yaz-5.37.0/0000755000175000017500000000000015130444232011035 5ustar00adamadamyaz-5.37.0/yaz.spec0000644000175000017500000001116615127773220012531 0ustar00adamadam# This file is part of the YAZ toolkit # Copyright (C) Index Data # See the file LICENSE for details. # # spec file for YAZ # disable LTO otherwise libstemmer compilation fails %global _lto_cflags %nil %define idmetaversion %(. ./IDMETA; echo $VERSION) Name: yaz Summary: Z39.50 Programs Version: %{idmetaversion} Release: 1.indexdata # determine system %define is_redhat5 %(grep 'release 5' /etc/redhat-release >/dev/null 2>&1 && echo 1 || echo 0) %define is_redhat8 %(grep 'release 8' /etc/redhat-release >/dev/null 2>&1 && echo 1 || echo 0) %define is_redhat9 %(grep 'release 9' /etc/redhat-release >/dev/null 2>&1 && echo 1 || echo 0) %define is_redhat10 %(grep 'release 10' /etc/redhat-release >/dev/null 2>&1 && echo 1 || echo 0) %define is_mandrake %(test -e /etc/mandrake-release && echo 1 || echo 0) %define is_suse %(test -e /etc/SuSE-release >/dev/null && echo 1 || echo 0) %define is_suse11 %(grep 'VERSION = 11' /etc/SuSE-release >/dev/null 2>&1 && echo 1 || echo 0) %define is_fedora %(test -e /etc/fedora-release && echo 1 || echo 0) Requires: readline, libyaz5 = %{version} License: BSD Group: Applications/Internet Vendor: Index Data ApS Source: yaz-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-root Prefix: %{_prefix} %define TCPWRAPPER tcp_wrappers-devel %if %is_suse %define TCPWRAPPER tcpd-devel %endif %if %is_suse11 BuildRequires: libgnutls-devel %else BuildRequires: gnutls-devel %endif %if %is_redhat5 %define TCPWRAPPER tcp_wrappers %endif %if %is_redhat8 %undefine TCPWRAPPER %endif %if %is_redhat9 %undefine TCPWRAPPER %endif %if %is_redhat10 %undefine TCPWRAPPER %endif %if 0%{?TCPWRAPPER:1} %define TCPDFLAGS --enable-tcpd BuildRequires: %{TCPWRAPPER} %else %define TCPDFLAGS --disable-tcpd %endif BuildRequires: pkgconfig BuildRequires: libxml2-devel BuildRequires: libxslt-devel BuildRequires: readline-devel BuildRequires: libicu-devel BuildRequires: wget Packager: Adam Dickmeiss URL: http://www.indexdata.com/yaz %description This package contains both a test-server and clients (normal & ssl) for the ANSI/NISO Z39.50 protocol for Information Retrieval. %package -n libyaz5 Summary: Z39.50 Library Group: Libraries Requires: libxslt, gnutls, libicu %description -n libyaz5 YAZ is a library for the ANSI/NISO Z39.50 protocol for Information Retrieval. %post -n libyaz5 -p /sbin/ldconfig %postun -n libyaz5 -p /sbin/ldconfig %package -n libyaz5-devel Summary: Z39.50 Library - development package Group: Development/Libraries Requires: libyaz5 = %{version}, libxml2-devel, libxslt-devel, libicu-devel Conflicts: libyaz-devel, libyaz4-devel %description -n libyaz5-devel Development libraries and includes for the libyaz package. %package -n yaz-illclient Summary: ILL client Group: Applications/Communication Requires: readline, libyaz5 = %{version} %description -n yaz-illclient yaz-illclient: an ISO ILL client. %package -n yaz-icu Summary: Command line utility for ICU utilities of YAZ Group: Applications/Communication Requires: libyaz5 = %{version} %description -n yaz-icu The yaz-icu program is a command-line based client which exposes the ICU chain facility of YAZ. %prep %setup %build CFLAGS="$RPM_OPT_FLAGS" \ ./configure --prefix=%{_prefix} --libdir=%{_libdir} --mandir=%{_mandir} \ --enable-shared ${TCPDFLAGS} --with-xslt --with-gnutls --with-icu \ --without-memcached %if %{?make_build:1}%{!?make_build:0} %make_build %else make -j4 CFLAGS="$RPM_OPT_FLAGS" %endif %install rm -fr ${RPM_BUILD_ROOT} make install DESTDIR=${RPM_BUILD_ROOT} rm ${RPM_BUILD_ROOT}/%{_libdir}/*.la %clean rm -fr ${RPM_BUILD_ROOT} %files %defattr(-,root,root) %doc README.md LICENSE NEWS %{_bindir}/yaz-client %{_bindir}/yaz-ztest %{_bindir}/zoomsh %{_bindir}/yaz-marcdump %{_bindir}/yaz-iconv %{_bindir}/yaz-json-parse %{_bindir}/yaz-url %{_bindir}/yaz-record-conv %{_mandir}/man1/yaz-client.* %{_mandir}/man1/yaz-json-parse.* %{_mandir}/man1/yaz-url.* %{_mandir}/man8/yaz-ztest.* %{_mandir}/man1/zoomsh.* %{_mandir}/man1/yaz-marcdump.* %{_mandir}/man1/yaz-iconv.* %{_mandir}/man1/yaz-record-conv.* %{_mandir}/man7/yaz-log.* %{_mandir}/man7/bib1-attr.* %files -n libyaz5 %defattr(-,root,root) %{_libdir}/*.so.* %files -n libyaz5-devel %defattr(-,root,root) %{_bindir}/yaz-config %{_bindir}/yaz-asncomp %{_includedir}/yaz %{_libdir}/pkgconfig/*.pc %{_libdir}/*.so %{_libdir}/*.a %{_datadir}/aclocal/yaz.m4 %{_mandir}/man1/yaz-asncomp.* %{_mandir}/man7/yaz.* %{_mandir}/man?/yaz-config.* %{_datadir}/doc/yaz %{_datadir}/yaz %files -n yaz-illclient %defattr(-,root,root) %{_bindir}/yaz-illclient %{_mandir}/man1/yaz-illclient.* %files -n yaz-icu %defattr(-,root,root) %{_bindir}/yaz-icu %{_mandir}/man1/yaz-icu.* yaz-5.37.0/doc/0000755000175000017500000000000015130444232011602 5ustar00adamadamyaz-5.37.0/doc/yaz-config-man.xml0000644000175000017500000000720115123757344015160 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-config 1 Commands yaz-config Script to get information about YAZ. yaz-config libraries DESCRIPTION yaz-config is a script that returns information that your own software should use to build software that uses YAZ. The following libraries are supported: threads Use the threaded version of YAZ. OPTIONS --prefix[=DIR] Returns prefix of YAZ or assume a different one if DIR is specified. --version Returns version of YAZ. --libs Library specification be used when using YAZ. --lalibs Return library specification. --cflags Return C Compiler flags. --include Return C compiler includes for YAZ header files (-Ipath). --comp Returns full path to YAZ' ASN.1 compiler: yaz-asncomp. -V Returns YAZ SHA1 ID (from Git) and version. FILES /usr/bin/yaz-config /usr/lib/libyaz*.a /usr/include/yaz/*.h SEE ALSO yaz(7) Section "How to make apps using YAZ on UNIX" in the YAZ manual. yaz-5.37.0/doc/list-oids.html0000644000175000017500000006342515130444232014411 0ustar00adamadamAppendix A. List of Object Identifiers
Appendix A. List of Object Identifiers
Prev   Next

Appendix A. List of Object Identifiers

These is a list of object identifiers that are built into YAZ.

NameClassConstant / OID
BER TRANSYN yaz_oid_transyn_ber
2.1.1
ISO2709 TRANSYN yaz_oid_transyn_iso2709
1.0.2709.1.1
ISOILL-1 GENERAL yaz_oid_general_isoill_1
1.0.10161.2.1
Z-APDU ABSYN yaz_oid_absyn_z_apdu
2.1
Z-BASIC APPCTX yaz_oid_appctx_z_basic
1.1
Bib-1 ATTSET yaz_oid_attset_bib_1
Z3950_PREFIX.3.1
Exp-1 ATTSET yaz_oid_attset_exp_1
Z3950_PREFIX.3.2
Ext-1 ATTSET yaz_oid_attset_ext_1
Z3950_PREFIX.3.3
CCL-1 ATTSET yaz_oid_attset_ccl_1
Z3950_PREFIX.3.4
GILS ATTSET yaz_oid_attset_gils
Z3950_PREFIX.3.5
GILS-attset ATTSET yaz_oid_attset_gils_attset
Z3950_PREFIX.3.5
STAS-attset ATTSET yaz_oid_attset_stas_attset
Z3950_PREFIX.3.6
Collections-attset ATTSET yaz_oid_attset_collections_attset
Z3950_PREFIX.3.7
CIMI-attset ATTSET yaz_oid_attset_cimi_attset
Z3950_PREFIX.3.8
Geo-attset ATTSET yaz_oid_attset_geo_attset
Z3950_PREFIX.3.9
ZBIG ATTSET yaz_oid_attset_zbig
Z3950_PREFIX.3.10
Util ATTSET yaz_oid_attset_util
Z3950_PREFIX.3.11
XD-1 ATTSET yaz_oid_attset_xd_1
Z3950_PREFIX.3.12
Zthes ATTSET yaz_oid_attset_zthes
Z3950_PREFIX.3.13
Fin-1 ATTSET yaz_oid_attset_fin_1
Z3950_PREFIX.3.14
Dan-1 ATTSET yaz_oid_attset_dan_1
Z3950_PREFIX.3.15
Holdings ATTSET yaz_oid_attset_holdings
Z3950_PREFIX.3.16
MARC ATTSET yaz_oid_attset_marc
Z3950_PREFIX.3.17
Bib-2 ATTSET yaz_oid_attset_bib_2
Z3950_PREFIX.3.18
ZeeRex ATTSET yaz_oid_attset_zeerex
Z3950_PREFIX.3.19
Thesaurus-attset ATTSET yaz_oid_attset_thesaurus_attset
Z3950_PREFIX.3.1000.81.1
IDXPATH ATTSET yaz_oid_attset_idxpath
Z3950_PREFIX.3.1000.81.2
EXTLITE ATTSET yaz_oid_attset_extlite
Z3950_PREFIX.3.1000.81.3
Bib-1 DIAGSET yaz_oid_diagset_bib_1
Z3950_PREFIX.4.1
Diag-1 DIAGSET yaz_oid_diagset_diag_1
Z3950_PREFIX.4.2
Diag-ES DIAGSET yaz_oid_diagset_diag_es
Z3950_PREFIX.4.3
Diag-General DIAGSET yaz_oid_diagset_diag_general
Z3950_PREFIX.4.3
Unimarc RECSYN yaz_oid_recsyn_unimarc
Z3950_PREFIX.5.1
Intermarc RECSYN yaz_oid_recsyn_intermarc
Z3950_PREFIX.5.2
CCF RECSYN yaz_oid_recsyn_ccf
Z3950_PREFIX.5.3
USmarc RECSYN yaz_oid_recsyn_usmarc
Z3950_PREFIX.5.10
MARC21 RECSYN yaz_oid_recsyn_marc21
Z3950_PREFIX.5.10
UKmarc RECSYN yaz_oid_recsyn_ukmarc
Z3950_PREFIX.5.11
Normarc RECSYN yaz_oid_recsyn_normarc
Z3950_PREFIX.5.12
Librismarc RECSYN yaz_oid_recsyn_librismarc
Z3950_PREFIX.5.13
Danmarc RECSYN yaz_oid_recsyn_danmarc
Z3950_PREFIX.5.14
Finmarc RECSYN yaz_oid_recsyn_finmarc
Z3950_PREFIX.5.15
MAB RECSYN yaz_oid_recsyn_mab
Z3950_PREFIX.5.16
Canmarc RECSYN yaz_oid_recsyn_canmarc
Z3950_PREFIX.5.17
SBN RECSYN yaz_oid_recsyn_sbn
Z3950_PREFIX.5.18
Picamarc RECSYN yaz_oid_recsyn_picamarc
Z3950_PREFIX.5.19
Ausmarc RECSYN yaz_oid_recsyn_ausmarc
Z3950_PREFIX.5.20
Ibermarc RECSYN yaz_oid_recsyn_ibermarc
Z3950_PREFIX.5.21
Carmarc RECSYN yaz_oid_recsyn_carmarc
Z3950_PREFIX.5.22
Malmarc RECSYN yaz_oid_recsyn_malmarc
Z3950_PREFIX.5.23
JPmarc RECSYN yaz_oid_recsyn_jpmarc
Z3950_PREFIX.5.24
SWEmarc RECSYN yaz_oid_recsyn_swemarc
Z3950_PREFIX.5.25
SIGLEmarc RECSYN yaz_oid_recsyn_siglemarc
Z3950_PREFIX.5.26
ISDSmarc RECSYN yaz_oid_recsyn_isdsmarc
Z3950_PREFIX.5.27
RUSmarc RECSYN yaz_oid_recsyn_rusmarc
Z3950_PREFIX.5.28
Hunmarc RECSYN yaz_oid_recsyn_hunmarc
Z3950_PREFIX.5.29
NACSIS-CATP RECSYN yaz_oid_recsyn_nacsis_catp
Z3950_PREFIX.5.30
FINMARC2000 RECSYN yaz_oid_recsyn_finmarc2000
Z3950_PREFIX.5.31
MARC21-fin RECSYN yaz_oid_recsyn_marc21_fin
Z3950_PREFIX.5.32
Explain RECSYN yaz_oid_recsyn_explain
Z3950_PREFIX.5.100
SUTRS RECSYN yaz_oid_recsyn_sutrs
Z3950_PREFIX.5.101
OPAC RECSYN yaz_oid_recsyn_opac
Z3950_PREFIX.5.102
Summary RECSYN yaz_oid_recsyn_summary
Z3950_PREFIX.5.103
GRS-0 RECSYN yaz_oid_recsyn_grs_0
Z3950_PREFIX.5.104
GRS-1 RECSYN yaz_oid_recsyn_grs_1
Z3950_PREFIX.5.105
Extended RECSYN yaz_oid_recsyn_extended
Z3950_PREFIX.5.106
Fragment RECSYN yaz_oid_recsyn_fragment
Z3950_PREFIX.5.107
pdf RECSYN yaz_oid_recsyn_pdf
Z3950_PREFIX.5.109.1
postscript RECSYN yaz_oid_recsyn_postscript
Z3950_PREFIX.5.109.2
html RECSYN yaz_oid_recsyn_html
Z3950_PREFIX.5.109.3
tiff RECSYN yaz_oid_recsyn_tiff
Z3950_PREFIX.5.109.4
gif RECSYN yaz_oid_recsyn_gif
Z3950_PREFIX.5.109.5
jpeg RECSYN yaz_oid_recsyn_jpeg
Z3950_PREFIX.5.109.6
png RECSYN yaz_oid_recsyn_png
Z3950_PREFIX.5.109.7
mpeg RECSYN yaz_oid_recsyn_mpeg
Z3950_PREFIX.5.109.8
sgml RECSYN yaz_oid_recsyn_sgml
Z3950_PREFIX.5.109.9
tiff-b RECSYN yaz_oid_recsyn_tiff_b
Z3950_PREFIX.5.110.1
wav RECSYN yaz_oid_recsyn_wav
Z3950_PREFIX.5.110.2
SQL-RS RECSYN yaz_oid_recsyn_sql_rs
Z3950_PREFIX.5.111
SOIF RECSYN yaz_oid_recsyn_soif
Z3950_PREFIX.5.1000.81.2
JSON RECSYN yaz_oid_recsyn_json
Z3950_PREFIX.5.1000.81.3
XML RECSYN yaz_oid_recsyn_xml
Z3950_PREFIX.5.109.10
text-XML RECSYN yaz_oid_recsyn_text_xml
Z3950_PREFIX.5.109.10
application-XML RECSYN yaz_oid_recsyn_application_xml
Z3950_PREFIX.5.109.11
Resource-1 RESFORM yaz_oid_resform_resource_1
Z3950_PREFIX.7.1
Resource-2 RESFORM yaz_oid_resform_resource_2
Z3950_PREFIX.7.2
UNIverse-Resource-Report RESFORM yaz_oid_resform_universe_resource_report
Z3950_PREFIX.7.1000.81.1
Prompt-1 ACCFORM yaz_oid_accform_prompt_1
Z3950_PREFIX.8.1
Des-1 ACCFORM yaz_oid_accform_des_1
Z3950_PREFIX.8.2
Krb-1 ACCFORM yaz_oid_accform_krb_1
Z3950_PREFIX.8.3
Persistent set EXTSERV yaz_oid_extserv_persistent_set
Z3950_PREFIX.9.1
Persistent query EXTSERV yaz_oid_extserv_persistent_query
Z3950_PREFIX.9.2
Periodic query EXTSERV yaz_oid_extserv_periodic_query
Z3950_PREFIX.9.3
Item order EXTSERV yaz_oid_extserv_item_order
Z3950_PREFIX.9.4
Database Update (first version) EXTSERV yaz_oid_extserv_database_update_first_version
Z3950_PREFIX.9.5
Database Update (second version) EXTSERV yaz_oid_extserv_database_update_second_version
Z3950_PREFIX.9.5.1
Database Update EXTSERV yaz_oid_extserv_database_update
Z3950_PREFIX.9.5.1.1
exp. spec. EXTSERV yaz_oid_extserv_exp__spec_
Z3950_PREFIX.9.6
exp. inv. EXTSERV yaz_oid_extserv_exp__inv_
Z3950_PREFIX.9.7
Admin EXTSERV yaz_oid_extserv_admin
Z3950_PREFIX.9.1000.81.1
searchResult-1 USERINFO yaz_oid_userinfo_searchresult_1
Z3950_PREFIX.10.1
CharSetandLanguageNegotiation USERINFO yaz_oid_userinfo_charsetandlanguagenegotiation
Z3950_PREFIX.10.2
UserInfo-1 USERINFO yaz_oid_userinfo_userinfo_1
Z3950_PREFIX.10.3
MultipleSearchTerms-1 USERINFO yaz_oid_userinfo_multiplesearchterms_1
Z3950_PREFIX.10.4
MultipleSearchTerms-2 USERINFO yaz_oid_userinfo_multiplesearchterms_2
Z3950_PREFIX.10.5
DateTime USERINFO yaz_oid_userinfo_datetime
Z3950_PREFIX.10.6
Proxy USERINFO yaz_oid_userinfo_proxy
Z3950_PREFIX.10.1000.81.1
Cookie USERINFO yaz_oid_userinfo_cookie
Z3950_PREFIX.10.1000.81.2
Client-IP USERINFO yaz_oid_userinfo_client_ip
Z3950_PREFIX.10.1000.81.3
Scan-Set USERINFO yaz_oid_userinfo_scan_set
Z3950_PREFIX.10.1000.81.4
Facet-1 USERINFO yaz_oid_userinfo_facet_1
Z3950_PREFIX.10.1000.81.5
Espec-1 ELEMSPEC yaz_oid_elemspec_espec_1
Z3950_PREFIX.11.1
Variant-1 VARSET yaz_oid_varset_variant_1
Z3950_PREFIX.12.1
WAIS-schema SCHEMA yaz_oid_schema_wais_schema
Z3950_PREFIX.13.1
GILS-schema SCHEMA yaz_oid_schema_gils_schema
Z3950_PREFIX.13.2
Collections-schema SCHEMA yaz_oid_schema_collections_schema
Z3950_PREFIX.13.3
Geo-schema SCHEMA yaz_oid_schema_geo_schema
Z3950_PREFIX.13.4
CIMI-schema SCHEMA yaz_oid_schema_cimi_schema
Z3950_PREFIX.13.5
Update ES SCHEMA yaz_oid_schema_update_es
Z3950_PREFIX.13.6
Holdings SCHEMA yaz_oid_schema_holdings
Z3950_PREFIX.13.7
Zthes SCHEMA yaz_oid_schema_zthes
Z3950_PREFIX.13.8
thesaurus-schema SCHEMA yaz_oid_schema_thesaurus_schema
Z3950_PREFIX.13.1000.81.1
Explain-schema SCHEMA yaz_oid_schema_explain_schema
Z3950_PREFIX.13.1000.81.2
TagsetM TAGSET yaz_oid_tagset_tagsetm
Z3950_PREFIX.14.1
TagsetG TAGSET yaz_oid_tagset_tagsetg
Z3950_PREFIX.14.2
STAS-tagset TAGSET yaz_oid_tagset_stas_tagset
Z3950_PREFIX.14.3
GILS-tagset TAGSET yaz_oid_tagset_gils_tagset
Z3950_PREFIX.14.4
Collections-tagset TAGSET yaz_oid_tagset_collections_tagset
Z3950_PREFIX.14.5
CIMI-tagset TAGSET yaz_oid_tagset_cimi_tagset
Z3950_PREFIX.14.6
thesaurus-tagset TAGSET yaz_oid_tagset_thesaurus_tagset
Z3950_PREFIX.14.1000.81.1
Explain-tagset TAGSET yaz_oid_tagset_explain_tagset
Z3950_PREFIX.14.1000.81.2
Zthes-tagset TAGSET yaz_oid_tagset_zthes_tagset
Z3950_PREFIX.14.8
Charset-3 NEGOT yaz_oid_negot_charset_3
Z3950_PREFIX.15.3
Charset-4 NEGOT yaz_oid_negot_charset_4
Z3950_PREFIX.15.4
Charset-ID NEGOT yaz_oid_negot_charset_id
Z3950_PREFIX.15.1000.81.1
CQL USERINFO yaz_oid_userinfo_cql
Z3950_PREFIX.16.2
UCS-2 GENERAL yaz_oid_general_ucs_2
1.0.10646.1.0.2
UCS-4 GENERAL yaz_oid_general_ucs_4
1.0.10646.1.0.4
UTF-16 GENERAL yaz_oid_general_utf_16
1.0.10646.1.0.5
UTF-8 GENERAL yaz_oid_general_utf_8
1.0.10646.1.0.8
OCLC-userInfo USERINFO yaz_oid_userinfo_oclc_userinfo
Z3950_PREFIX.10.1000.17.1
XML-ES EXTSERV yaz_oid_extserv_xml_es
Z3950_PREFIX.9.1000.105.4
Prev   Next
yaz-record-iconv Home Appendix B. Bib-1 diagnostics
yaz-5.37.0/doc/bib1.html0000644000175000017500000001530615130444232013312 0ustar00adamadamBib-1 Attribute Set
Bib-1 Attribute Set
Prev Reference Next

Name

bib1-attr — Bib-1 Attribute Set

DESCRIPTION

This reference entry lists the Bib-1 attribute set types and values.

TYPES

The Bib-1 attribute set defines six attribute types: Use (1), Relation (2), Position (3), Structure (4), Truncation (5) and Completeness (6).

USE (1)

    1     Personal-name
    2     Corporate-name
    3     Conference-name
    4     Title
    5     Title-series
    6     Title-uniform
    7     ISBN
    8     ISSN
    9     LC-card-number
    10    BNB-card-number
    11    BGF-number
    12    Local-number
    13    Dewey-classification
    14    UDC-classification
    15    Bliss-classification
    16    LC-call-number
    17    NLM-call-number
    18    NAL-call-number
    19    MOS-call-number
    20    Local-classification
    21    Subject-heading
    22    Subject-Rameau
    23    BDI-index-subject
    24    INSPEC-subject
    25    MESH-subject
    26    PA-subject
    27    LC-subject-heading
    28    RVM-subject-heading
    29    Local-subject-index
    30    Date
    31    Date-of-publication
    32    Date-of-acquisition
    33    Title-key
    34    Title-collective
    35    Title-parallel
    36    Title-cover
    37    Title-added-title-page
    38    Title-caption
    39    Title-running
    40    Title-spine
    41    Title-other-variant
    42    Title-former
    43    Title-abbreviated
    44    Title-expanded
    45    Subject-precis
    46    Subject-rswk
    47    Subject-subdivision
    48    Number-natl-biblio
    49    Number-legal-deposit
    50    Number-govt-pub
    51    Number-music-publisher
    52    Number-db
    53    Number-local-call
    54    Code-language
    55    Code-geographic
    56    Code-institution
    57    Name-and-title
    58    Name-geographic
    59    Place-publication
    60    CODEN
    61    Microform-generation
    62    Abstract
    63    Note
    1000  Author-title
    1001  Record-type
    1002  Name
    1003  Author
    1004  Author-name-personal
    1005  Author-name-corporate
    1006  Author-name-conference
    1007  Identifier-standard
    1008  Subject-LC-childrens
    1009  Subject-name-personal
    1010  Body-of-text
    1011  Date/time-added-to-db
    1012  Date/time-last-modified
    1013  Authority/format-id
    1014  Concept-text
    1015  Concept-reference
    1016  Any
    1017  Server-choice
    1018  Publisher
    1019  Record-source
    1020  Editor
    1021  Bib-level
    1022  Geographic-class
    1023  Indexed-by
    1024  Map-scale
    1025  Music-key
    1026  Related-periodical
    1027  Report-number
    1028  Stock-number
    1030  Thematic-number
    1031  Material-type
    1032  Doc-id
    1033  Host-item
    1034  Content-type
    1035  Anywhere
    1036  Author-Title-Subject

RELATION (2)

    1 Less than
    2 Less than or equal
    3 Equal
    4 Greater or equal
    5 Greater than
    6 Not equal
    100 Phonetic
    101 Stem
    102 Relevance
    103 AlwaysMatches

POSITION (3)

    1 First in field
    2 First in subfield
    3 Any position in field

STRUCTURE (4)

    1 Phrase
    2 Word
    3 Key
    4 Year
    5 Date (normalized)
    6 Word list
    100 Date (un-normalized)
    101 Name (normalized)
    102 Name (un-normalized)
    103 Structure
    104 Urx
    105 Free-form-text
    106 Document-text
    107 Local-number
    108 String
    109 Numeric-string

TRUNCATION (5)

    1 Right truncation
    2 Left truncation
    3 Left and right truncation
    100 Do not truncate
    101 Process # in search term  . regular #=.*
    102 RegExpr-1
    103 RegExpr-2
    104 Process # ?n . regular: #=., ?n=.{0,n} or ?=.* Z39.58

The 105-106 truncation attributes below are only supported by Index Data's Zebra server. 

    105 Process * ! regular: *=.*, !=. and right truncate
    106 Process * ! regular: *=.*, !=.

COMPLETENESS (6)

    1 Incomplete subfield
    2 Complete subfield
    3 Complete field

SORTING (7)

    1 ascending
    2 descending

Type 7 is an Index Data extension to RPN queries that allows embedding a sort critieria into a query.

SEE ALSO

Bib-1 Attribute Set

Attribute Set Bib-1 Semantics.

Prev Up Next
yaz-url Home yaz-json-parse
yaz-5.37.0/doc/yaz-log.70000644000175000017500000002164615130444226013270 0ustar00adamadam'\" t .\" Title: yaz-log .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Conventions and miscellaneous .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-LOG" "7" "01/10/2026" "YAZ 5.37.0" "Conventions and miscellaneous" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-log \- Log handling in all yaz\-based programs .SH "SYNOPSIS" .HP \w'\fByaz\-XXXX\fR\ 'u \fByaz\-XXXX\fR [\fB\-v\ \fR\fB\fIloglevel,\&.\&.\&.\fR\fR] [\fB\-l\ \fR\fB\fIlogfile\fR\fR] .SH "DESCRIPTION" .PP All YAZ\-based programs use a common log subsystem, and should support common command line options for controlling it\&. This man page documents those\&. .PP .SH "OPTIONS" .PP \-l\fI logfile\fR .RS 4 Specify the file where the log is to be written\&. If none is specified, stderr is used\&. The log is appended to this file\&. If the file grows overly large, it is silently rotated: It is renamed to \fIlogfile\fR\&.1, \fIlogfile\fR\&.2, \&.\&., 9 (old such file is deleted), and a new file is opened\&. The limit defaults to 1GB, but can be set by the program\&. The rotating limit can be specified with option \-r for the YAZ frontend server (yaz\-ztest)\&. .sp Rotation can also be implicitly enabled by using a filename which gets changed for a given date, due to substitutions as given by the strftime(3) function\&. .RE .PP \-v\fI loglevel\fR .RS 4 Specify the logging level\&. The argument is a set of log level names, separated by commas (no whitespace!), optionally preceded by a \*(Aq\-\*(Aq to negate that level\&. Most programs have their own default, often containing fatal,warn,log, and some application\-specific values\&. The default list can be cleared with the word none, or individual bits can be removed by prefixing them with a dash \*(Aq\-\*(Aq\&. .RE .SH "LOG LEVELS TO CONTROL LOGGING" .PP Some of the log levels control the way the log is written\&. .PP flush causes the log to be flushed after every write\&. This can have serious implications to performance, and should not be used in production\&. On the other hand, when debugging a program crash, this can be extremely useful\&. The option debug implies flush as well\&. .PP notime prevents the writing of time stamps\&. This is intended for automatic test scripts, which should produce predictable log files that are easy to compare\&. .SH "GENERAL LOG LEVELS IN YAZ ITSELF" .PP YAZ itself uses the following log levels: .PP fatal for fatal errors, that prevent further execution of the program\&. .PP warn for warnings about things that should be corrected\&. .PP debug for debugging\&. This flag may be used temporarily when developing or debugging yaz, or a program that uses yaz\&. It is practically deprecated, you should be defining and using your own log levels (see below)\&. .PP all turns on almost all hard\-coded log levels\&. .PP loglevel logs information about the log levels used by the program\&. Every time the log level is changed, lists all bits that are on\&. Every time a module asks for its log bits, this is logged\&. This can be used for getting an idea of what log levels are available in any program that uses yaz\-log\&. Start the program with \-v none,loglevel, and do some common operations with it\&. Another way is to grep for \fByaz_log_module_level\fR in the source code, as in .sp .if n \{\ .RS 4 .\} .nf find \&. \-name \*(Aq*\&.[ch]\*(Aq \-print | xargs grep yaz_log_module_level | grep \*(Aq"\*(Aq | cut \-d\*(Aq"\*(Aq \-f2 | sort \-u .fi .if n \{\ .RE .\} .PP eventl, malloc, nmem, odr are used internally for debugging yaz\&. .PP .SH "LOG LEVELS FOR CLIENTS" .PP zoom logs the calls to the zoom API, which may be useful in debugging client applications\&. .SH "LOG LEVELS FOR SERVERS" .PP server logs the server functions on a high level, starting up, listening on a port, etc\&. .PP session logs individual sessions (connections)\&. .PP request logs a one\-liner for each request (init, search, etc\&.)\&. .PP requestdetail logs the details of every request, before it is passed to the back\-end, and the results received from it\&. .PP Each server program (zebra, etc\&.) is supposed to define its own log levels in addition to these\&. As they depend on the server in question, they can not be described here\&. See above how to find out about them\&. .SH "LOGGING EXAMPLES" .PP See what log levels yaz\-ztest is using: .sp .if n \{\ .RS 4 .\} .nf yaz\-ztest \-1 \-v none,loglevel 14:43:29\-23/11 [loglevel] Setting log level to 4096 = 0x00001000 14:43:29\-23/11 [loglevel] Static log bit 00000001 \*(Aqfatal\*(Aq is off 14:43:29\-23/11 [loglevel] Static log bit 00000002 \*(Aqdebug\*(Aq is off 14:43:29\-23/11 [loglevel] Static log bit 00000004 \*(Aqwarn\*(Aq is off 14:43:29\-23/11 [loglevel] Static log bit 00000008 \*(Aqlog\*(Aq is off 14:43:29\-23/11 [loglevel] Static log bit 00000080 \*(Aqmalloc\*(Aq is off 14:43:29\-23/11 [loglevel] Static log bit 00000800 \*(Aqflush\*(Aq is off 14:43:29\-23/11 [loglevel] Static log bit 00001000 \*(Aqloglevel\*(Aq is ON 14:43:29\-23/11 [loglevel] Static log bit 00002000 \*(Aqserver\*(Aq is off 14:43:29\-23/11 [loglevel] Dynamic log bit 00004000 \*(Aqsession\*(Aq is off 14:43:29\-23/11 [loglevel] Dynamic log bit 00008000 \*(Aqrequest\*(Aq is off 14:44:13\-23/11 yaz\-ztest [loglevel] returning log bit 0x4000 for \*(Aqsession\*(Aq 14:44:13\-23/11 yaz\-ztest [loglevel] returning log bit 0x2000 for \*(Aqserver\*(Aq 14:44:13\-23/11 yaz\-ztest [loglevel] returning NO log bit for \*(Aqeventl\*(Aq 14:44:20\-23/11 yaz\-ztest [loglevel] returning log bit 0x4000 for \*(Aqsession\*(Aq 14:44:20\-23/11 yaz\-ztest [loglevel] returning log bit 0x8000 for \*(Aqrequest\*(Aq 14:44:20\-23/11 yaz\-ztest [loglevel] returning NO log bit for \*(Aqrequestdetail\*(Aq 14:44:20\-23/11 yaz\-ztest [loglevel] returning NO log bit for \*(Aqodr\*(Aq 14:44:20\-23/11 yaz\-ztest [loglevel] returning NO log bit for \*(Aqztest\*(Aq .fi .if n \{\ .RE .\} .PP See the details of the requests for yaz\-ztest .sp .if n \{\ .RS 4 .\} .nf \&./yaz\-ztest \-1 \-v requestdetail 14:45:35\-23/11 yaz\-ztest [server] Adding static Z3950 listener on tcp:@:9999 14:45:35\-23/11 yaz\-ztest [server] Starting server \&./yaz\-ztest pid=32200 14:45:38\-23/11 yaz\-ztest [session] Starting session from tcp:127\&.0\&.0\&.1 (pid=32200) 14:45:38\-23/11 yaz\-ztest [requestdetail] Got initRequest 14:45:38\-23/11 yaz\-ztest [requestdetail] Id: 81 14:45:38\-23/11 yaz\-ztest [requestdetail] Name: YAZ 14:45:38\-23/11 yaz\-ztest [requestdetail] Version: 2\&.0\&.28 14:45:38\-23/11 yaz\-ztest [requestdetail] Negotiated to v3: srch prst del extendedServices namedresults scan sort 14:45:38\-23/11 yaz\-ztest [request] Init from \*(AqYAZ\*(Aq (81) (ver 2\&.0\&.28) OK 14:45:39\-23/11 yaz\-ztest [requestdetail] Got SearchRequest\&. 14:45:39\-23/11 yaz\-ztest [requestdetail] ResultSet \*(Aq1\*(Aq 14:45:39\-23/11 yaz\-ztest [requestdetail] Database \*(AqDefault\*(Aq 14:45:39\-23/11 yaz\-ztest [requestdetail] RPN query\&. Type: Bib\-1 14:45:39\-23/11 yaz\-ztest [requestdetail] term \*(Aqfoo\*(Aq (general) 14:45:39\-23/11 yaz\-ztest [requestdetail] resultCount: 7 14:45:39\-23/11 yaz\-ztest [request] Search Z: @attrset Bib\-1 foo OK:7 hits 14:45:41\-23/11 yaz\-ztest [requestdetail] Got PresentRequest\&. 14:45:41\-23/11 yaz\-ztest [requestdetail] Request to pack 1+1 1 14:45:41\-23/11 yaz\-ztest [requestdetail] pms=1048576, mrs=1048576 14:45:41\-23/11 yaz\-ztest [request] Present: [1] 1+1 OK 1 records returned .fi .if n \{\ .RE .\} .sp .SH "LOG FILENAME EXAMPLES" .PP A file with format my_YYYYMMDD\&.log (where Y, M, D is year, month, and day digits) is given as follows: \-l my_%Y%m%d\&.log \&. And since the filename is depending on day, rotation will occur on midnight\&. .PP A weekly log could be specified as \-l my_%Y%U\&.log\&. .SH "FILES" .PP \fIprefix\fR/include/yaz/log\&.h \fIprefix\fR/src/log\&.c .SH "SEE ALSO" .PP \fByaz\fR(7) \fByaz-ztest\fR(8) \fByaz-client\fR(1) \fBstrftime\fR(3) .SH "AUTHORS" .PP \fBIndex Data\fR yaz-5.37.0/doc/introduction.api.html0000644000175000017500000002165515130444232015772 0ustar00adamadam2. The API
2. The API
Prev Chapter 1. Introduction Next

2. The API

The YAZ toolkit offers several different levels of access to the ISO23950/Z39.50, ILL and SRU protocols. The level that you need to use depends on your requirements, and the role (server or client) that you want to implement. If you're developing a client application you should consider the ZOOM API. It is, by far, the easiest way to develop clients in C. Server implementors should consider the generic front-end server. None of those high-level APIs support the whole protocol, but they do include most facilities used in existing Z39.50 applications.

If you're using 'exotic' functionality (meaning anything not included in the high-level APIs), developing non-standard extensions to Z39.50 or you're going to develop an ILL application, you'll have to learn the lower level APIs of YAZ.

The YAZ toolkit modules are shown in figure Figure 1.1, “YAZ layers”.

Figure 1.1. YAZ layers

YAZ layers

There are four layers.

  • A client or server application (or both). This layer includes ZOOM and the generic front-end server.

  • The second layer provides a C representation of the protocol units (packages) for Z39.50 ASN.1, ILL ASN.1, SRU.

  • The third layer encodes and decodes protocol data units to simple packages (buffer with certain length). The ODR module encodes and decodes BER whereas the HTTP modules encodes and decodes HTTP requests/responses.

  • The lowest layer is COMSTACK which exchanges the encoded packages with a peer process over a network.

The Z39.50 ASN.1 module represents the ASN.1 definition of the Z39.50 protocol. It establishes a set of type and structure definitions, with one structure for each of the top-level PDUs, and one structure or type for each of the contained ASN.1 types. For primitive types, or other types that are defined by the ASN.1 standard itself (such as the EXTERNAL type), the C representation is provided by the ODR (Open Data Representation) subsystem.

ODR is a basic mechanism for representing an ASN.1 type in the C programming language, and for implementing BER encoders and decoders for values of that type. The types defined in the Z39.50 ASN.1 module generally have the prefix Z_, and a suffix corresponding to the name of the type in the ASN.1 specification of the protocol (generally Z39.50-1995). In the case of base types (those originating in the ASN.1 standard itself), the prefix Odr_ is sometimes seen. Either way, look for the actual definition in either z-core.h (for the types from the protocol), odr.h (for the primitive ASN.1 types). The Z39.50 ASN.1 library also provides functions (which are, in turn, defined using ODR primitives) for encoding and decoding data values. Their general form is

int z_xxx(o,  
 p,  
 optional,  
 name); 
ODR o;
Z_xxx **p;
int optional;
const char *name;
 

(note the lower-case "z" in the function name)

Note

If you are using the premade definitions of the Z39.50 ASN.1 module, and you are not adding a new protocol of your own, the only parts of ODR that you need to worry about are documented in Section 2, “Using ODR”.

When you have created a BER-encoded buffer, you can use the COMSTACK subsystem to transmit (or receive) data over the network. The COMSTACK module provides simple functions for establishing a connection (passively or actively, depending on the role of your application), and for exchanging BER-encoded PDUs over that connection. When you create a connection endpoint, you need to specify what transport to use (TCP/IP, SSL or UNIX sockets). For the remainder of the connection's lifetime, you don't have to worry about the underlying transport protocol at all - the COMSTACK will ensure that the correct mechanism is used.

We call the combined interfaces to ODR, Z39.50 ASN.1, and COMSTACK the service level API. It's the API that most closely models the Z39.50 service/protocol definition, and it provides unlimited access to all fields and facilities of the protocol definitions.

The reason that the YAZ service-level API is a conglomerate of the APIs from three different sub-modules is twofold. First, we wanted to allow the user a choice of different options for each major task. For instance, if you don't like the protocol API provided by ODR/Z39.50 ASN.1, you can use SNACC or BERUtils instead, and still have the benefits of the transparent transport approach of the COMSTACK module. Secondly, we realize that you may have to fit the toolkit into an existing event-processing structure, in a way that is incompatible with the COMSTACK interface or some other part of YAZ.

Prev Up Next
Chapter 1. Introduction Home Chapter 2. Compilation and Installation
yaz-5.37.0/doc/yaz-asncomp.10000644000175000017500000001264015130444226014133 0ustar00adamadam'\" t .\" Title: yaz-asncomp .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-ASNCOMP" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-asncomp \- YAZ ASN\&.1 compiler .SH "SYNOPSIS" .HP \w'\fByaz\-asncomp\fR\ 'u \fByaz\-asncomp\fR [\fB\-v\fR] [\fB\-c\ \fR\fB\fIcfile\fR\fR] [\fB\-h\ \fR\fB\fIhfile\fR\fR] [\fB\-p\ \fR\fB\fIpfile\fR\fR] [\fB\-d\ \fR\fB\fIconfig\fR\fR] [\fB\-I\ \fR\fB\fIincludeout\fR\fR] [\fB\-i\ \fR\fB\fIincludedir\fR\fR] [\fB\-m\ \fR\fB\fImodule\fR\fR] [filename] .SH "DESCRIPTION" .PP \fByaz\-asncomp\fR is an ASN\&.1 compiler that reads an ASN\&.1 specification in \fIfilename\fR and produces C/C++ definitions and BER encoders/decoders for it\&. .PP The produced C/C++ code and header files uses the ODR module of YAZ which is a library that encodes/decodes/prints BER packages\&. \fByaz\-asncomp\fR allows you to specify name of resulting source via options\&. Alternatively, you can specify a DEFINITIONS file, which provides customized output to many output files \- if the ASN\&.1 specification file consists of many modules\&. .PP This utility is written in Tcl\&. Any version of Tcl should work\&. .SH "OPTIONS" .PP \-v .RS 4 Makes the ASN\&.1 compiler print more verbose about the various stages of operations\&. .RE .PP \-c \fIcfile\fR .RS 4 Specifies the name of the C/C++ file with encoders/decoders\&. .RE .PP \-h \fIhfile\fR .RS 4 Specifies the name of header file with definitions\&. .RE .PP \-p \fIpfile\fR .RS 4 Specifies the name of the a private header file with definitions\&. By default all definitions are put in header file (option \-h)\&. .RE .PP \-d \fIdfile\fR .RS 4 Specifies the name of a definitions file\&. .RE .PP \-I \fIiout\fR .RS 4 Specifies first part of directory in which header files are written\&. .RE .PP \-i \fIidir\fR .RS 4 Specifies second part of directory in which header files are written\&. .RE .PP \-m \fImodule\fR .RS 4 Specifies that ASN\&.1 compiler should only process the module given\&. If this option is not specified, all modules in the ASN\&.1 file are processed\&. .RE .SH "DEFINITIONS FILE" .PP The definitions file is really a Tcl script but follows traditional rules for Shell like configuration files\&. That is # denotes the beginning of a comment\&. Definitions are line oriented\&. The definitions files usually consist of a series of variable assignments of the form: .PP set \fIname\fR \fIvalue\fR .PP Available variables are: .PP default\-prefix .RS 4 Sets prefix for names in the produced output\&. The value consists of three tokens: C function prefix, C typedef prefix and preprocessor prefix respectively\&. .RE .PP prefix(\fImodule\fR) .RS 4 This value sets prefix values for module \fImodule\fR\&. The value has same form as default\-prefix\&. .RE .PP filename(\fImodule\fR) .RS 4 Specifies filename for C/header file for module \fImodule\fR\&. .RE .PP init(\fImodule\fR,h) .RS 4 Code fragment to be put in first part of public header for module \fImodule\fR\&. .RE .PP body(\fImodule\fR,h) .RS 4 Code fragment to be put in last part of public header for module \fImodule\fR (trailer)\&. .RE .PP init(\fImodule\fR,c) .RS 4 Code fragment to be put in first part of C based encoder/decoder for module \fImodule\fR\&. .RE .PP body(\fImodule\fR,c) .RS 4 Code fragment to be put in last part of C based encoder/decoder for module \fImodule\fR (trailer)\&. .RE .PP map(\fImodule\fR,\fIname\fR) .RS 4 Maps ASN\&.1 type in module \fImodule\fR of \fIname\fR to value\&. .RE .PP membermap(\fImodule\fR,\fIname\fR,\fImember\fR) .RS 4 Maps member \fImember\fR in SEQUENCE/CHOICE of \fIname\fR in module \fImodule\fR to value\&. The value consists of one or two tokens\&. First token is name of C preprocessor part\&. Second token is resulting C member name\&. If second token is omitted the value (one token) is both preprocessor part and C struct,union\&. .RE .PP unionmap(\fImodule\fR,\fIname\fR,\fImember\fR) .RS 4 Maps member \fImember\fR in CHOICE of \fIname\fR in module \fImodule\fR to value\&. Value consists of two or three tokens\&. The first token is name of the integer in the union that is used as selector for the union itself\&. The second token is name of the union\&. The third token overrides the name of the CHOICE member; if omitted the member name is used\&. .RE .SH "FILES" .PP /usr/share/yaz/z39\&.50/z\&.tcl .PP /usr/share/yaz/z39\&.50/*\&.asn .SH "SEE ALSO" .PP \fByaz\fR(7) .PP Section "The ODR Module" in the YAZ manual\&. .SH "AUTHORS" .PP \fBIndex Data\fR yaz-5.37.0/doc/yaz-iconv-man.xml0000644000175000017500000001344115123757344015034 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-iconv 1 Commands yaz-iconv YAZ Character set conversion utility yaz-iconv file DESCRIPTION yaz-iconv converts data in the character set specified by from to output in the character set as specified by to. This yaz-iconv utility is similar to the iconv found on many POSIX systems (Glibc, Solaris, etc). If no file is specified, yaz-iconv reads from standard input. OPTIONS -ffrom] Specify the character set from of the input file. Should be used in conjunction with option -t. -tto] Specify the character set of of the output. Should be used in conjunction with option -f. -v Print more information about the conversion process. ENCODINGS The yaz-iconv command and the API as defined in yaz/yaz-iconv.h is a wrapper for the library system call iconv. But YAZ' iconv utility also implements conversions on its own. The table below lists characters sets (or encodings) that are supported by YAZ. Each character set is marked with either encode or decode. If an encoding is encode-enabled, YAZ may convert to the designated encoding. If an encoding is decode-enabled, YAZ may convert from the designated encoding. marc8 (encode, decode) The MARC8 encoding as defined by the Library of Congress. Most MARC21/USMARC records use this encoding. marc8s (encode, decode) Like MARC8 but conversion prefers non-combined characters in the Latin-1 plane over combined characters. marc8lossy (encode) Lossy encoding of MARC-8. marc8lossless (encode) Lossless encoding of MARC8. utf8 (encode, decode) The most commonly used UNICODE encoding on the Internet. iso8859-1 (encode, decode) ISO-8859-1, AKA Latin-1. iso5426 (decode) ISO 5426. Some MARC records (UNIMARC) use this encoding. iso5428:1984 (encode, decode) ISO 5428:1984. advancegreek (encode, decode) An encoding for Greek in use by some vendors (Advance). danmarc (decode) Danmarc (in danish) is an encoding based on UNICODE which is used for DanMARC2 records. EXAMPLES The following command converts from ISO-8859-1 (Latin-1) to UTF-8. yaz-iconv -f ISO-8859-1 -t UTF-8 <input.lst >output.lst FILES prefix/bin/yaz-iconv prefix/include/yaz/yaz-iconv.h SEE ALSO yaz(7) iconv(1) yaz-5.37.0/doc/yaz-log.html0000644000175000017500000002625715130444232014066 0ustar00adamadamyaz-log
yaz-log
Prev Reference Next

Name

yaz-log — Log handling in all yaz-based programs

Synopsis

yaz-XXXX [-v loglevel,...] [-l logfile]

DESCRIPTION

All YAZ-based programs use a common log subsystem, and should support common command line options for controlling it. This man page documents those.

OPTIONS

-l logfile

Specify the file where the log is to be written. If none is specified, stderr is used. The log is appended to this file. If the file grows overly large, it is silently rotated: It is renamed to logfile.1, logfile.2, .., 9 (old such file is deleted), and a new file is opened. The limit defaults to 1GB, but can be set by the program. The rotating limit can be specified with option -r for the YAZ frontend server (yaz-ztest).

Rotation can also be implicitly enabled by using a filename which gets changed for a given date, due to substitutions as given by the strftime(3) function.

-v loglevel

Specify the logging level. The argument is a set of log level names, separated by commas (no whitespace!), optionally preceded by a '-' to negate that level. Most programs have their own default, often containing fatal,warn,log, and some application-specific values. The default list can be cleared with the word none, or individual bits can be removed by prefixing them with a dash '-'.

LOG LEVELS TO CONTROL LOGGING

Some of the log levels control the way the log is written.

flush causes the log to be flushed after every write. This can have serious implications to performance, and should not be used in production. On the other hand, when debugging a program crash, this can be extremely useful. The option debug implies flush as well.

notime prevents the writing of time stamps. This is intended for automatic test scripts, which should produce predictable log files that are easy to compare.

GENERAL LOG LEVELS IN YAZ ITSELF

YAZ itself uses the following log levels:

fatal for fatal errors, that prevent further execution of the program.

warn for warnings about things that should be corrected.

debug for debugging. This flag may be used temporarily when developing or debugging yaz, or a program that uses yaz. It is practically deprecated, you should be defining and using your own log levels (see below).

all turns on almost all hard-coded log levels.

loglevel logs information about the log levels used by the program. Every time the log level is changed, lists all bits that are on. Every time a module asks for its log bits, this is logged. This can be used for getting an idea of what log levels are available in any program that uses yaz-log. Start the program with -v none,loglevel, and do some common operations with it. Another way is to grep for yaz_log_module_level in the source code, as in 

      find . -name '*.[ch]' -print |
         xargs grep yaz_log_module_level |
         grep '"' |
         cut -d'"' -f2 |
         sort -u

eventl, malloc, nmem, odr are used internally for debugging yaz.

LOG LEVELS FOR CLIENTS

zoom logs the calls to the zoom API, which may be useful in debugging client applications.

LOG LEVELS FOR SERVERS

server logs the server functions on a high level, starting up, listening on a port, etc.

session logs individual sessions (connections).

request logs a one-liner for each request (init, search, etc.).

requestdetail logs the details of every request, before it is passed to the back-end, and the results received from it.

Each server program (zebra, etc.) is supposed to define its own log levels in addition to these. As they depend on the server in question, they can not be described here. See above how to find out about them.

LOGGING EXAMPLES

See what log levels yaz-ztest is using: 

    yaz-ztest -1 -v none,loglevel
    14:43:29-23/11 [loglevel] Setting log level to 4096 = 0x00001000
    14:43:29-23/11 [loglevel] Static  log bit 00000001 'fatal' is off
    14:43:29-23/11 [loglevel] Static  log bit 00000002 'debug' is off
    14:43:29-23/11 [loglevel] Static  log bit 00000004 'warn' is off
    14:43:29-23/11 [loglevel] Static  log bit 00000008 'log' is off
    14:43:29-23/11 [loglevel] Static  log bit 00000080 'malloc' is off
    14:43:29-23/11 [loglevel] Static  log bit 00000800 'flush' is off
    14:43:29-23/11 [loglevel] Static  log bit 00001000 'loglevel' is ON
    14:43:29-23/11 [loglevel] Static  log bit 00002000 'server' is off
    14:43:29-23/11 [loglevel] Dynamic log bit 00004000 'session' is off
    14:43:29-23/11 [loglevel] Dynamic log bit 00008000 'request' is off
    14:44:13-23/11 yaz-ztest [loglevel] returning log bit 0x4000 for 'session'
    14:44:13-23/11 yaz-ztest [loglevel] returning log bit 0x2000 for 'server'
    14:44:13-23/11 yaz-ztest [loglevel] returning NO log bit for 'eventl'
    14:44:20-23/11 yaz-ztest [loglevel] returning log bit 0x4000 for 'session'
    14:44:20-23/11 yaz-ztest [loglevel] returning log bit 0x8000 for 'request'
    14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'requestdetail'
    14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'odr'
    14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'ztest'

See the details of the requests for yaz-ztest 

   ./yaz-ztest -1 -v requestdetail
   14:45:35-23/11 yaz-ztest [server] Adding static Z3950 listener on tcp:@:9999
   14:45:35-23/11 yaz-ztest [server] Starting server ./yaz-ztest pid=32200
   14:45:38-23/11 yaz-ztest [session] Starting session from tcp:127.0.0.1 (pid=32200)
   14:45:38-23/11 yaz-ztest [requestdetail] Got initRequest
   14:45:38-23/11 yaz-ztest [requestdetail] Id:        81
   14:45:38-23/11 yaz-ztest [requestdetail] Name:      YAZ
   14:45:38-23/11 yaz-ztest [requestdetail] Version:   2.0.28
   14:45:38-23/11 yaz-ztest [requestdetail] Negotiated to v3: srch prst del extendedServices namedresults scan sort
   14:45:38-23/11 yaz-ztest [request] Init from 'YAZ' (81) (ver 2.0.28) OK
   14:45:39-23/11 yaz-ztest [requestdetail] Got SearchRequest.
   14:45:39-23/11 yaz-ztest [requestdetail] ResultSet '1'
   14:45:39-23/11 yaz-ztest [requestdetail] Database 'Default'
   14:45:39-23/11 yaz-ztest [requestdetail] RPN query. Type: Bib-1
   14:45:39-23/11 yaz-ztest [requestdetail]  term 'foo' (general)
   14:45:39-23/11 yaz-ztest [requestdetail] resultCount: 7
   14:45:39-23/11 yaz-ztest [request] Search Z: @attrset Bib-1 foo  OK:7 hits
   14:45:41-23/11 yaz-ztest [requestdetail] Got PresentRequest.
   14:45:41-23/11 yaz-ztest [requestdetail] Request to pack 1+1 1
   14:45:41-23/11 yaz-ztest [requestdetail] pms=1048576, mrs=1048576
   14:45:41-23/11 yaz-ztest [request] Present: [1] 1+1  OK 1 records returned

LOG FILENAME EXAMPLES

A file with format my_YYYYMMDD.log (where Y, M, D is year, month, and day digits) is given as follows: -l my_%Y%m%d.log . And since the filename is depending on day, rotation will occur on midnight.

A weekly log could be specified as -l my_%Y%U.log.

FILES

prefix/include/yaz/log.h prefix/src/log.c

SEE ALSO

yaz(7) yaz-ztest(8) yaz-client(1) strftime(3)

Prev Up Next
yaz-iconv Home yaz-illclient
yaz-5.37.0/doc/yaz-iconv.10000644000175000017500000001021215130444226013602 0ustar00adamadam'\" t .\" Title: yaz-iconv .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-ICONV" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-iconv \- YAZ Character set conversion utility .SH "SYNOPSIS" .HP \w'\fByaz\-iconv\fR\ 'u \fByaz\-iconv\fR [\fB\-f\ \fR\fB\fIfrom\fR\fR] [\fB\-t\ \fR\fB\fIto\fR\fR] [\fB\-v\fR] [file...] .SH "DESCRIPTION" .PP \fByaz\-iconv\fR converts data in the character set specified by \fIfrom\fR to output in the character set as specified by \fIto\fR\&. .PP This \fByaz\-iconv\fR utility is similar to the \fBiconv\fR found on many POSIX systems (Glibc, Solaris, etc)\&. .PP If no \fIfile\fR is specified, \fByaz\-iconv\fR reads from standard input\&. .SH "OPTIONS" .PP \-f\fIfrom\fR] .RS 4 Specify the character set \fIfrom\fR of the input file\&. Should be used in conjunction with option \-t\&. .RE .PP \-t\fIto\fR] .RS 4 Specify the character set \fIof\fR of the output\&. Should be used in conjunction with option \-f\&. .RE .PP \-v .RS 4 Print more information about the conversion process\&. .RE .SH "ENCODINGS" .PP The yaz\-iconv command and the API as defined in yaz/yaz\-iconv\&.h is a wrapper for the library system call iconv\&. But YAZ\*(Aq iconv utility also implements conversions on its own\&. The table below lists characters sets (or encodings) that are supported by YAZ\&. Each character set is marked with either \fIencode\fR or \fIdecode\fR\&. If an encoding is encode\-enabled, YAZ may convert \fIto\fR the designated encoding\&. If an encoding is decode\-enabled, YAZ may convert \fIfrom\fR the designated encoding\&. .PP marc8 (encode, decode) .RS 4 The \m[blue]\fBMARC8\fR\m[]\&\s-2\u[1]\d\s+2 encoding as defined by the Library of Congress\&. Most MARC21/USMARC records use this encoding\&. .RE .PP marc8s (encode, decode) .RS 4 Like MARC8 but conversion prefers non\-combined characters in the Latin\-1 plane over combined characters\&. .RE .PP marc8lossy (encode) .RS 4 Lossy encoding of MARC\-8\&. .RE .PP marc8lossless (encode) .RS 4 Lossless encoding of MARC8\&. .RE .PP utf8 (encode, decode) .RS 4 The most commonly used UNICODE encoding on the Internet\&. .RE .PP iso8859\-1 (encode, decode) .RS 4 ISO\-8859\-1, AKA Latin\-1\&. .RE .PP iso5426 (decode) .RS 4 ISO 5426\&. Some MARC records (UNIMARC) use this encoding\&. .RE .PP iso5428:1984 (encode, decode) .RS 4 ISO 5428:1984\&. .RE .PP advancegreek (encode, decode) .RS 4 An encoding for Greek in use by some vendors (Advance)\&. .RE .PP danmarc (decode) .RS 4 \m[blue]\fBDanmarc (in danish)\fR\m[]\&\s-2\u[2]\d\s+2 is an encoding based on UNICODE which is used for DanMARC2 records\&. .RE .SH "EXAMPLES" .PP The following command converts from ISO\-8859\-1 (Latin\-1) to UTF\-8\&. .sp .if n \{\ .RS 4 .\} .nf yaz\-iconv \-f ISO\-8859\-1 \-t UTF\-8 output\&.lst .fi .if n \{\ .RE .\} .sp .SH "FILES" .PP \fIprefix\fR/bin/yaz\-iconv .PP \fIprefix\fR/include/yaz/yaz\-iconv\&.h .SH "SEE ALSO" .PP yaz(7) iconv(1) .SH "AUTHORS" .PP \fBIndex Data\fR .SH "NOTES" .IP " 1." 4 MARC8 .RS 4 \%https://loc.gov/marc/specifications/speccharmarc8.html .RE .IP " 2." 4 Danmarc (in danish) .RS 4 \%https://www.kat-format.dk/danMARC2/Danmarc2.4.htm .RE yaz-5.37.0/doc/yaz-url.10000644000175000017500000000544015130444227013276 0ustar00adamadam'\" t .\" Title: yaz-url .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-URL" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-url \- YAZ URL fetch utility .SH "SYNOPSIS" .HP \w'\fByaz\-url\fR\ 'u \fByaz\-url\fR [\-H\ \fIname:value\fR] [\-m\ \fImethod\fR] [\-O\ \fIfname\fR] [\-p\ \fIfname\fR] [\-R\ \fInum\fR] [\-u\ \fIuser/password\fR] [\-v] [\-x\ \fIproxy\fR] [url...] .SH "DESCRIPTION" .PP \fByaz\-url\fR is utility to get web content\&. It is very limited in functionality compared to programs such as curl, wget\&. .PP The options must precede the URL given on the command line, to take effect\&. .PP Fetched HTTP content is written to stdout, unless option \-O is given\&. .SH "OPTIONS" .PP \-H \fIname:value\fR .RS 4 Specifies HTTP header content with name and value\&. This option can be given multiple times (for different names, of course)\&. .RE .PP \-m \fImethod\fR .RS 4 Specifies the HTTP method to be used for the next URL\&. Default is method "GET"\&. However, option \-p sets it to "POST"\&. .RE .PP \-O \fIfname\fR .RS 4 Sets output filename for HTTP content\&. .RE .PP \-p \fIfname\fR .RS 4 Sets a file to be POSTed in the following URL\&. .RE .PP \-R \fInum\fR .RS 4 Sets maximum number of HTTP redirects to be followed\&. A value of zero disables follow of HTTP redirects\&. .RE .PP \-u \fIuser/password\fR .RS 4 Specifies a user and a password to be used in HTTP basic authentication in the following URL fetch\&. The user and password must be separated by a slash (thus it is not possible to specify a user with a slash in it)\&. .RE .PP \-v .RS 4 Makes yaz\-url dump each HTTP request/response to stdout\&. .RE .PP \-x \fIproxy\fR .RS 4 Specifies a proxy to be used for URL fetch\&. .RE .SH "SEE ALSO" .PP \fByaz\fR(7) .SH "AUTHORS" .PP \fBIndex Data\fR yaz-5.37.0/doc/bib1-diag-table.xml0000644000175000017500000004041515130444224015135 0ustar00adamadam Code Text 1 Permanent system error 2 Temporary system error 3 Unsupported search 4 Terms only exclusion (stop) words 5 Too many argument words 6 Too many boolean operators 7 Too many truncated words 8 Too many incomplete subfields 9 Truncated words too short 10 Invalid format for record number (search term) 11 Too many characters in search statement 12 Too many records retrieved 13 Present request out of range 14 System error in presenting records 15 Record no authorized to be sent intersystem 16 Record exceeds Preferred-message-size 17 Record exceeds Maximum-record-size 18 Result set not supported as a search term 19 Only single result set as search term supported 20 Only ANDing of a single result set as search term supported 21 Result set exists and replace indicator off 22 Result set naming not supported 23 Combination of specified databases not supported 24 Element set names not supported 25 Specified element set name not valid for specified database 26 Only a single element set name supported 27 Result set no longer exists - unilaterally deleted by target 28 Result set is in use 29 One of the specified databases is locked 30 Specified result set does not exist 31 Resources exhausted - no results available 32 Resources exhausted - unpredictable partial results available 33 Resources exhausted - valid subset of results available 100 Unspecified error 101 Access-control failure 102 Security challenge required but could not be issued - request terminated 103 Security challenge required but could not be issued - record not included 104 Security challenge failed - record not included 105 Terminated by negative continue response 106 No abstract syntaxes agreed to for this record 107 Query type not supported 108 Malformed query 109 Database unavailable 110 Operator unsupported 111 Too many databases specified 112 Too many result sets created 113 Unsupported attribute type 114 Unsupported Use attribute 115 Unsupported value for Use attribute 116 Use attribute required but not supplied 117 Unsupported Relation attribute 118 Unsupported Structure attribute 119 Unsupported Position attribute 120 Unsupported Truncation attribute 121 Unsupported Attribute Set 122 Unsupported Completeness attribute 123 Unsupported attribute combination 124 Unsupported coded value for term 125 Malformed search term 126 Illegal term value for attribute 127 Unparsable format for un-normalized value 128 Illegal result set name 129 Proximity search of sets not supported 130 Illegal result set in proximity search 131 Unsupported proximity relation 132 Unsupported proximity unit code 201 Proximity not supported with this attribute combination 202 Unsupported distance for proximity 203 Ordered flag not supported for proximity 205 Only zero step size supported for Scan 206 Specified step size not supported for Scan 207 Cannot sort according to sequence 208 No result set name supplied on Sort 209 Generic sort not supported (database-specific sort only supported) 210 Database specific sort not supported 211 Too many sort keys 212 Duplicate sort keys 213 Unsupported missing data action 214 Illegal sort relation 215 Illegal case value 216 Illegal missing data action 217 Segmentation: Cannot guarantee records will fit in specified segments 218 ES: Package name already in use 219 ES: no such package, on modify/delete 220 ES: quota exceeded 221 ES: extended service type not supported 222 ES: permission denied on ES - id not authorized 223 ES: permission denied on ES - cannot modify or delete 224 ES: immediate execution failed 225 ES: immediate execution not supported for this service 226 ES: immediate execution not supported for these parameters 227 No data available in requested record syntax 228 Scan: malformed scan 229 Term type not supported 230 Sort: too many input results 231 Sort: incompatible record formats 232 Scan: term list not supported 233 Scan: unsupported value of position-in-response 234 Too many index terms processed 235 Database does not exist 236 Access to specified database denied 237 Sort: illegal sort 238 Record not available in requested syntax 239 Record syntax not supported 240 Scan: Resources exhausted looking for satisfying terms 241 Scan: Beginning or end of term list 242 Segmentation: max-segment-size too small to segment record 243 Present: additional-ranges parameter not supported 244 Present: comp-spec parameter not supported 245 Type-1 query: restriction ('resultAttr') operand not supported 246 Type-1 query: 'complex' attributeValue not supported 247 Type-1 query: 'attributeSet' as part of AttributeElement not supported 1001 Malformed APDU 1002 ES: EXTERNAL form of Item Order request not supported 1003 ES: Result set item form of Item Order request not supported 1004 ES: Extended services not supported unless access control is in effect 1005 Response records in Search response not supported 1006 Response records in Search response not possible for specified database (or database combination) 1007 No Explain server. Addinfo: pointers to servers that have a surrogate Explain database for this server 1008 ES: missing mandatory parameter for specified function. Addinfo: parameter 1009 ES: Item Order, unsupported OID in itemRequest. Addinfo: OID 1010 Init/AC: Bad Userid 1011 Init/AC: Bad Userid and/or Password 1012 Init/AC: No searches remaining (pre-purchased searches exhausted) 1013 Init/AC: Incorrect interface type (specified id valid only when used with a particular access method or client) 1014 Init/AC: Authentication System error 1015 Init/AC: Maximum number of simultaneous sessions for Userid 1016 Init/AC: Blocked network address 1017 Init/AC: No databases available for specified userId 1018 Init/AC: System temporarily out of resources 1019 Init/AC: System not available due to maintenance 1020 Init/AC: System temporarily unavailable (Addinfo: when it's expected back up) 1021 Init/AC: Account has expired 1022 Init/AC: Password has expired so a new one must be supplied 1023 Init/AC: Password has been changed by an administrator so a new one must be supplied 1024 Unsupported Attribute 1025 Service not supported for this database 1026 Record cannot be opened because it is locked 1027 SQL error 1028 Record deleted 1029 Scan: too many terms requested. Addinfo: max terms supported 1040 ES: Invalid function 1041 ES: Error in retention time 1042 ES: Permissions data not understood 1043 ES: Invalid OID for task specific parameters 1044 ES: Invalid action 1045 ES: Unknown schema 1046 ES: Too many records in package 1047 ES: Invalid wait action 1048 ES: Cannot create task package -- exceeds maximum permissible size 1049 ES: Cannot return task package -- exceeds maximum permissible size 1050 ES: Extended services request too large 1051 Scan: Attribute set id required -- not supplied 1052 ES: Cannot process task package record -- exceeds maximum permissible record size for ES 1053 ES: Cannot return task package record -- exceeds maximum permissible record size for ES response 1054 Init: Required negotiation record not included 1055 Init: negotiation option required 1056 Attribute not supported for database 1057 ES: Unsupported value of task package parameter 1058 Duplicate Detection: Cannot dedup on requested record portion 1059 Duplicate Detection: Requested detection criterion not supported 1060 Duplicate Detection: Requested level of match not supported 1061 Duplicate Detection: Requested regular expression not supported 1062 Duplicate Detection: Cannot do clustering 1063 Duplicate Detection: Retention criterion not supported 1064 Duplicate Detection: Requested number (or percentage) of entries 1065 Duplicate Detection: Requested sort criterion not supported 1066 CompSpec: Unknown schema, or schema not supported. 1067 Encapsulation: Encapsulated sequence of PDUs not supported 1068 Encapsulation: Base operation (and encapsulated PDUs) not executed based on pre-screening analysis 1069 No syntaxes available for this request 1070 user not authorized to receive record(s) in requested syntax 1071 preferredRecordSyntax not supplied 1072 Query term includes characters that do not translate into the target character set 1073 Database records do not contain data associated with access point 1074 Proxy failure yaz-5.37.0/doc/zoom.events.html0000644000175000017500000000772115130444232014766 0ustar00adamadam10. Events
10. Events
Prev Chapter 3. ZOOM Next

10. Events

If you're developing non-blocking applications, you have to deal with events. 

    int ZOOM_event(int no, ZOOM_connection *cs);

The ZOOM_event executes pending events for a number of connections. Supply the number of connections in no and an array of connections in cs (cs[0] ... cs[no-1]). A pending event could be sending a search, receiving a response, etc. When an event has occurred for one of the connections, this function returns a positive integer n denoting that an event occurred for connection cs[n-1]. When no events are pending for the connections, a value of zero is returned. To ensure that all outstanding requests are performed, call this function repeatedly until zero is returned.

If ZOOM_event returns, and returns non-zero, the last event that occurred can be expected. 

    int ZOOM_connection_last_event(ZOOM_connection cs);

ZOOM_connection_last_event returns an event type (integer) for the last event.

Table 3.13. ZOOM Event IDs

EventDescription
ZOOM_EVENT_NONENo event has occurred
ZOOM_EVENT_CONNECTTCP/IP connect has initiated
ZOOM_EVENT_SEND_DATAData has been transmitted (sending)
ZOOM_EVENT_RECV_DATAData has been received
ZOOM_EVENT_TIMEOUTTimeout
ZOOM_EVENT_UNKNOWNUnknown event
ZOOM_EVENT_SEND_APDUAn APDU has been transmitted (sending)
ZOOM_EVENT_RECV_APDUAn APDU has been received
ZOOM_EVENT_RECV_RECORDA result-set record has been received
ZOOM_EVENT_RECV_SEARCHA search result has been received

Prev Up Next
9. Query conversions Home Chapter 4. Generic server
yaz-5.37.0/doc/yaz.html0000644000175000017500000001075615130444232013304 0ustar00adamadamyaz
yaz
Prev Reference Next

Name

yaz — Z39.50 toolkit.

DESCRIPTION

YAZ is a C/C++ programmer's toolkit supporting the development of Z39.50v3 clients and servers. The YAZ toolkit offers several different levels of access to the ISO23950/Z39.50, SRU Solr (client only) and ILL protocols. The level that you need to use depends on your requirements, and the role (server or client) that you want to implement.

COPYRIGHT

Copyright © 1995-2026 Index Data.

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

  • Neither the name of Index Data nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

SEE ALSO

yaz-client(1), yaz-ztest(8), yaz-config(8), zoomsh(1) bib1-attr(7)

YAZ manual ( /usr/share/doc/yaz)

YAZ home page.

Z39.50 Maintenance Agency Page.

Prev Up Next
yaz-config Home zoomsh
yaz-5.37.0/doc/sorting.html0000644000175000017500000001160015130444232014153 0ustar00adamadam7. Sorting
7. Sorting
Prev Chapter 7. Supporting Tools Next

7. Sorting

This chapter describes sorting and how it is supported in YAZ. Sorting applies to a result-set. The Z39.50 sorting facility takes one or more input result-sets and one result-set as output. The most simple case is that the input-set is the same as the output-set.

Z39.50 sorting has a separate APDU (service) that is, thus, performed following a search (two phases).

In SRU/Solr, however, the model is different. Here, sorting is specified during the search operation. Note, however, that SRU might perform sort as separate search, by referring to an existing result-set in the query (result-set reference).

7.1. Using the Z39.50 sort service

yaz-client and the ZOOM API support the Z39.50 sort facility. In any case the sort sequence or sort criteria is using a string notation. This notation is a one-line notation suitable for being manually entered or generated, and allows for easy logging (one liner). For the ZOOM API, the sort is specified in the call to ZOOM_query_sortby function. For yaz-client the sort is performed and specified using the sort and sort+ commands. For description of the sort criteria notation refer to the sort command in the yaz-client manual.

The ZOOM API might choose one of several sort strategies for sorting. Refer to Table 3.2, “ZOOM sort strategy”.

7.2. Type-7 sort

Type-7 sort is an extension to the Bib-1 based RPN query where the sort specification is embedded as an Attribute-Plus-Term.

The objectives for introducing Type-7 sorting is that it allows a client to perform sorting even if it does not implement/support Z39.50 sort. Virtually all Z39.50 client software supports RPN queries. It also may improve performance because the sort criteria is specified along with the search query.

The sort is triggered by the presence of type 7, and the value of type 7 specifies the sortRelation . The value for type 7 is 1 for ascending and 2 for descending. For the sortElement only the generic part is handled. If generic sortKey is of type sortField, then attribute type 1 is present and the value is sortField (InternationalString). If generic sortKey is of type sortAttributes, then the attributes in the list are used. Generic sortKey of type elementSpec is not supported.

The term in the sorting Attribute-Plus-Term combo should hold an integer. The value is 0 for primary sorting criteria, 1 for second criteria, etc.

Prev Up Next
6. Retrieval Facility Home 8. Facets
yaz-5.37.0/doc/book.xml0000644000175000017500000135133715127270670013304 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ User's Guide and Reference SebastianHammer AdamDickmeiss MikeTaylor HeikkiLevanto DennisSchafroth JakubSkoczen &version; ©right-year; Index Data This document is the programmer's guide and reference to the &yaz; package version &version;. &yaz; is a compact toolkit that provides access to the Z39.50 and SRU/Solr protocols, as well as a set of higher-level tools for implementing the server and client roles, respectively. The documentation can be used on its own, or as a reference when looking at the example applications provided with the package. Introduction &yaz; is a C/C++ library for information retrieval applications using the Z39.50/SRU/Solr protocols for information retrieval. Properties of &yaz;: Complete Z39.50 version 3 support. Amendments and Z39.50-2002 revision is supported. Supports SRU GET/POST/SOAP version 1.1, 1.2 and 2.0 (over HTTP and HTTPS). Includes BER encoders/decoders for the ISO ILL protocol. Supports Apache Solr Web Service version 1.4.x (client side only) Supports the following transports: BER over TCP/IP (RFC1729), BER over Unix local socket, and HTTP 1.1. Secure Socket Layer support using GnuTLS. If enabled, &yaz; uses HTTPS transport (for SOAP) or "Secure BER" (for Z39.50). Offers ZOOM C API implementing Z39.50, SRU and Solr Web Service. The &yaz; library offers a set of useful utilities related to the protocols, such as MARC (ISO2709) parser, CCL (ISO8777) parser, CQL parser, memory management routines, character set conversion. Portable code. &yaz; compiles out-of-the box on most Unixes and on Windows using Microsoft Visual C++. Fast operation. The C based BER encoders/decoders as well as the server component of &yaz; is very fast. Liberal license that allows for commercial use of &yaz;. Reading this Manual Most implementors only need to read a fraction of the material in this manual, so a quick walk-through of the chapters is in order. contains installation instructions for &yaz;. You don't need to read this if you expect to download &yaz; binaries. However, the chapter contains information about how to make your application link with &yaz;. describes the ZOOM API of &yaz;. This is definitely worth reading if you wish to develop a Z39.50/SRU client. describes the generic front-end server and explains how to develop server Z39.50/SRU applications for &yaz;. Obviously worth reading if you're to develop a server. describes how to use the &yaz; Z39.50 client. If you're a developer and wish to test your server or a server from another party, you might find this chapter useful. documents the most commonly used Z39.50 C data structures offered by the &yaz; API. Client developers using ZOOM and non-Z39.50 implementors may skip this. describes how SRU and SOAP is used in &yaz;. Only if you're developing SRU applications this section is a must. contains sections for the various tools offered by &yaz;. Scan through the material quickly and see what's relevant to you! SRU implementors might find the CQL section particularly useful. goes through the details of the ODR module which is the work horse that encodes and decodes BER packages. Implementors using ZOOM only, do not need to read this. Most other Z39.50 implementors only need to read the first two sections ( and ). describes the network layer module COMSTACK. Implementors using ZOOM or the generic front-end server may skip this. Others, presumably, handling client/server communication on their own should read this. The API The &yaz; toolkit offers several different levels of access to the ISO23950/Z39.50, ILL and SRU protocols. The level that you need to use depends on your requirements, and the role (server or client) that you want to implement. If you're developing a client application you should consider the ZOOM API. It is, by far, the easiest way to develop clients in C. Server implementors should consider the generic front-end server. None of those high-level APIs support the whole protocol, but they do include most facilities used in existing Z39.50 applications. If you're using 'exotic' functionality (meaning anything not included in the high-level APIs), developing non-standard extensions to Z39.50 or you're going to develop an ILL application, you'll have to learn the lower level APIs of &yaz;. The YAZ toolkit modules are shown in figure .
YAZ layers
There are four layers. A client or server application (or both). This layer includes ZOOM and the generic front-end server. The second layer provides a C representation of the protocol units (packages) for Z39.50 ASN.1, ILL ASN.1, SRU. The third layer encodes and decodes protocol data units to simple packages (buffer with certain length). The &odr; module encodes and decodes BER whereas the HTTP modules encodes and decodes HTTP requests/responses. The lowest layer is &comstack; which exchanges the encoded packages with a peer process over a network. The &asn; module represents the ASN.1 definition of the Z39.50 protocol. It establishes a set of type and structure definitions, with one structure for each of the top-level PDUs, and one structure or type for each of the contained ASN.1 types. For primitive types, or other types that are defined by the ASN.1 standard itself (such as the EXTERNAL type), the C representation is provided by the &odr; (Open Data Representation) subsystem. &odr; is a basic mechanism for representing an ASN.1 type in the C programming language, and for implementing BER encoders and decoders for values of that type. The types defined in the &asn; module generally have the prefix Z_, and a suffix corresponding to the name of the type in the ASN.1 specification of the protocol (generally Z39.50-1995). In the case of base types (those originating in the ASN.1 standard itself), the prefix Odr_ is sometimes seen. Either way, look for the actual definition in either z-core.h (for the types from the protocol), odr.h (for the primitive ASN.1 types). The &asn; library also provides functions (which are, in turn, defined using &odr; primitives) for encoding and decoding data values. Their general form is int z_xxx ODR o Z_xxx **p int optional const char *name (note the lower-case "z" in the function name) If you are using the premade definitions of the &asn; module, and you are not adding a new protocol of your own, the only parts of &odr; that you need to worry about are documented in . When you have created a BER-encoded buffer, you can use the &comstack; subsystem to transmit (or receive) data over the network. The &comstack; module provides simple functions for establishing a connection (passively or actively, depending on the role of your application), and for exchanging BER-encoded PDUs over that connection. When you create a connection endpoint, you need to specify what transport to use (TCP/IP, SSL or UNIX sockets). For the remainder of the connection's lifetime, you don't have to worry about the underlying transport protocol at all - the &comstack; will ensure that the correct mechanism is used. We call the combined interfaces to &odr;, &asn;, and &comstack; the service level API. It's the API that most closely models the Z39.50 service/protocol definition, and it provides unlimited access to all fields and facilities of the protocol definitions. The reason that the &yaz; service-level API is a conglomerate of the APIs from three different sub-modules is twofold. First, we wanted to allow the user a choice of different options for each major task. For instance, if you don't like the protocol API provided by &odr;/&asn;, you can use SNACC or BERUtils instead, and still have the benefits of the transparent transport approach of the &comstack; module. Secondly, we realize that you may have to fit the toolkit into an existing event-processing structure, in a way that is incompatible with the &comstack; interface or some other part of &yaz;. Compilation and Installation Introduction The latest version of the software will generally be found at: We have tried our best to keep the software portable, and on many platforms, you should be able to compile everything with little or no changes. The software is regularly tested on Debian GNU/Linux, CentOS, Ubuntu Linux, FreeBSD (i386), MAC OSX, Windows 10. Some versions have be known to work on Windows XP, Solaris, HP/UX, DEC Unix, NetBSD, OpenBSD, IBM AIX, Data General DG/UX (with some CFLAGS tinkering), SGI/IRIX, DDE Supermax, Apple Macintosh (using the Codewarrior programming environment and the GUSI socket libraries), IBM AS/400 . If you move the software to other platforms, we'd be grateful if you'd let us know about it. If you run into difficulties, we will try to help if we can, and if you solve the problems, we would be happy to include your fixes in the next release. So far, we have mostly avoided #ifdefs for individual platforms, and we'd like to keep it that way as far as it makes sense. Use GitHub Discussions for questions and discussions about &yaz;. General questions and problems can be directed to . UNIX/macOS We provide Debian GNU/Linux (i386 and amd64), Ubuntu (i386 and amd64) and CentOS (amd64 only) packages for &yaz;. You should be able to create packages for other CPUs by building them from the source package. YAZ is also part of several packages repositories. Some of them are Solaris CSW: Solaris: FreeBSD: Debian: Ubuntu: NetBSD: Compiling from source on Unix You can choose to compile YAZ from official tar releases from or clone it via GitHub . If you wish to use character set conversion facilities in &yaz; or if you are compiling &yaz; for use with Zebra, it is a good idea to ensure that the iconv library is installed. Some Unixes today already have it - if not, we suggest GNU libiconv. YAZ 3.0.16 and later includes a wrapper for the ICU (International Components for Unicode). In order to use this, the developer version of the ICU library must be available. ICU support is recommended for applications such as Pazpar2 and Zebra. The libxslt, libxml2 libraries are required if &yaz; is to support SRU/Solr. These libraries are very portable and should compile out-of-the box on virtually all Unix platforms. It is available in binary forms for Linux and others. The GNU tools Autoconf, Automake and Libtool are used to generate Makefiles and configure &yaz; for the system. You do not need these tools unless you're using the Git version of &yaz;. The CQL parser for &yaz; is built using GNU Bison. This tool is only needed if you're using the Git version of &yaz;. &yaz; includes a tiny ASN.1 compiler. This compiler is written in Tcl. But as for Bison you do not need it unless you're using Git version of &yaz; or you're using the compiler to build your own codecs for private ASN.1. If you are checking out from Git, run: ./buildconf.sh This will create the configure script and Makefiles. The next step is always: ./configure The configure script attempts to use use the C compiler specified by the CC environment variable. If not set, GNU C will be used if it is available. The CFLAGS environment variable holds options to be passed to the C compiler. If you're using Bourne-compatible shell, you may pass something like this to use a particular C compiler with optimization enabled: CC=/opt/ccs/bin/cc CFLAGS=-O ./configure To customize &yaz;, the configure script also accepts a set of options. The most important are: --prefix=prefix Specifies installation prefix for &yaz;. This is only needed if you run make install later to perform a "system" installation. The prefix is /usr/local if not specified. --enable-tcpd The front end server will be built using Wietse's TCP wrapper library. It allows you to allow/deny clients depending on IP number. The TCP wrapper library is often used in GNU/Linux and BSD distributions. See hosts_access 5 and tcpd 8 . --enable-threads &yaz; will be built using POSIX threads. Specifically, _REENTRANT will be defined during compilation. --disable-shared The make process will not create shared libraries (also known as shared objects .so). By default, shared libraries are created - equivalent to --enable-shared. --disable-shared The make process will not create static libraries (.a). By default, static libraries are created - equivalent to --enable-static. --with-iconv[=prefix] Compile &yaz; with iconv library in directory prefix. By default configure will search for iconv on the system. Use this option if it doesn't find iconv. Alternatively, --without-iconv, can be used to force &yaz; not to use iconv. --with-xslt[=prefix] Compile &yaz; with libxslt in directory prefix. Use this option if you want XSLT and XML support. By default, configure will search for libxslt on the system. Use this option if libxslt is not found automatically. Alternatively, --without-xslt, can be used to force &yaz; not to use libxslt. --with-xml2[=prefix] Compile &yaz; with libxml2 in directory prefix. Use this option if you want &yaz; to use XML and support SRU/Solr. By default, configure will search for libxml2 on the system. Use this option if libxml2 is not found automatically. Alternatively, --without-xml2, can be used to force &yaz; not to use libxml2. Note that option --with-xslt also enables libxml2. --with-gnutls[=prefix] &yaz; will be linked with the GNU TLS libraries and an SSL COMSTACK will be provided. By default configure enables SSL support for YAZ if the GNU TLS development libraries are found on the system. --with-icu[=prefix] &yaz; will be linked the ICU library in the prefix if given. If prefix is not given, the libraries exposed by the script icu-config will be used if found. --with-memcached &yaz; will be linked with libMemcached to allow for result-set caching for ZOOM. The prefix can not be given. Note that 0.40 of libmemcached is required. --with-redis &yaz; will be linked with the hiredis C library to allow for result-set caching for ZOOM on a redis server. The prefix can not be given. When configured, build the software by typing: make The following files are generated by the make process: src/libyaz.la Main &yaz; library. This is no ordinary library. It's a Libtool archive. By default, &yaz; creates a static library in lib/.libs/libyaz.a. src/libyaz_server.la Generic Frontend server. This is an add-on for libyaz.la. Code in this library uses POSIX threads functions - if POSIX threads are available on the platform. src/libyaz_icu.la Functions that wrap the ICU library. ztest/yaz-ztest Test Z39.50 server. client/yaz-client Z39.50 client for testing the protocol. See chapter YAZ client for more information. util/yaz-config A Bourne-shell script, generated by configure, that specifies how external applications should compile - and link with &yaz;. util/yaz-asncomp The ASN.1 compiler for &yaz;. Requires the Tcl Shell, tclsh, in PATH to operate. util/yaz-iconv This program converts data in one character set to another. This command exercises the YAZ character set conversion API. util/yaz-marcdump This program parses ISO2709 encoded MARC records and prints them in line-format or XML. util/yaz-icu This program exposes the ICU wrapper library if that is enabled for YAZ. Only if ICU is available this program is useful. util/yaz-url This program is a simple HTTP page fetcher ala wget or curl. zoom/zoomsh A simple shell implemented on top of the ZOOM functions. The shell is a command line application that allows you to enter simple commands to perform ZOOM operations. zoom/zoomtst1, zoom/zoomtst2, .. Several small applications that demonstrate the ZOOM API. If you wish to install &yaz; in system directories /usr/local/bin, /usr/local/lib .. etc, you can type: make install You probably need to have root access in order to perform this. You must specify the --prefix option for configure if you wish to install &yaz; in other directories than the default /usr/local/. If you wish to perform an un-installation of &yaz;, use: make uninstall This will only work if you haven't reconfigured &yaz; (and therefore changed installation prefix). Note that uninstall will not remove directories created by make install, e.g. /usr/local/include/yaz. Compiling from source on macOS Install Apple's Xcode Command Line Tools (XCLT) package from Apple Developer which provides necessary tools for building C/C++ programs on macOS. You can also try to install it from the command line with: xcode-select --install Out of the box, XCLT is sufficient for compiling basic &yaz; from the source distribution tarball with XML support as it includes libxml2 and libxslt development headers. For ICU support, you can fetch Apple's source distribution from GitHub: git clone https://github.com/apple-oss-distributions/ICU.git and compile &yaz; with: export ICU_CPPFLAGS="-DYAZ_HAVE_ICU=1 -I../../ICU/icu/icu4c/source/common -I../../ICU/icu/icu4c/source/i18n" export ICU_LIBS=" -licucore" ./configure make For SSL support, &yaz; requires GnuTLS and cannot be compiled with LibreSSL/OpenSSL shipped with macOS (see below). If you are compiling &yaz; from a Git checkout, at the time of writing XCLT includes GNU Bison v2.3 which is too old to generate &yaz; sources. You can use e.g. Homebrew to install a more recent version: brew install bison After installation make sure to put it on the path: export PATH="/opt/homebrew/opt/bison/bin:$PATH" Note: XCLT 15.4 fails to make gm4 available as m4 which can cause a silent Bison failure, one way to fix it is: sudo ln -s /Library/Developer/CommandLineTools/usr/bin/gm4 \ /Library/Developer/CommandLineTools/usr/bin/m4 Additionally, you will need to install DocBook stylesheets to generate documentation: brew install docbook docbook-xsl per the caveats section (brew info docbook), for the compilation to find them, add: export XML_CATALOG_FILES="/opt/homebrew/etc/xml/catalog" To compile &yaz; with SSL support, install GnuTLS with: brew install gnutls Homebrew makes GnuTLS discoverable by pkg-config, so no additional flags are needed when configuring &yaz;. You may also want to compile &yaz; with Homebrew's ICU: brew install icu4c but make sure to add compiler flags before the configure stage, per the caveats section (brew info icu4c): export LDFLAGS="-L/opt/homebrew/opt/icu4c/lib" export CPPFLAGS="-I/opt/homebrew/opt/icu4c/include" export PKG_CONFIG_PATH="/opt/homebrew/opt/icu4c/lib/pkgconfig" Additionally, if you want to compile &yaz; with a more recent version of libxml2 and libxslt, you can install them with Homebrew: brew install libxml2 libxslt and, again, make sure to add compiler flags, per the caveats section (brew info libxml2): export PATH="/opt/homebrew/opt/bison/bin:\ /opt/homebrew/opt/libxml2/bin:\ /opt/homebrew/opt/libxslt/bin:\ $PATH" export LDFLAGS="-L/opt/homebrew/opt/libxml2/lib \ -L/opt/homebrew/opt/libxslt/lib \ -L/opt/homebrew/opt/icu4c/lib" export CPPFLAGS="-I/opt/homebrew/opt/libxml2/include \ -I/opt/homebrew/opt/libxslt/include \ -I/opt/homebrew/opt/icu4c/include" export PKG_CONFIG_PATH="/opt/homebrew/opt/libxml2/lib/pkgconfig:\ /opt/homebrew/opt/libxslt/lib/pkgconfig:\ /opt/homebrew/opt/icu4c/lib/pkgconfig" Then configure and conpile with: ./configure make How to make apps using YAZ on UNIX This section describes how to compile - and link your own applications using the &yaz; toolkit. If you're used to Makefiles this shouldn't be hard. As for other libraries you have used before, you need to set a proper include path for your C/C++ compiler and specify the location of &yaz; libraries. You can do it by hand, but generally we suggest you use the yaz-config that is generated by configure. This is especially important if you're using the threaded version of &yaz; which require you to pass more options to your linker/compiler. The yaz-config script accepts command line options that makes the yaz-config script print options that you should use in your make process. The most important ones are: --cflags, --libs which prints C compiler flags, and linker flags respectively. A small and complete Makefile for a C application consisting of one source file, myprog.c, may look like this: YAZCONFIG=/usr/local/bin/yaz-config CFLAGS=`$(YAZCONFIG) --cflags` LIBS=`$(YAZCONFIG) --libs` myprog: myprog.o $(CC) $(CFLAGS) -o myprog myprog.o $(LIBS) The CFLAGS variable consists of a C compiler directive that will set the include path to the parent directory of yaz. That is, if &yaz; header files were installed in /usr/local/include/yaz, then include path is set to /usr/local/include. Therefore, in your applications you should use #include <yaz/proto.h> and not #include <proto.h> For Libtool users, the yaz-config script provides a different variant of option --libs, called --lalibs that returns the name of the Libtool archive(s) for &yaz; rather than the ordinary ones. For applications using the threaded version of &yaz;, specify threads after the other options. When threads is given, more flags and linker flags will be printed by yaz-config. If our previous example was using threads, you'd have to modify the lines that set CFLAGS and LIBS as follows: CFLAGS=`$(YAZCONFIG) --cflags threads` LIBS=`$(YAZCONFIG) --libs threads` There is no need specify POSIX thread libraries in your Makefile. The LIBS variable includes that as well. Windows The easiest way to install YAZ on Windows is by downloading an installer from Index Data's Windows support area . The installer comes with source too - in case you wish to compile YAZ with different compiler options, etc. Compiling from Source on Windows &yaz; is shipped with "makefiles" for the NMAKE tool that comes with Microsoft Visual Studio. It has been tested with Microsoft Visual Studio 2019 and 2022. Start a command prompt and switch the sub directory WIN where the file makefile is located. Customize the installation by editing the makefile file (for example by using notepad). The following summarizes the most important settings in that file: DEBUG If set to 1, the software is compiled with debugging libraries (code generation is multi-threaded debug DLL). If set to 0, the software is compiled with release libraries (code generation is multi-threaded DLL). HAVE_TCL, TCL If HAVE_TCL is set to 1, nmake will use the ASN.1 compiler (Tcl based). You must set TCL to the full path of the Tcl interpreter. A Windows version of Tcl is part of Git for Windows. If you do not have Tcl installed, set HAVE_TCL to 0. HAVE_BISON, BISON If GNU Bison is present, you might set HAVE_BISON to 1 and specify the Bison executable in BISON. Bison is only required if you use the Git version of YAZ or if you modify the grammar for CQL (cql.y). A Windows version of GNU Bison can be fetched from here: Index Data's Windows support area . HAVE_ICONV, ICONV_DIR If HAVE_ICONV is set to 1, YAZ is compiled with iconv support. In this configuration, set ICONV_DIR to the iconv source directory. HAVE_LIBXML2, LIBXML2_DIR If HAVE_LIBXML2 is set to 1, YAZ is compiled with SRU support. In this configuration, set LIBXML2_DIR to the libxml2 source directory. You can get pre-compiled Libxml2+Libxslt DLLs and headers from here. Should you with to compile those libraries yourself, refer to to HAVE_LIBXSLT, LIBXSLT_DIR If HAVE_LIBXSLT is set to 1, YAZ is compiled with XSLT support. In this configuration, set LIBXSLT_DIR to the libxslt source directory. libxslt depends on libxml2. HAVE_ICU, ICU_DIR If HAVE_ICU is set to 1, YAZ is compiled with ICU support. In this configuration, set ICU_DIR to the ICU source directory. Pre-compiled ICU libraries for various versions of Visual Studio can be found here or from Index Data's Windows support site. When satisfied with the settings in the makefile, type nmake If the nmake command is not found on your system you probably haven't defined the environment variables required to use that tool. To fix that, find and run the batch file vcvarsall.bat. You need to run it from within the command prompt or set the environment variables "globally"; otherwise it doesn't work. If you wish to recompile &yaz; - for example if you modify settings in the makefile you can delete object files, etc by running. nmake clean The following files are generated upon successful compilation: bin/yaz&soversion;.dll / bin/yaz&soversion;d.dll &yaz; Release/Debug DLL. lib/yaz&soversion;.lib / lib/yaz&soversion;d.lib Import library for yaz&soversion;.dll / yaz&soversion;d.dll. bin/yaz_cond&soversion;.dll / bin/yaz_cond&soversion;d.dll Release/Debug DLL for condition variable utilities (condvar.c). lib/yaz_cond&soversion;.lib / lib/yaz_cond&soversion;d.lib Import library for yaz_cond&soversion;.dll / yaz_cond&soversion;d.dll. bin/yaz_icu&soversion;.dll / bin/yaz_icu&soversion;d.dll Release/Debug DLL for the ICU wrapper utility. Only build if HAVE_ICU is 1. lib/yaz_icu&soversion;.lib / lib/yaz_icu&soversion;d.lib Import library for yaz_icu&soversion;.dll / yaz_icu&soversion;d.dll. bin/yaz-ztest.exe Z39.50 multi-threaded test/example server. It's a WIN32 console application. bin/yaz-client.exe &yaz; Z39.50 client application. It's a WIN32 console application. See chapter YAZ client for more information. bin/yaz-icu.exe This program exposes the ICU wrapper library if that is enabled for YAZ. Only if ICU is available this program is built. bin/zoomsh.exe Simple console application implemented on top of the ZOOM functions. The application is a command line shell that allows you to enter simple commands to perform ZOOM operations. bin/zoomtst1.exe, bin/zoomtst2.exe, .. Several small applications that demonstrate the ZOOM API. How to make apps using YAZ on Windows This section will go though the process of linking your Windows applications with &yaz;. Some people are confused by the fact that we use the nmake tool to build &yaz;. They think they have to do that too - in order to make their Windows applications work with &yaz;. The good news is that you don't have to. You can use the integrated environment of Visual Studio if desired for your own application. When setting up a project or Makefile you have to set the following: include path Set it to the include directory of &yaz;. import library yaz&soversion;.lib You must link with this library. It's located in the sub directory lib of &yaz;. If you want to link with the debug version of &yaz;, you must link against yaz&soversion;d.lib instead. dynamic link library yaz&soversion;.dll This DLL must be in your execution path when you invoke your application. Specifically, you should distribute this DLL with your application. Compiling Libxml2 and Libxslt on windows Download libxml2 and Libxslt source and unpack it. In the example below we install Libxml2 2.9.2 and Libxslt 1.1.28 for 32-bit, so we use the destination directories libxml2.2.9.2.win32 and libxslt-1.1.28.win32 to reflect both version and architecture. cd win32 cscript configure.js prefix=c:\libxml2-2.9.2.win32 iconv=no nmake nmake install There's an error in configure.js for Libxml2 2.9.2. Line 17 should be assigned to configure.ac rather than configure.in. For Libxslt it is similar. We must ensure that compilation of Libxslt links against the already installed libxml2. cd win32 cscript configure.js prefix=c:\libxslt-1.1.28.win32 iconv=no \ lib=c:\libxml2-2.9.2.win32\lib \ include=c:\libxml2-2.9.2.win32\include\libxml2 nmake nmake install ZOOM &zoom; is an acronym for 'Z39.50 Object-Orientation Model' and is an initiative started by Mike Taylor (Mike is from the UK, which explains the peculiar name of the model). The goal of &zoom; is to provide a common Z39.50 client API not bound to a particular programming language or toolkit. From YAZ version 2.1.12, SRU is supported. You can make SRU ZOOM connections by specifying scheme http:// for the hostname for a connection. The dialect of SRU used is specified by the value of the connection's sru option, which may be SRU over HTTP GET (get), SRU over HTTP POST (post), (SRU over SOAP) (soap) or solr (Solr Web Service). Using the facility for embedding options in target strings, a connection can be forced to use SRU rather the SRW (the default) by prefixing the target string with sru=get,, like this: sru=get,http://sru.miketaylor.org.uk:80/sru.pl Solr protocol support was added to YAZ in version 4.1.0, as a dialect of a SRU protocol, since both are HTTP based protocols. The lack of a simple Z39.50 client API for &yaz; has become more and more apparent over time. So when the first &zoom; specification became available, an implementation for &yaz; was quickly developed. For the first time, it is now as easy (or easier!) to develop clients as it is to develop servers with &yaz;. This chapter describes the &zoom; C binding. Before going further, please reconsider whether C is the right programming language for the job. There are other language bindings available for &yaz;, and still more are in active development. See the ZOOM web-site for more information. In order to fully understand this chapter you should read and try the example programs zoomtst1.c, zoomtst2.c, .. in the zoom directory. The C language misses features found in object oriented languages such as C++, Java, etc. For example, you'll have to manually, destroy all objects you create, even though you may think of them as temporary. Most objects have a _create - and a _destroy variant. All objects are in fact pointers to internal stuff, but you don't see that because of typedefs. All destroy methods should gracefully ignore a NULL pointer. In each of the sections below you'll find a sub section called protocol behavior, that describes how the API maps to the Z39.50 protocol. Connections The Connection object is a session with a target. #include <yaz/zoom.h> ZOOM_connection ZOOM_connection_new(const char *host, int portnum); ZOOM_connection ZOOM_connection_create(ZOOM_options options); void ZOOM_connection_connect(ZOOM_connection c, const char *host, int portnum); void ZOOM_connection_destroy(ZOOM_connection c); Connection objects are created with either function ZOOM_connection_new or ZOOM_connection_create. The former creates and automatically attempts to establish a network connection with the target. The latter doesn't establish a connection immediately, thus allowing you to specify options before establishing network connection using the function ZOOM_connection_connect. If the port number, portnum, is zero, the host is consulted for a port specification. If no port is given, 210 is used. A colon denotes the beginning of a port number in the host string. If the host string includes a slash, the following part specifies a database for the connection. You can prefix the host with a scheme followed by colon. The default scheme is tcp (Z39.50 protocol). The scheme http selects SRU/SOAP over HTTP by default, but can be changed with option sru. You can prefix the scheme-qualified host-string with one or more comma-separated key=value sequences, each of which represents an option to be set into the connection structure before the protocol-level connection is forged and the initialization handshake takes place. This facility can be used to provide authentication credentials, as in host-strings such as: user=admin,password=halfAm4n,tcp:localhost:8017/db Connection objects should be destroyed using the function ZOOM_connection_destroy. void ZOOM_connection_option_set(ZOOM_connection c, const char *key, const char *val); void ZOOM_connection_option_setl(ZOOM_connection c, const char *key, const char *val, int len); const char *ZOOM_connection_option_get(ZOOM_connection c, const char *key); const char *ZOOM_connection_option_getl(ZOOM_connection c, const char *key, int *lenp); The functions ZOOM_connection_option_set and ZOOM_connection_option_setl allows you to set an option given by key to the value value for the connection. For ZOOM_connection_option_set, the value is assumed to be a 0-terminated string. Function ZOOM_connection_option_setl specifies a value of a certain size (len). Functions ZOOM_connection_option_get and ZOOM_connection_option_getl returns the value for an option given by key. ZOOM Connection Options Option Description Default implementationNameName of your client none userAuthentication user name none groupAuthentication group name none passwordAuthentication password. none authenticationModeHow authentication is encoded. basic hostTarget host. This setting is "read-only". It's automatically set internally when connecting to a target. none proxyProxy host. If set, the logical host is encoded in the otherInfo area of the Z39.50 Init PDU with OID 1.2.840.10003.10.1000.81.1. none clientIPClient IP. If set, is encoded in the otherInfo area of a Z39.50 PDU with OID 1.2.840.10003.10.1000.81.3. Holds the original IP addresses of a client. Is used if ZOOM is used in a gateway of some sort. none timeoutIdle timeout which specifies how long ZOOM will wait for network I/O before giving up. Thus, the actual waiting time might be longer than this value if the target makes a chunked response and the time between each chunk arrive is less this value. For the connect+init, this is the time ZOOM will wait until receiving first byte from Init response. 30 asyncIf true (1) the connection operates in asynchronous operation which means that all calls are non-blocking except ZOOM_event. 0 maximumRecordSize Maximum size of single record. 1 MB preferredMessageSize Maximum size of multiple records. 1 MB lang Language for negotiation. none charset Character set for negotiation. nonerpnCharset Client-side character conversion for RPN queries and scan terms. The input terms are converted from UTF-8 to the character set of rpnCharset. none (no conversion) serverImplementationId Implementation ID of server. (The old targetImplementationId option is also supported for the benefit of old applications.) none targetImplementationName Implementation Name of server. (The old targetImplementationName option is also supported for the benefit of old applications.) none serverImplementationVersion Implementation Version of server. (The old targetImplementationVersion option is also supported for the benefit of old applications.) none databaseNameOne or more database names separated by character plus (+), which is to be used by subsequent search requests on this Connection. Default piggybackTrue (1) if piggyback should be used in searches; false (0) if not. 1 smallSetUpperBoundIf hits is less than or equal to this value, then target will return all records using small element set name 0 largeSetLowerBoundIf hits is greater than this value, the target will return no records. 1 mediumSetPresentNumberThis value represents the number of records to be returned as part of a search when hits is less than or equal to large set lower bound and if hits is greater than small set upper bound. 0 smallSetElementSetName The element set name to be used for small result sets. none mediumSetElementSetName The element set name to be used for medium-sized result sets. none init_opt_search, init_opt_present, init_opt_delSet, etc. After a successful Init, these options may be interrogated to discover whether the server claims to support the specified operations. none sru SRU/Solr transport type. Must be either soap, get, post, or solr. soap if scheme is already http; ignored otherwise sru_version SRU/SRW version. Should be 1.1, or 1.2. This is, prior to connect, the version to offer (highest version). And following connect (in fact first operation), holds the negotiated version with the server (same or lower version). 1.2 extraArgs Extra arguments for SRU/Solr URLs. The value must be URL encoded already. facets Requested or recommended facets may be given before a search is sent. The value of this setting is described in For inspection of the facets returned, refer to the functions described in . none apdulog If set to a true value such as "1", a log of low-level protocol packets is emitted on standard error stream. This can be very useful for debugging. 0 saveAPDU If set to a true value such as "1", a log of low-level protocol packets is saved. The log can be retrieved by reading option APDU. Setting saveAPDU always has the side effect of resetting the currently saved log. This setting is write-only. If read, NULL will be returned. It is only recognized in ZOOM_connection_option_set. 0 APDU Returns the log of protocol packets. Will be empty if logging is not enabled (see saveAPDU above). This setting is read-only. It is only recognized if used in call to ZOOM_connection_option_get or ZOOM_connection_option_getl. memcached If given and non-empty, libMemcached will be configured for the connection. This option is inspected by ZOOM when a connection is established. If the memcached option is given and YAZ is compiled without libMemcached support, an internal diagnostic (10018) will be thrown. libMemcached support is available for YAZ 5.0.13 or later. If this option is supplied for an earlier version of YAZ, it is ignored. The value of this option is a list options - each is of the form --name=value. Option --server=host[:port] specifies a memcached server. It may be repeated for multiple memcached servers. Option --expire=seconds sets expiry time in seconds for how long result sets are to be cached. none redis If given and non-empty, a redis context will be created for the connection. This option is inspected by ZOOM when a connection is established. If the redis option is given and YAZ is compiled without redis support, an internal diagnostic (10018) will be thrown. redis support is available for YAZ 5.2.0 or later. If this option is supplied for an earlier version of YAZ, it is ignored. The value of this option is a set of options, similar to that of the memcached setting. At this stage only --server=host[:port] and --expire=seconds are supported. none
If either option lang or charset is set, then Character Set and Language Negotiation is in effect. int ZOOM_connection_error(ZOOM_connection c, const char **cp, const char **addinfo); int ZOOM_connection_error_x(ZOOM_connection c, const char **cp, const char **addinfo, const char **dset); Function ZOOM_connection_error checks for errors for the last operation(s) performed. The function returns zero if no errors occurred; non-zero otherwise indicating the error. Pointers cp and addinfo holds messages for the error and additional-info if passed as non-NULL. Function ZOOM_connection_error_x is an extended version of ZOOM_connection_error that is capable of returning name of diagnostic set in dset. Z39.50 Protocol behavior The calls ZOOM_connection_new and ZOOM_connection_connect establishes a TCP/IP connection and sends an Initialize Request to the target if possible. In addition, the calls wait for an Initialize Response from the target and the result is inspected (OK or rejected). If proxy is set then the client will establish a TCP/IP connection with the peer as specified by the proxy host and the hostname as part of the connect calls will be set as part of the Initialize Request. The proxy server will then "forward" the PDUs transparently to the target behind the proxy. For the authentication parameters, if option user is set and both options group and pass are unset, then Open style authentication is used (Version 2/3) in which case the username is usually followed by a slash, then by a password. If either group or pass is set then idPass authentication (Version 3 only) is used. If none of the options are set, no authentication parameters are set as part of the Initialize Request (obviously). When option async is 1, it really means that all network operations are postponed (and queued) until the function ZOOM_event is invoked. When doing so it doesn't make sense to check for errors after ZOOM_connection_new is called since that operation "connecting - and init" is still incomplete and the API cannot tell the outcome (yet). SRU/Solr Protocol behavior The HTTP based protocols (SRU, SRW, Solr) do not feature an Inititialize Request, so the connection phase merely establishes a TCP/IP connection with the HTTP server. Most of the ZOOM connection options do not affect SRU/Solr and they are ignored. However, future versions of &yaz; might honor implementationName and put that as part of User-Agent header for HTTP requests. The charset is used in the Content-Type header of HTTP requests. Setting authentcationMode specifies how authentication parameters are encoded for HTTP. The default is "basic" where user and password are encoded by using HTTP basic authentication. If authentcationMode is "url", then user and password are encoded in the URL by parameters x-username and x-password as given by the SRU standard. Queries Query objects represents queries. ZOOM_query ZOOM_query_create(void); void ZOOM_query_destroy(ZOOM_query q); int ZOOM_query_prefix(ZOOM_query q, const char *str); int ZOOM_query_cql(ZOOM_query s, const char *str); int ZOOM_query_sortby(ZOOM_query q, const char *criteria); int ZOOM_query_sortby2(ZOOM_query q, const char *strategy, const char *criteria); Create query objects using ZOOM_query_create and destroy them by calling ZOOM_query_destroy. RPN-queries can be specified in PQF notation by using the function ZOOM_query_prefix. The ZOOM_query_cql specifies a CQL query to be sent to the server/target. More query types will be added in future versions of &yaz;, such as CCL to RPN-mapping, native CCL query, etc. In addition to a search, a sort criteria may be set. Function ZOOM_query_sortby enables Z39.50 sorting and it takes sort criteria using the same string notation as yaz-client's sort command. ZOOM_query_sortby2 is similar to ZOOM_query_sortby but allows a strategy for sorting. The reason for the strategy parameter is that some protocols offer multiple ways of performing sorting. For example, Z39.50 has the standard sort, which is performed after search on an existing result set. It's also possible to use CQL in Z39.50 as the query type and use CQL's SORTBY keyword. Finally, Index Data's Zebra server also allows sorting to be specified as part of RPN (Type 7). ZOOM sort strategy Name Description z39.50Z39.50 resultset sort type7Sorting embedded in RPN(Type-7) cqlCQL SORTBY sru11SRU sortKeys parameter solrSolr sort embedtype7 for Z39.50, cql for SRU, solr for Solr protocol
Result sets The result set object is a container for records returned from a target. ZOOM_resultset ZOOM_connection_search(ZOOM_connection, ZOOM_query q); ZOOM_resultset ZOOM_connection_search_pqf(ZOOM_connection c, const char *q); void ZOOM_resultset_destroy(ZOOM_resultset r); Function ZOOM_connection_search creates a result set, given a connection and query. Destroy a result set by calling ZOOM_resultset_destroy. Simple clients using PQF only, may use the function ZOOM_connection_search_pqf in which case creating query objects is not necessary. void ZOOM_resultset_option_set(ZOOM_resultset r, const char *key, const char *val); const char *ZOOM_resultset_option_get(ZOOM_resultset r, const char *key); size_t ZOOM_resultset_size(ZOOM_resultset r); Functions ZOOM_resultset_options_set and ZOOM_resultset_get sets and gets an option for a result set similar to ZOOM_connection_option_get and ZOOM_connection_option_set. The number of hits, also called result-count, is returned by function ZOOM_resultset_size. ZOOM Result set Options Option Description Default startOffset of first record to be retrieved from target. First record has offset 0 unlike the protocol specifications where first record has position 1. This option affects ZOOM_resultset_search and ZOOM_resultset_search_pqf and must be set before any of these functions are invoked. If a range of records must be fetched manually after search, function ZOOM_resultset_records should be used. 0 countNumber of records to be retrieved. This option affects ZOOM_resultset_search and ZOOM_resultset_search_pqf and must be set before any of these functions are invoked. 0 presentChunkThe number of records to be requested from the server in each chunk (present request). The value 0 means to request all the records in a single chunk. (The old step option is also supported for the benefit of old applications.) 0 elementSetNameElement-Set name of records. Most targets should honor element set name B and F for brief and full respectively. none preferredRecordSyntaxPreferred Syntax, such as USMARC, SUTRS, etc. none schemaSchema for retrieval, such as Gils-schema, Geo-schema, etc. none setnameName of Result Set (Result Set ID). If this option isn't set, the ZOOM module will automatically allocate a result set name. default rpnCharsetCharacter set for RPN terms. If this is set, ZOOM C will assume that the ZOOM application is running UTF-8. Terms in RPN queries are then converted to the rpnCharset. If this is unset, ZOOM C will not assume any encoding of RPN terms and no conversion is performed. none
For servers that support Search Info report, the following options may be read using ZOOM_resultset_get. This detailed information is read after a successful search has completed. This information is a list of of items, where each item is information about a term or subquery. All items in the list are prefixed by SearchResult.no where no presents the item number (0=first, 1=second). Read searchresult.size to determine the number of items. Search Info Report Options Option Description searchresult.size number of search result entries. This option is non-existent if no entries are returned by the server. searchresult.no.id sub query ID searchresult.no.count result count for item (number of hits) searchresult.no.subquery.term subquery term searchresult.no.interpretation.term interpretation term searchresult.no.recommendation.term recommendation term
Z39.50 Result-set Sort void ZOOM_resultset_sort(ZOOM_resultset r, const char *sort_type, const char *sort_spec); int ZOOM_resultset_sort1(ZOOM_resultset r, const char *sort_type, const char *sort_spec); ZOOM_resultset_sort and ZOOM_resultset_sort1 both sort an existing result-set. The sort_type parameter is not used. Set it to "yaz". The sort_spec is same notation as ZOOM_query_sortby and identical to that offered by yaz-client's sort command. These functions only work for Z39.50. Use the more generic utility ZOOM_query_sortby2 for other protocols (and even Z39.50). Z39.50 Protocol behavior The creation of a result set involves at least a SearchRequest - SearchResponse protocol handshake. Following that, if a sort criteria was specified as part of the query, a SortRequest - SortResponse handshake takes place. Note that it is necessary to perform sorting before any retrieval takes place, so no records will be returned from the target as part of the SearchResponse because these would be unsorted. Hence, piggyback is disabled when sort criteria are set. Following Search - and a possible sort - Retrieval takes place - as one or more Present Requests/Response pairs being transferred. The API allows for two different modes for retrieval. A high level mode which is somewhat more powerful and a low level one. The low level is enabled when searching on a Connection object for which the settings smallSetUpperBound, mediumSetPresentNumber and largeSetLowerBound are set. The low level mode thus allows you to precisely set how records are returned as part of a search response as offered by the Z39.50 protocol. Since the client may be retrieving records as part of the search response, this mode doesn't work well if sorting is used. The high-level mode allows you to fetch a range of records from the result set with a given start offset. When you use this mode the client will automatically use piggyback if that is possible with the target, and perform one or more present requests as needed. Even if the target returns fewer records as part of a present response because of a record size limit, etc. the client will repeat sending present requests. As an example, if option start is 0 (default) and count is 4, and piggyback is 1 (default) and no sorting criteria is specified, then the client will attempt to retrieve the 4 records as part the search response (using piggyback). On the other hand, if either start is positive or if a sorting criteria is set, or if piggyback is 0, then the client will not perform piggyback but send Present Requests instead. If either of the options mediumSetElementSetName and smallSetElementSetName are unset, the value of option elementSetName is used for piggyback searches. This means that for the high-level mode you only have to specify one elementSetName option rather than three. SRU Protocol behavior Current version of &yaz; does not take advantage of a result set id returned by the SRU server. Future versions might do, however. Since the ZOOM driver does not save result set IDs, any present (retrieval) is transformed to a SRU SearchRetrieveRequest with same query but, possibly, different offsets. Option schema specifies SRU schema for retrieval. However, options elementSetName and preferredRecordSyntax are ignored. Options start and count are supported by SRU. The remaining options piggyback, smallSetUpperBound, largeSetLowerBound, mediumSetPresentNumber, mediumSetElementSetName, smallSetElementSetName are unsupported. SRU supports CQL queries, not PQF. If PQF is used, however, the PQF query is transferred anyway using non-standard element pQuery in SRU SearchRetrieveRequest. Solr queries need to be done in Solr query format. Unfortunately, SRU and Solr do not define a database setting. Hence, databaseName is unsupported and ignored. However, the path part in host parameter for functions ZOOM_connecton_new and ZOOM_connection_connect acts as a database (at least for the &yaz; SRU server). Records A record object is a retrieval record on the client side - created from result sets. void ZOOM_resultset_records(ZOOM_resultset r, ZOOM_record *recs, size_t start, size_t count); ZOOM_record ZOOM_resultset_record(ZOOM_resultset s, size_t pos); const char *ZOOM_record_get(ZOOM_record rec, const char *type, size_t *len); int ZOOM_record_error(ZOOM_record rec, const char **msg, const char **addinfo, const char **diagset); ZOOM_record ZOOM_record_clone(ZOOM_record rec); void ZOOM_record_destroy(ZOOM_record rec); References to temporary records are returned by functions ZOOM_resultset_records or ZOOM_resultset_record. If a persistent reference to a record is desired ZOOM_record_clone should be used. It returns a record reference that should be destroyed by a call to ZOOM_record_destroy. A single record is returned by function ZOOM_resultset_record that takes a position as argument. First record has position zero. If no record could be obtained NULL is returned. Error information for a record can be checked with ZOOM_record_error which returns non-zero (error code) if record is in error, called Surrogate Diagnostics in Z39.50. Function ZOOM_resultset_records retrieves a number of records from a result set. Parameter start and count specifies the range of records to be returned. Upon completion, the array recs[0], ..recs[count-1] holds record objects for the records. The array of records recs should be allocated prior the call ZOOM_resultset_records. Note that for those records that couldn't be retrieved from the target, recs[ ..] is set to NULL. In order to extract information about a single record, ZOOM_record_get is provided. The function returns a pointer to certain record information. The nature (type) of the pointer depends on the parameter, type. The type is a string of the format: format[;charset=from[/opacfrom][,to]][;format=v][;base64=xpath] If charset is given, then from specifies the character set of the record in its original form (as returned by the server), to specifies the output (returned) character set encoding. If to is omitted, then UTF-8 is assumed. If charset is not given, then no character set conversion takes place. OPAC records may be returned in a different set from the bibliographic MARC record. If this is this the case, opacfrom should be set to the character set of the OPAC record part. The format is generic but can only be used to specify XML indentation when the value v is 1 (format=1). The base64 allows a full record to be extracted from base64-encoded string in an XML document. Specifying the OPAC record character set requires YAZ 4.1.5 or later. Specifying the base64 parameter requires YAZ 4.2.35 or later. The format argument controls whether record data should be XML pretty-printed (post process operation). It is enabled only if format value v is 1 and the record content is XML well-formed. In addition, for certain types, the length len passed will be set to the size in bytes of the returned information. The following are the supported values for form. database The Database of the record is returned as a C null-terminated string. Return type const char *. syntax The transfer syntax of the record is returned as a C null-terminated string containing the symbolic name of the record syntax, e.g. Usmarc. Return type is const char *. schema The schema of the record is returned as a C null-terminated string. Return type is const char *. render The record is returned in a display friendly format. Upon completion, buffer is returned (type const char *) and length is stored in *len. raw The record is returned in the internal YAZ specific format. For GRS-1, Explain, and others, the raw data is returned as type Z_External * which is just the type for the member retrievalRecord in type NamePlusRecord. For SUTRS and octet aligned record (including all MARCs) the octet buffer is returned and the length of the buffer. xml The record is returned in XML if possible. SRU, Solr and Z39.50 records with transfer syntax XML are returned verbatim. MARC records are returned in MARCXML (converted from ISO2709 to MARCXML by YAZ). OPAC records are also converted to XML and the bibliographic record is converted to MARCXML (when possible). GRS-1 records are not supported for this form. Upon completion, the XML buffer is returned (type const char *) and length is stored in *len. opac OPAC information for record is returned in XML if an OPAC record is present at the position given. If no OPAC record is present, a NULL pointer is returned. txml The record is returned in TurboMARC if possible. SRU and Z39.50 records with transfer syntax XML are returned verbatim. MARC records are returned in TurboMARC (converted from ISO2709 to TurboMARC by YAZ). Upon completion, the XML buffer is returned (type const char *) and length is stored in *len. json Like xml, but MARC records are converted to MARC-in-JSON. Most MARC21 records uses the MARC-8 character set encoding. An application that wishes to display in Latin-1 would use render; charset=marc8,iso-8859-1 Z39.50 Protocol behavior The functions ZOOM_resultset_record and ZOOM_resultset_records inspects the client-side record cache. Records not found in cache are fetched using Present. The functions may block (and perform network I/O) - even though option async is 1, because they return records objects. (And there's no way to return records objects without retrieving them!) There is a trick, however, in the usage of function ZOOM_resultset_records that allows for delayed retrieval (and makes it non-blocking). By using a null pointer for recs you're indicating you're not interested in getting records objects now. SRU/Solr Protocol behavior The ZOOM driver for SRU/Solr treats records returned by a SRU/Solr server as if they where Z39.50 records with transfer syntax XML and no element set name or database name. ZOOM Facets Facets are only supported for a few Z39.50 targets. It is a relatively new non-standard Z39.50 extension (see facets.asn in the YAZ source). However, facets are usually supported for Solr and SRU 2.0 targets. Facets may be specified by the facets option before a search is sent. See for the notation. For inspection of the returned facets, the following functions are available: ZOOM_facet_field *ZOOM_resultset_facets(ZOOM_resultset r); size_t ZOOM_resultset_facets_size(ZOOM_resultset r); ZOOM_facet_field ZOOM_resultset_get_facet_field(ZOOM_resultset r, const char *facet_name); ZOOM_facet_field ZOOM_resultset_get_facet_field_by_index(ZOOM_resultset r, int pos); const char *ZOOM_facet_field_name(ZOOM_facet_field facet_field); size_t ZOOM_facet_field_term_count(ZOOM_facet_field facet_field); const char *ZOOM_facet_field_get_term(ZOOM_facet_field facet_field, size_t idx, int *freq); References to temporary structures are returned by all functions. They are only valid as long the Result set is valid. All facet fields may be returned by a call to ZOOM_resultset_facets. The length of the array is given by ZOOM_resultset_facets_size. The array is zero-based and the last entry will be at ZOOM_resultset_facets_size(result_set)-1. Facet fields can also be fetched via its name using ZOOM_resultset_get_facet_field. Or by its index (starting from 0) by a call to ZOOM_resultset_get_facet_field_by_index. Both of these functions return NULL if name is not found or index is out of bounds. Function ZOOM_facet_field_name gets the request facet name from a returned facet field. Function ZOOM_facet_field_get_term returns the idx'th term and term count for a facet field. Idx must between 0 and ZOOM_facet_field_term_count-1, otherwise the returned reference will be NULL. On a valid idx, the value of the freq reference will be the term count. The freq parameter must be valid pointer to integer. Scan This section describes an interface for Scan. Scan is not an official part of the ZOOM model yet. The result of a scan operation is the ZOOM_scanset which is a set of terms returned by a target. The Scan interface is supported for both Z39.50, SRU and Solr. ZOOM_scanset ZOOM_connection_scan(ZOOM_connection c, const char *startpqf); ZOOM_scanset ZOOM_connection_scan1(ZOOM_connection c, ZOOM_query q); size_t ZOOM_scanset_size(ZOOM_scanset scan); const char *ZOOM_scanset_term(ZOOM_scanset scan, size_t pos, size_t *occ, size_t *len); const char *ZOOM_scanset_display_term(ZOOM_scanset scan, size_t pos, size_t *occ, size_t *len); void ZOOM_scanset_destroy(ZOOM_scanset scan); const char *ZOOM_scanset_option_get(ZOOM_scanset scan, const char *key); void ZOOM_scanset_option_set(ZOOM_scanset scan, const char *key, const char *val); The scan set is created by function ZOOM_connection_scan which performs a scan operation on the connection using the specified startpqf. If the operation was successful, the size of the scan set can be retrieved by a call to ZOOM_scanset_size. Like result sets, the items are numbered 0..size-1. To obtain information about a particular scan term, call function ZOOM_scanset_term. This function takes a scan set offset pos and returns a pointer to a raw term or NULL if non-present. If present, the occ and len are set to the number of occurrences and the length of the actual term respectively. ZOOM_scanset_display_term is similar to ZOOM_scanset_term except that it returns the display term rather than the raw term. In a few cases, the term is different from display term. Always use the display term for display and the raw term for subsequent scan operations (to get more terms, next scan result, etc). A scan set may be freed by a call to function ZOOM_scanset_destroy. Functions ZOOM_scanset_option_get and ZOOM_scanset_option_set retrieves and sets an option respectively. The startpqf is a subset of PQF, namely the Attributes+Term part. Multiple @attr can be used. For example to scan in title (complete) phrases: @attr 1=4 @attr 6=2 "science o" The ZOOM_connecton_scan1 is a newer and more generic alternative to ZOOM_connection_scan which allows to use both CQL and PQF for Scan. ZOOM Scan Set Options Option Description Default numberNumber of Scan Terms requested in next scan. After scan it holds the actual number of terms returned. 20 positionPreferred Position of term in response in next scan; actual position after completion of scan. 1 stepSizeStep Size 0 scanStatusAn integer indicating the Scan Status of last scan. 0 rpnCharsetCharacter set for RPN terms. If this is set, ZOOM C will assume that the ZOOM application is running UTF-8. Terms in RPN queries are then converted to the rpnCharset. If this is unset, ZOOM C will not assume any encoding of RPN terms and no conversion is performed. none
 Extended Services ZOOM offers an interface to a subset of the Z39.50 extended services as well as a few privately defined ones: Z39.50 Item Order (ILL). See . Record Update. This allows a client to insert, modify or delete records. See . Database Create. This a non-standard feature. Allows a client to create a database. See . Database Drop. This a non-standard feature. Allows a client to delete/drop a database. See . Commit operation. This a non-standard feature. Allows a client to commit operations. See . To create an extended service operation, a ZOOM_package must be created. The operation is a five step operation. The package is created, package is configured by means of options, the package is sent, result is inspected (by means of options), the package is destroyed. ZOOM_package ZOOM_connection_package(ZOOM_connection c, ZOOM_options options); const char *ZOOM_package_option_get(ZOOM_package p, const char *key); void ZOOM_package_option_set(ZOOM_package p, const char *key, const char *val); void ZOOM_package_send(ZOOM_package p, const char *type); void ZOOM_package_destroy(ZOOM_package p); The ZOOM_connection_package creates a package for the connection given using the options specified. Functions ZOOM_package_option_get and ZOOM_package_option_set gets and sets options. ZOOM_package_send sends the package the via connection specified in ZOOM_connection_package. The type specifies the actual extended service package type to be sent. Extended Service Type Type Description itemorderItem Order updateRecord Update createDatabase Create dropDatabase Drop commitCommit Operation
Extended Service Common Options Option Description Default package-name Extended Service Request package name. Must be specified as part of a request. none user-id User ID of Extended Service Package. Is a request option. none function Function of package - one of create, delete, modify. Is a request option. create waitAction Wait action for package. Possible values: wait, waitIfPossible, dontWait or dontReturnPackage. waitIfPossible operationStatus Read after response. One of: done, accepted or failure. Inspect with ZOOM_pacakage_option_get. none targetReference Target Reference. This is part of the response as returned by the target. Read it after a successful operation. Inspect with ZOOM_pacakage_option_get. none taskStatus Read after response: One of: pending, active, complete, aborted. none esError Read after response: is set to diagnostic code for response. none esAddinfo Read after response: is set to additional info for response. none
Item Order For Item Order, type must be set to itemorder in ZOOM_package_send. Item Order Options Option Description Default contact-name ILL contact name none contact-phone ILL contact phone none contact-email ILL contact email none itemorder-setname Name of result set for record default itemorder-item Position for item (record) requested. An integer 1
There are two variants of item order: ILL-variant and XML document variant. In order to use the XML variant the setting doc must hold the XML item order document. If that setting is unset, the ILL-variant is used. ILL Request Options Option protocol-version-numtransaction-id,initial-requester-id,person-or-institution-symbol,persontransaction-id,initial-requester-id,person-or-institution-symbol,institutiontransaction-id,initial-requester-id,name-of-person-or-institution,name-of-persontransaction-id,initial-requester-id,name-of-person-or-institution,name-of-institutiontransaction-id,transaction-group-qualifiertransaction-id,transaction-qualifiertransaction-id,sub-transaction-qualifierservice-date-time,this,dateservice-date-time,this,timeservice-date-time,original,dateservice-date-time,original,timerequester-id,person-or-institution-symbol,personrequester-id,person-or-institution-symbol,institutionrequester-id,name-of-person-or-institution,name-of-personrequester-id,name-of-person-or-institution,name-of-institutionresponder-id,person-or-institution-symbol,personresponder-id,person-or-institution-symbol,institutionresponder-id,name-of-person-or-institution,name-of-personresponder-id,name-of-person-or-institution,name-of-institutiontransaction-typedelivery-address,postal-address,name-of-person-or-institution,name-of-persondelivery-address,postal-address,name-of-person-or-institution,name-of-institutiondelivery-address,postal-address,extended-postal-delivery-addressdelivery-address,postal-address,street-and-numberdelivery-address,postal-address,post-office-boxdelivery-address,postal-address,citydelivery-address,postal-address,regiondelivery-address,postal-address,countrydelivery-address,postal-address,postal-codedelivery-address,electronic-address,telecom-service-identifierdelivery-address,electronic-address,telecom-service-addreessbilling-address,postal-address,name-of-person-or-institution,name-of-personbilling-address,postal-address,name-of-person-or-institution,name-of-institutionbilling-address,postal-address,extended-postal-delivery-addressbilling-address,postal-address,street-and-numberbilling-address,postal-address,post-office-boxbilling-address,postal-address,citybilling-address,postal-address,regionbilling-address,postal-address,countrybilling-address,postal-address,postal-codebilling-address,electronic-address,telecom-service-identifierbilling-address,electronic-address,telecom-service-addreessill-service-typerequester-optional-messages,can-send-RECEIVEDrequester-optional-messages,can-send-RETURNEDrequester-optional-messages,requester-SHIPPEDrequester-optional-messages,requester-CHECKED-INsearch-type,level-of-servicesearch-type,need-before-datesearch-type,expiry-datesearch-type,expiry-flagplace-on-holdclient-id,client-nameclient-id,client-statusclient-id,client-identifieritem-id,item-typeitem-id,call-numberitem-id,authoritem-id,titleitem-id,sub-titleitem-id,sponsoring-bodyitem-id,place-of-publicationitem-id,publisheritem-id,series-title-numberitem-id,volume-issueitem-id,editionitem-id,publication-dateitem-id,publication-date-of-componentitem-id,author-of-articleitem-id,title-of-articleitem-id,paginationitem-id,ISBNitem-id,ISSNitem-id,additional-no-lettersitem-id,verification-reference-sourcecopyright-complicanceretry-flagforward-flagrequester-noteforward-note
 Record Update For Record Update, type must be set to update in ZOOM_package_send. Record Update Options Option Description Default action The update action. One of specialUpdate, recordInsert, recordReplace, recordDelete, elementUpdate. specialUpdate (recordInsert for updateVersion=1 which does not support specialUpdate) recordIdOpaque Opaque Record ID none recordIdNumber Record ID number none recordIdString Record ID string none record The record itself none recordOpaque Specifies an opaque record which is encoded as an ASN.1 ANY type with the OID as given by option syntax (see below). Option recordOpaque is an alternative to record - and record option (above) is ignored if recordOpaque is set. This option is only available in YAZ 3.0.35 and later, and is meant to facilitate Updates with servers from OCLC. none syntax The record syntax (transfer syntax). Is a string that is a known record syntax. no syntax databaseName Database from connection object Default correlationInfo.note Correlation Info Note (string) none correlationInfo.id Correlation Info ID (integer) none elementSetName Element Set for Record none updateVersion Record Update version which holds one of the values 1, 2 or 3. Each version has a distinct OID: 1.2.840.10003.9.5 (first version) , 1.2.840.10003.9.5.1 (second version) and 1.2.840.10003.9.5.1.1 (third and newest version). 3
Database Create For Database Create, type must be set to create in ZOOM_package_send. Database Create Options Option Description Default databaseName Database from connection object Default
Database Drop For Database Drop, type must be set to drop in ZOOM_package_send. Database Drop Options Option Description Default databaseName Database from connection object Default
Commit Operation For Commit, type must be set to commit in ZOOM_package_send. Protocol behavior All the extended services are Z39.50-only. The database create, drop, and commit services are privately defined operations. Refer to esadmin.asn in YAZ for the ASN.1 definitions. Options Most &zoom; objects provide a way to specify options to change behavior. From an implementation point of view, a set of options is just like an associative array / hash. ZOOM_options ZOOM_options_create(void); ZOOM_options ZOOM_options_create_with_parent(ZOOM_options parent); void ZOOM_options_destroy(ZOOM_options opt); const char *ZOOM_options_get(ZOOM_options opt, const char *name); void ZOOM_options_set(ZOOM_options opt, const char *name, const char *v); typedef const char *(*ZOOM_options_callback) (void *handle, const char *name); ZOOM_options_callback ZOOM_options_set_callback(ZOOM_options opt, ZOOM_options_callback c, void *handle); Query conversions int ZOOM_query_cql2rpn(ZOOM_query s, const char *cql_str, ZOOM_connection conn); int ZOOM_query_ccl2rpn(ZOOM_query s, const char *ccl_str, const char *config, int *ccl_error, const char **error_string, int *error_pos); ZOOM_query_cql2rpn translates the CQL string, client-side, into RPN which may be passed to the server. This is useful for servers that don't themselves support CQL, for which ZOOM_query_cql is useless. 'conn' is used only as a place to stash diagnostics if compilation fails; if this information is not needed, a null pointer may be used. The CQL conversion is driven by option cqlfile from connection conn. This specifies a conversion file (e.g. pqf.properties) which must be present. ZOOM_query_ccl2rpn translates the CCL string, client-side, into RPN which may be passed to the server. The conversion is driven by the specification given by config. Upon completion 0 is returned on success; -1 is returned on failure. On failure error_string and error_pos hold the error message and position of first error in original CCL string. Events If you're developing non-blocking applications, you have to deal with events. int ZOOM_event(int no, ZOOM_connection *cs); The ZOOM_event executes pending events for a number of connections. Supply the number of connections in no and an array of connections in cs (cs[0] ... cs[no-1]). A pending event could be sending a search, receiving a response, etc. When an event has occurred for one of the connections, this function returns a positive integer n denoting that an event occurred for connection cs[n-1]. When no events are pending for the connections, a value of zero is returned. To ensure that all outstanding requests are performed, call this function repeatedly until zero is returned. If ZOOM_event returns, and returns non-zero, the last event that occurred can be expected. int ZOOM_connection_last_event(ZOOM_connection cs); ZOOM_connection_last_event returns an event type (integer) for the last event. ZOOM Event IDs Event Description ZOOM_EVENT_NONE No event has occurred ZOOM_EVENT_CONNECT TCP/IP connect has initiated ZOOM_EVENT_SEND_DATA Data has been transmitted (sending) ZOOM_EVENT_RECV_DATA Data has been received ZOOM_EVENT_TIMEOUT Timeout ZOOM_EVENT_UNKNOWN Unknown event ZOOM_EVENT_SEND_APDU An APDU has been transmitted (sending) ZOOM_EVENT_RECV_APDU An APDU has been received ZOOM_EVENT_RECV_RECORD A result-set record has been received ZOOM_EVENT_RECV_SEARCH A search result has been received
Generic server Introduction If you aren't into documentation, a good way to learn how the back end interface works is to look at the backend.h file. Then, look at the small dummy-server in ztest/ztest.c. The backend.h file also makes a good reference, once you've chewed your way through the prose of this file. If you have a database system that you would like to make available by means of Z39.50 or SRU, &yaz; basically offers two options. You can use the APIs provided by the &asn;, &odr;, and &comstack; modules to create and decode PDUs, and exchange them with a client. Using this low-level interface gives you access to all fields and options of the protocol, and you can construct your server as close to your existing database as you like. It is also a fairly involved process, requiring you to set up an event-handling mechanism, protocol state machine, etc. To simplify server implementation, we have implemented a compact and simple, but reasonably full-functioned server-frontend that will handle most of the protocol mechanics, while leaving you to concentrate on your database interface. The backend interface was designed in anticipation of a specific integration task, while still attempting to achieve some degree of generality. We realize fully that there are points where the interface can be improved significantly. If you have specific functions or parameters that you think could be useful, send us a mail (or better, sign on to the mailing list referred to in the top-level README file). We will try to fit good suggestions into future releases, to the extent that it can be done without requiring too many structural changes in existing applications. The &yaz; server does not support XCQL. The Database Frontend We refer to this software as a generic database frontend. Your database system is the backend database, and the interface between the two is called the backend API. The backend API consists of a small number of function handlers and structure definitions. You are required to provide the main() routine for the server (which can be quite simple), as well as a set of handlers to match each of the prototypes. The interface functions that you write can use any mechanism you like to communicate with your database system: You might link the whole thing together with your database application and access it by function calls; you might use IPC to talk to a database server somewhere; or you might link with third-party software that handles the communication for you (like a commercial database client library). At any rate, the handlers will perform the tasks of: Initialization. Searching. Fetching records. Scanning the database index (optional - if you wish to implement SCAN). Extended Services (optional). Result-Set Delete (optional). Result-Set Sort (optional). Return Explain for SRU (optional). (more functions will be added in time to support as much of Z39.50-1995 as possible). The Backend API The header file that you need to use the interface are in the include/yaz directory. It's called backend.h. It will include other files from the include/yaz directory, so you'll probably want to use the -I option of your compiler to tell it where to find the files. When you run make in the top-level &yaz; directory, everything you need to create your server is to link with the lib/libyaz.la library. Your main() Routine As mentioned, your main() routine can be quite brief. If you want to initialize global parameters, or read global configuration tables, this is the place to do it. At the end of the routine, you should call the function int statserv_main(int argc, char **argv, bend_initresult *(*bend_init)(bend_initrequest *r), void (*bend_close)(void *handle)); The third and fourth arguments are pointers to handlers. Handler bend_init is called whenever the server receives an Initialize Request, so it serves as a Z39.50 session initializer. The bend_close handler is called when the session is closed. statserv_main will establish listening sockets according to the parameters given. When connection requests are received, the event handler will typically fork() and create a sub-process to handle a new connection. Alternatively the server may be setup to create threads for each connection. If you do use global variables and forking, you should be aware, then, that these cannot be shared between associations, unless you explicitly disable forking by command line parameters. The server provides a mechanism for controlling some of its behavior without using command-line options. The function statserv_options_block *statserv_getcontrol(void); will return a pointer to a struct statserv_options_block describing the current default settings of the server. The structure contains these elements: int dynamic A boolean value, which determines whether the server will fork on each incoming request (TRUE), or not (FALSE). Default is TRUE. This flag is only read by UNIX-based servers (WIN32-based servers do not fork). int threads A boolean value, which determines whether the server will create a thread on each incoming request (TRUE), or not (FALSE). Default is FALSE. This flag is only read by UNIX-based servers that offer POSIX Threads support. WIN32-based servers always operate in threaded mode. int inetd A boolean value, which determines whether the server will operate under a UNIX INET daemon (inetd). Default is FALSE. char logfile[ODR_MAXNAME+1] File for diagnostic output ("": stderr). char apdufile[ODR_MAXNAME+1] Name of file for logging incoming and outgoing APDUs ("": don't log APDUs, "-": stderr). char default_listen[1024] Same form as the command-line specification of listener address. "": no default listener address. Default is to listen at "tcp:@:9999". You can only specify one default listener address in this fashion. enum oid_proto default_proto; Either PROTO_Z3950 or PROTO_SR. Default is PROTO_Z39_50. int idle_timeout; Maximum session idle-time, in minutes. Zero indicates no (infinite) timeout. Default is 15 minutes. int maxrecordsize; Maximum permissible record (message) size. Default is 64 MB. This amount of memory will only be allocated if a client requests a very large amount of records in one operation (or a big record). Set it to a lower number if you are worried about resource consumption on your host system. char configname[ODR_MAXNAME+1] Passed to the backend when a new connection is received. char setuid[ODR_MAXNAME+1] Set user id to the user specified, after binding the listener addresses. void (*bend_start)(struct statserv_options_block *p) Pointer to function which is called after the command line options have been parsed - but before the server starts listening. For forked UNIX servers, this handler is called in the mother process; for threaded servers, this handler is called in the main thread. The default value of this pointer is NULL in which case it isn't invoked by the frontend server. When the server operates as an NT service, this handler is called whenever the service is started. void (*bend_stop)(struct statserv_options_block *p) Pointer to function which is called whenever the server has stopped listening for incoming connections. This function pointer has a default value of NULL in which case it isn't called. When the server operates as an NT service, this handler is called whenever the service is stopped. void *handle User defined pointer (default value NULL). This is a per-server handle that can be used to specify "user-data". Do not confuse this with the session-handle as returned by bend_init. The pointer returned by statserv_getcontrol points to a static area. You are allowed to change the contents of the structure, but the changes will not take effect until you call void statserv_setcontrol(statserv_options_block *block); You should generally update this structure before calling statserv_main(). The Backend Functions For each service of the protocol, the backend interface declares one or two functions. You are required to provide implementations of the functions representing the services that you wish to implement. Init bend_initresult (*bend_init)(bend_initrequest *r); This handler is called once for each new connection request, after a new process/thread has been created, and an Initialize Request has been received from the client. The pointer to the bend_init handler is passed in the call to statserv_start. This handler is also called when operating in SRU mode - when a connection has been made (even though SRU does not offer this service). Unlike previous versions of YAZ, the bend_init also serves as a handler that defines the Z39.50 services that the backend intends to support. Pointers to all service handlers, including search - and fetch must be specified here in this handler. The request - and result structures are defined as typedef struct bend_initrequest { /** \brief user/name/password to be read */ Z_IdAuthentication *auth; /** \brief encoding stream (for results) */ ODR stream; /** \brief printing stream */ ODR print; /** \brief decoding stream (use stream for results) */ ODR decode; /** \brief reference ID */ Z_ReferenceId *referenceId; /** \brief peer address of client */ char *peer_name; /** \brief character set and language negotiation see include/yaz/z-charneg.h */ Z_CharSetandLanguageNegotiation *charneg_request; /** \brief character negotiation response */ Z_External *charneg_response; /** \brief character set (encoding) for query terms This is NULL by default. It should be set to the native character set that the backend assumes for query terms */ char *query_charset; /** \brief whether query_charset also applies to records Is 0 (No) by default. Set to 1 (yes) if records is in the same character set as queries. If in doubt, use 0 (No). */ int records_in_same_charset; char *implementation_id; char *implementation_name; char *implementation_version; /** \brief Z39.50 sort handler */ int (*bend_sort)(void *handle, bend_sort_rr *rr); /** \brief SRU/Z39.50 search handler */ int (*bend_search)(void *handle, bend_search_rr *rr); /** \brief SRU/Z39.50 fetch handler */ int (*bend_fetch)(void *handle, bend_fetch_rr *rr); /** \brief SRU/Z39.50 present handler */ int (*bend_present)(void *handle, bend_present_rr *rr); /** \brief Z39.50 extended services handler */ int (*bend_esrequest) (void *handle, bend_esrequest_rr *rr); /** \brief Z39.50 delete result set handler */ int (*bend_delete)(void *handle, bend_delete_rr *rr); /** \brief Z39.50 scan handler */ int (*bend_scan)(void *handle, bend_scan_rr *rr); /** \brief Z39.50 segment facility handler */ int (*bend_segment)(void *handle, bend_segment_rr *rr); /** \brief SRU explain handler */ int (*bend_explain)(void *handle, bend_explain_rr *rr); /** \brief SRU scan handler */ int (*bend_srw_scan)(void *handle, bend_scan_rr *rr); /** \brief SRU record update handler */ int (*bend_srw_update)(void *handle, bend_update_rr *rr); /** \brief whether named result sets are supported (0=disable, 1=enable) */ int named_result_sets; } bend_initrequest; typedef struct bend_initresult { int errcode; /* 0==OK */ char *errstring; /* system error string or NULL */ void *handle; /* private handle to the backend module */ } bend_initresult; In general, the server frontend expects that the bend_*result pointer that you return is valid at least until the next call to a bend_* function. This applies to all of the functions described herein. The parameter structure passed to you in the call belongs to the server frontend, and you should not make assumptions about its contents after the current function call has completed. In other words, if you want to retain any of the contents of a request structure, you should copy them. The errcode should be zero if the initialization of the backend went well. Any other value will be interpreted as an error. The errstring isn't used in the current version, but one option would be to stick it in the initResponse as a VisibleString. The handle is the most important parameter. It should be set to some value that uniquely identifies the current session to the backend implementation. It is used by the frontend server in any future calls to a backend function. The typical use is to set it to point to a dynamically allocated state structure that is private to your backend module. The auth member holds the authentication information part of the Z39.50 Initialize Request. Interpret this if your server requires authentication. The members peer_name, implementation_id, implementation_name and implementation_version holds DNS of client, ID of implementor, name of client (Z39.50) implementation - and version. The bend_ - members are set to NULL when bend_init is called. Modify the pointers by setting them to point to backend functions. Search and Retrieve We now describe the handlers that are required to support search - and retrieve. You must support two functions - one for search - and one for fetch (retrieval of one record). If desirable you can provide a third handler which is called when a present request is received which allows you to optimize retrieval of multiple-records. int (*bend_search) (void *handle, bend_search_rr *rr); typedef struct { char *setname; /* name to give to this set */ int replace_set; /* replace set, if it already exists */ int num_bases; /* number of databases in list */ char **basenames; /* databases to search */ Z_ReferenceId *referenceId;/* reference ID */ Z_Query *query; /* query structure */ ODR stream; /* encode stream */ ODR decode; /* decode stream */ ODR print; /* print stream */ bend_request request; bend_association association; int *fd; int hits; /* number of hits */ int errcode; /* 0==OK */ char *errstring; /* system error string or NULL */ Z_OtherInformation *search_info; /* additional search info */ char *srw_sortKeys; /* holds SRU/SRW sortKeys info */ char *srw_setname; /* holds SRU/SRW generated resultsetID */ int *srw_setnameIdleTime; /* holds SRU/SRW life-time */ int estimated_hit_count; /* if hit count is estimated */ int partial_resultset; /* if result set is partial */ } bend_search_rr; The bend_search handler is a fairly close approximation of a protocol Z39.50 Search Request - and Response PDUs. The setname is the resultSetName from the protocol. You are required to establish a mapping between the set name and whatever your backend database likes to use. Similarly, the replace_set is a boolean value corresponding to the resultSetIndicator field in the protocol. num_bases/basenames is a length of/array of character pointers to the database names provided by the client. The query is the full query structure as defined in the protocol ASN.1 specification. It can be either of the possible query types, and it's up to you to determine if you can handle the provided query type. Rather than reproduce the C interface here, we'll refer you to the structure definitions in the file include/yaz/z-core.h. If you want to look at the attributeSetId OID of the RPN query, you can either match it against your own internal tables, or you can use the OID tools. The structure contains a number of hits, and an errcode/errstring pair. If an error occurs during the search, or if you're unhappy with the request, you should set the errcode to a value from the BIB-1 diagnostic set. The value will then be returned to the user in a nonsurrogate diagnostic record in the response. The errstring, if provided, will go in the addinfo field. Look at the protocol definition for the defined error codes, and the suggested uses of the addinfo field. The bend_search handler is also called when the frontend server receives a SRU SearchRetrieveRequest. For SRU, a CQL query is usually provided by the client. The CQL query is available as part of Z_Query structure (note that CQL is now part of Z39.50 via an external). To support CQL in existing implementations that only do Type-1, we refer to the CQL-to-PQF tool described here. To maintain backwards compatibility, the frontend server of yaz always assume that error codes are BIB-1 diagnostics. For SRU operation, a Bib-1 diagnostic code is mapped to SRU diagnostic. int (*bend_fetch) (void *handle, bend_fetch_rr *rr); typedef struct bend_fetch_rr { char *setname; /* set name */ int number; /* record number */ Z_ReferenceId *referenceId;/* reference ID */ Odr_oid *request_format; /* format, transfer syntax (OID) */ Z_RecordComposition *comp; /* Formatting instructions */ ODR stream; /* encoding stream - memory source if req */ ODR print; /* printing stream */ char *basename; /* name of database that provided record */ int len; /* length of record or -1 if structured */ char *record; /* record */ int last_in_set; /* is it? */ Odr_oid *output_format; /* response format/syntax (OID) */ int errcode; /* 0==success */ char *errstring; /* system error string or NULL */ int surrogate_flag; /* surrogate diagnostic */ char *schema; /* string record schema input/output */ } bend_fetch_rr; The frontend server calls the bend_fetch handler when it needs database records to fulfill a Z39.50 Search Request, a Z39.50 Present Request or a SRU SearchRetrieveRequest. The setname is simply the name of the result set that holds the reference to the desired record. The number is the offset into the set (with 1 being the first record in the set). The format field is the record format requested by the client (See ). A value of NULL for format indicates that the client did not request a specific format. The stream argument is an &odr; stream which should be used for allocating space for structured data records. The stream will be reset when all records have been assembled, and the response package has been transmitted. For unstructured data, the backend is responsible for maintaining a static or dynamic buffer for the record between calls. If a SRU SearchRetrieveRequest is received by the frontend server, the referenceId is NULL and the format (transfer syntax) is the OID for XML. The schema for SRU is stored in both the Z_RecordComposition structure and schema (simple string). In the structure, the basename is the name of the database that holds the record. len is the length of the record returned, in bytes, and record is a pointer to the record. last_in_set should be nonzero only if the record returned is the last one in the given result set. errcode and errstring, if given, will be interpreted as a global error pertaining to the set, and will be returned in a non-surrogate-diagnostic. If you wish to return the error as a surrogate-diagnostic (local error) you can do this by setting surrogate_flag to 1 also. If the len field has the value -1, then record is assumed to point to a constructed data type. The format field will be used to determine which encoder should be used to serialize the data. If your backend generates structured records, it should use odr_malloc() on the provided stream for allocating data: This allows the frontend server to keep track of the record sizes. The format field is mapped to an object identifier in the direct reference of the resulting EXTERNAL representation of the record. The current version of &yaz; only supports the direct reference mode. int (*bend_present) (void *handle, bend_present_rr *rr); typedef struct { char *setname; /* set name */ int start; int number; /* record number */ Odr_oid *format; /* format, transfer syntax (OID) */ Z_ReferenceId *referenceId;/* reference ID */ Z_RecordComposition *comp; /* Formatting instructions */ ODR stream; /* encoding stream - memory source if required */ ODR print; /* printing stream */ bend_request request; bend_association association; int hits; /* number of hits */ int errcode; /* 0==OK */ char *errstring; /* system error string or NULL */ } bend_present_rr; The bend_present handler is called when the server receives a Z39.50 Present Request. The setname, start and number is the name of the result set - start position - and number of records to be retrieved respectively. format and comp is the preferred transfer syntax and element specifications of the present request. Note that this is handler serves as a supplement for bend_fetch and need not to be defined in order to support search - and retrieve. Delete For back-ends that supports delete of a result set, only one handler must be defined. int (*bend_delete)(void *handle, bend_delete_rr *rr); typedef struct bend_delete_rr { int function; int num_setnames; char **setnames; Z_ReferenceId *referenceId; int delete_status; /* status for the whole operation */ int *statuses; /* status each set - indexed as setnames */ ODR stream; ODR print; } bend_delete_rr; The delete set function definition is rather primitive, mostly because we have had no practical need for it as of yet. If someone wants to provide a full delete service, we'd be happy to add the extra parameters that are required. Are there clients out there that will actually delete sets they no longer need? Scan For servers that wish to offer the scan service one handler must be defined. int (*bend_scan)(void *handle, bend_scan_rr *rr); typedef enum { BEND_SCAN_SUCCESS, /* ok */ BEND_SCAN_PARTIAL /* not all entries could be found */ } bend_scan_status; typedef struct bend_scan_rr { int num_bases; /* number of elements in databaselist */ char **basenames; /* databases to search */ Odr_oid *attributeset; Z_ReferenceId *referenceId; /* reference ID */ Z_AttributesPlusTerm *term; ODR stream; /* encoding stream - memory source if required */ ODR print; /* printing stream */ int *step_size; /* step size */ int term_position; /* desired index of term in result list/returned */ int num_entries; /* number of entries requested/returned */ /* scan term entries. The called handler does not have to allocate this. Size of entries is num_entries (see above) */ struct scan_entry *entries; bend_scan_status status; int errcode; char *errstring; char *scanClause; /* CQL scan clause */ char *setname; /* Scan in result set (NULL if omitted) */ } bend_scan_rr; This backend server handles both Z39.50 scan and SRU scan. In order for a handler to distinguish between SRU (CQL) scan Z39.50 Scan, it must check for a non-NULL value of scanClause. If designed today, it would be a choice using a union or similar, but that would break binary compatibility with existing servers. Application Invocation The finished application has the following invocation syntax (by way of statserv_main()): &gfs-synopsis; The options are: &gfs-options; A listener specification consists of a transport mode followed by a colon (:) followed by a listener address. The transport mode is either tcp, unix: or ssl. For TCP and SSL, an address has the form hostname | IP-number [: portnumber] The port number defaults to 210 (standard Z39.50 port). For UNIX, the address is the filename of socket. For TCP/IP and SSL, the special hostnames @, maps to IN6ADDR_ANY_INIT with IPV4 binding as well (bindv6only=0), The special hostname @4 binds to INADDR_ANY (IPV4 only listener). The special hostname @6 binds to IN6ADDR_ANY_INIT with bindv6only=1 (IPV6 only listener). Running the GFS on Unix Assuming the server application appname is started as root, the following will make it listen on port 210. The server will change identity to nobody and write its log to /var/log/app.log. application -l /var/log/app.log -u nobody tcp:@:210 The server will accept Z39.50 requests and offer SRU service on port 210. Setting up Apache as SRU Frontend If you use Apache as your public web server and want to offer HTTP port 80 access to the YAZ server on 210, you can use the ProxyPass directive. If you have virtual host srw.mydomain you can use the following directives in Apache's httpd.conf: <VirtualHost *> ErrorLog /home/srw/logs/error_log TransferLog /home/srw/logs/access_log ProxyPass / http://srw.mydomain:210/ </VirtualHost> The above is for the Apache 1.3 series. Running a server with local access only A server that is only being accessed from the local host should listen on UNIX file socket rather than an Internet socket. To listen on /tmp/mysocket start the server as follows: application unix:/tmp/mysocket GFS Configuration and Virtual Hosts &gfs-virtual; The Z39.50 ASN.1 Module Introduction The &asn; module provides you with a set of C struct definitions for the various PDUs of the Z39.50 protocol, as well as for the complex types appearing within the PDUs. For the primitive data types, the C representation often takes the form of an ordinary C language type, such as Odr_int which is equivalent to an integral C integer. For ASN.1 constructs that have no direct representation in C, such as general octet strings and bit strings, the &odr; module (see section The ODR Module) provides auxiliary definitions. The &asn; module is located in sub directory z39.50. There you'll find C files that implement encoders and decoders for the Z39.50 types. You'll also find the protocol definitions: z3950v3.asn, esupdate.asn, and others. Preparing PDUs A structure representing a complex ASN.1 type doesn't in itself contain the members of that type. Instead, the structure contains pointers to the members of the type. This is necessary, in part, to allow a mechanism for specifying which of the optional structure (SEQUENCE) members are present, and which are not. It follows that you will need to somehow provide space for the individual members of the structure, and set the pointers to refer to the members. The conversion routines don't care how you allocate and maintain your C structures - they just follow the pointers that you provide. Depending on the complexity of your application, and your personal taste, there are at least three different approaches that you may take when you allocate the structures. You can use static or automatic local variables in the function that prepares the PDU. This is a simple approach, and it provides the most efficient form of memory management. While it works well for flat PDUs like the InitRequest, it will generally not be sufficient for say, the generation of an arbitrarily complex RPN query structure. You can individually create the structure and its members using the malloc(2) function. If you want to ensure that the data is freed when it is no longer needed, you will have to define a function that individually releases each member of a structure before freeing the structure itself. You can use the odr_malloc() function (see for details). When you use odr_malloc(), you can release all of the allocated data in a single operation, independent of any pointers and relations between the data. The odr_malloc() function is based on a "nibble-memory" scheme, in which large portions of memory are allocated, and then gradually handed out with each call to odr_malloc(). The next time you call odr_reset(), all of the memory allocated since the last call is recycled for future use (actually, it is placed on a free-list). You can combine all of the methods described here. This will often be the most practical approach. For instance, you might use odr_malloc() to allocate an entire structure and some of its elements, while you leave other elements pointing to global or per-session default variables. The &asn; module provides an important aid in creating new PDUs. For each of the PDU types (say, Z_InitRequest), a function is provided that allocates and initializes an instance of that PDU type for you. In the case of the InitRequest, the function is simply named zget_InitRequest(), and it sets up reasonable default value for all of the mandatory members. The optional members are generally initialized to null pointers. This last aspect is very important: it ensures that if the PDU definitions are extended after you finish your implementation (to accommodate new versions of the protocol, say), you won't get into trouble with uninitialized pointers in your structures. The functions use odr_malloc() to allocate the PDUs and its members, so you can free everything again with a single call to odr_reset(). We strongly recommend that you use the zget_* functions whenever you are preparing a PDU (in a C++ API, the zget_ functions would probably be promoted to constructors for the individual types). The prototype for the individual PDU types generally look like this: Z_<type> *zget_<type>(ODR o); e.g.: Z_InitRequest *zget_InitRequest(ODR o); The &odr; handle should generally be your encoding stream, but it needn't be. As well as the individual PDU functions, a function zget_APDU() is provided, which allocates a top-level Z-APDU of the type requested: Z_APDU *zget_APDU(ODR o, int which); The which parameter is (of course) the discriminator belonging to the Z_APDU CHOICE type. All of the interface described here is provided by the &asn; module, and you access it through the proto.h header file. EXTERNAL Data In order to achieve extensibility and adaptability to different application domains, the new version of the protocol defines many structures outside of the main ASN.1 specification, referencing them through ASN.1 EXTERNAL constructs. To simplify the construction and access to the externally referenced data, the &asn; module defines a specialized version of the EXTERNAL construct, called Z_External.It is defined thus: typedef struct Z_External { Odr_oid *direct_reference; int *indirect_reference; char *descriptor; enum { /* Generic types */ Z_External_single = 0, Z_External_octet, Z_External_arbitrary, /* Specific types */ Z_External_SUTRS, Z_External_explainRecord, Z_External_resourceReport1, Z_External_resourceReport2 ... } which; union { /* Generic types */ Odr_any *single_ASN1_type; Odr_oct *octet_aligned; Odr_bitmask *arbitrary; /* Specific types */ Z_SUTRS *sutrs; Z_ExplainRecord *explainRecord; Z_ResourceReport1 *resourceReport1; Z_ResourceReport2 *resourceReport2; ... } u; } Z_External; When decoding, the &asn; module will attempt to determine which syntax describes the data by looking at the reference fields (currently only the direct-reference). For ASN.1 structured data, you need only consult the which field to determine the type of data. You can the access the data directly through the union. When constructing data for encoding, you set the union pointer to point to the data, and set the which field accordingly. Remember also to set the direct (or indirect) reference to the correct OID for the data type. For non-ASN.1 data such as MARC records, use the octet_aligned arm of the union. Some servers return ASN.1 structured data values (e.g. database records) as BER-encoded records placed in the octet-aligned branch of the EXTERNAL CHOICE. The ASN-module will not automatically decode these records. To help you decode the records in the application, the function Z_ext_typeent *z_ext_gettypebyref(const oid *oid); can be used to retrieve information about the known, external data types. The function returns a pointer to a static area, or NULL, if no match for the given direct reference is found. The Z_ext_typeent is defined as: typedef struct Z_ext_typeent { int oid[OID_SIZE]; /* the direct-reference OID. */ int what; /* discriminator value for the external CHOICE */ Odr_fun fun; /* decoder function */ } Z_ext_typeent; The what member contains the Z_External union discriminator value for the given type: For the SUTRS record syntax, the value would be Z_External_sutrs. The fun member contains a pointer to the function which encodes/decodes the given type. Again, for the SUTRS record syntax, the value of fun would be z_SUTRS (a function pointer). If you receive an EXTERNAL which contains an octet-string value that you suspect of being an ASN.1-structured data value, you can use z_ext_gettypebyref to look for the provided direct-reference. If the return value is different from NULL, you can use the provided function to decode the BER string (see ). If you want to send EXTERNALs containing ASN.1-structured values in the octet-aligned branch of the CHOICE, this is possible too. However, on the encoding phase, it requires a somewhat involved juggling around of the various buffers involved. If you need to add new, externally defined data types, you must update the struct above, in the source file prt-ext.h, as well as the encoder/decoder in the file prt-ext.c. When changing the latter, remember to update both the arm array and the list type_table, which drives the CHOICE biasing that is necessary to tell the different, structured types apart on decoding. Eventually, the EXTERNAL processing will most likely automatically insert the correct OIDs or indirect-refs. First, however, we need to determine how application-context management (specifically the presentation-context-list) should fit into the various modules. PDU Contents Table We include, for reference, a listing of the fields of each top-level PDU, as well as their default settings. Default settings for PDU Initialize Request Field Type Default Value referenceIdZ_ReferenceIdNULL protocolVersionOdr_bitmaskEmpty bitmask optionsOdr_bitmaskEmpty bitmask preferredMessageSizeOdr_int30*1024 maximumRecordSizeOdr_int30*1024 idAuthenticationZ_IdAuthenticationNULL implementationIdchar*"81" implementationNamechar*"YAZ" implementationVersionchar*YAZ_VERSION userInformationFieldZ_UserInformationNULL otherInfoZ_OtherInformationNULL
Default settings for PDU Initialize Response Field Type Default Value referenceIdZ_ReferenceIdNULL protocolVersionOdr_bitmaskEmpty bitmask optionsOdr_bitmaskEmpty bitmask preferredMessageSizeOdr_int30*1024 maximumRecordSizeOdr_int30*1024 resultOdr_boolTRUE implementationIdchar*"id)" implementationNamechar*"YAZ" implementationVersionchar*YAZ_VERSION userInformationFieldZ_UserInformationNULL otherInfoZ_OtherInformationNULL
Default settings for PDU Search Request Field Type Default Value referenceIdZ_ReferenceIdNULL smallSetUpperBoundOdr_int0 largeSetLowerBoundOdr_int1 mediumSetPresentNumberOdr_int0 replaceIndicatorOdr_boolTRUE resultSetNamechar *"default" num_databaseNamesOdr_int0 databaseNameschar **NULL smallSetElementSetNamesZ_ElementSetNames NULL mediumSetElementSetNamesZ_ElementSetNames NULL preferredRecordSyntaxOdr_oidNULL queryZ_QueryNULL additionalSearchInfoZ_OtherInformation NULL otherInfoZ_OtherInformationNULL
Default settings for PDU Search Response Field Type Default Value referenceIdZ_ReferenceIdNULL resultCountOdr_int0 numberOfRecordsReturnedOdr_int0 nextResultSetPositionOdr_int0 searchStatusOdr_boolTRUE resultSetStatusOdr_intNULL presentStatusOdr_intNULL recordsZ_RecordsNULL additionalSearchInfo Z_OtherInformationNULL otherInfoZ_OtherInformationNULL
Default settings for PDU Present Request Field Type Default Value referenceIdZ_ReferenceIdNULL resultSetIdchar*"default" resultSetStartPointOdr_int1 numberOfRecordsRequestedOdr_int10 num_rangesOdr_int0 additionalRangesZ_RangeNULL recordCompositionZ_RecordCompositionNULL preferredRecordSyntaxOdr_oidNULL maxSegmentCountOdr_intNULL maxRecordSizeOdr_intNULL maxSegmentSizeOdr_intNULL otherInfoZ_OtherInformationNULL
Default settings for PDU Present Response Field Type Default Value referenceIdZ_ReferenceIdNULL numberOfRecordsReturnedOdr_int0 nextResultSetPositionOdr_int0 presentStatusOdr_intZ_PresentStatus_success recordsZ_RecordsNULL otherInfoZ_OtherInformationNULL
Default settings for Delete Result Set Request Field Type Default Value referenceId Z_ReferenceIdNULL deleteFunctionOdr_intZ_DeleteResultSetRequest_list num_idsOdr_int0 resultSetListchar**NULL otherInfoZ_OtherInformationNULL
Default settings for Delete Result Set Response Field Type Default Value referenceIdZ_ReferenceIdNULL deleteOperationStatusOdr_int Z_DeleteStatus_success num_statusesOdr_int0 deleteListStatusesZ_ListStatus**NULL numberNotDeletedOdr_intNULL num_bulkStatusesOdr_int0 bulkStatusesZ_ListStatusNULL deleteMessagechar*NULL otherInfoZ_OtherInformationNULL
Default settings for Scan Request Field Type Default Value referenceIdZ_ReferenceIdNULL num_databaseNamesOdr_int0 databaseNameschar**NULL attributeSetOdr_oidNULL termListAndStartPointZ_AttributesPlus... NULL stepSizeOdr_intNULL numberOfTermsRequestedOdr_int20 preferredPositionInResponseOdr_intNULL otherInfoZ_OtherInformationNULL
Default settings for Scan Response Field Type Default Value referenceIdZ_ReferenceIdNULL stepSizeOdr_intNULL scanStatusOdr_intZ_Scan_success numberOfEntriesReturnedOdr_int0 positionOfTermOdr_intNULL entriesZ_ListEntriesNULL attributeSetOdr_oidNULL otherInfoZ_OtherInformationNULL
Default settings for Trigger Resource Control Request Field Type Default Value referenceIdZ_ReferenceIdNULL requestedActionOdr_int Z_TriggerResourceCtrl_resou.. prefResourceReportFormatOdr_oidNULL resultSetWantedOdr_boolNULL otherInfoZ_OtherInformationNULL
Default settings for Resource Control Request Field Type Default Value referenceIdZ_ReferenceIdNULL suspendedFlagOdr_boolNULL resourceReportZ_ExternalNULL partialResultsAvailableOdr_intNULL responseRequiredOdr_boolFALSE triggeredRequestFlagOdr_boolNULL otherInfoZ_OtherInformationNULL
Default settings for Resource Control Response Field Type Default Value referenceIdZ_ReferenceIdNULL continueFlagbool_tTRUE resultSetWantedbool_tNULL otherInfoZ_OtherInformationNULL
Default settings for Access Control Request Field Type Default Value referenceIdZ_ReferenceIdNULL whichenumZ_AccessRequest_simpleForm; uunionNULL otherInfoZ_OtherInformationNULL
Default settings for Access Control Response Field Type Default Value referenceIdZ_ReferenceIdNULL whichenumZ_AccessResponse_simpleForm uunionNULL diagnosticZ_DiagRecNULL otherInfoZ_OtherInformationNULL
Default settings for Segment Field Type Default Value referenceIdZ_ReferenceIdNULL numberOfRecordsReturnedOdr_intvalue=0 num_segmentRecordsOdr_int0 segmentRecordsZ_NamePlusRecordNULL otherInfoZ_OtherInformationNULL
Default settings for Close Field Type Default Value referenceIdZ_ReferenceIdNULL closeReasonOdr_intZ_Close_finished diagnosticInformationchar*NULL resourceReportFormatOdr_oidNULL resourceFormatZ_ExternalNULL otherInfoZ_OtherInformationNULL
SOAP and SRU Introduction &yaz; uses a very simple implementation of SOAP that only (currently) supports what is sufficient to offer SRU SOAP functionality. The implementation uses the tree API of libxml2 to encode and decode SOAP packages. Like the Z39.50 ASN.1 module, the &yaz; SRU implementation uses simple C structs to represent SOAP packages as well as HTTP packages. HTTP &yaz; only offers HTTP as transport carrier for SOAP, but it is relatively easy to change that. The following definition of Z_GDU (Generic Data Unit) allows for both HTTP and Z39.50 in one packet. #include <yaz/zgdu.h> #define Z_GDU_Z3950 1 #define Z_GDU_HTTP_Request 2 #define Z_GDU_HTTP_Response 3 typedef struct { int which; union { Z_APDU *z3950; Z_HTTP_Request *HTTP_Request; Z_HTTP_Response *HTTP_Response; } u; } Z_GDU ; The corresponding Z_GDU encoder/decoder is z_GDU. The z3950 is any of the known BER encoded Z39.50 APDUs. HTTP_Request and HTTP_Response is the HTTP Request and Response respectively. SOAP Packages Every SOAP package in &yaz; is represented as follows: #include <yaz/soap.h> typedef struct { char *fault_code; char *fault_string; char *details; } Z_SOAP_Fault; typedef struct { int no; char *ns; void *p; } Z_SOAP_Generic; #define Z_SOAP_fault 1 #define Z_SOAP_generic 2 #define Z_SOAP_error 3 typedef struct { int which; union { Z_SOAP_Fault *fault; Z_SOAP_Generic *generic; Z_SOAP_Fault *soap_error; } u; const char *ns; } Z_SOAP; The fault and soap_error arms both represent a SOAP fault - struct Z_SOAP_Fault. Any other generic (valid) package is represented by Z_SOAP_Generic. The ns as part of Z_SOAP is the namespace for SOAP itself and reflects the SOAP version. For version 1.1 it is http://schemas.xmlsoap.org/soap/envelope/, for version 1.2 it is http://www.w3.org/2001/06/soap-envelope. int z_soap_codec(ODR o, Z_SOAP **pp, char **content_buf, int *content_len, Z_SOAP_Handler *handlers); The content_buf and content_len is XML buffer and length of buffer respectively. The handlers is a list of SOAP codec handlers - one handler for each service namespace. For SRU SOAP, the namespace would be http://www.loc.gov/zing/srw/v1.0/. When decoding, the z_soap_codec inspects the XML content and tries to match one of the services namespaces of the supplied handlers. If there is a match. a handler function is invoked which decodes that particular SOAP package. If successful, the returned Z_SOAP package will be of type Z_SOAP_Generic. Member no is set the offset of the handler that matched; ns is set to namespace of the matching handler; the void pointer p is set to the C data structure associated with the handler. When a NULL namespace is met (member ns below), that specifies end-of-list. Each handler is defined as follows: typedef struct { char *ns; void *client_data; Z_SOAP_fun f; } Z_SOAP_Handler; The ns is the namespace of the service associated with handler f. The client_data is user-defined data which is passed to the handler. The prototype for a SOAP service handler is: int handler(ODR o, void * ptr, void **handler_data, void *client_data, const char *ns); The o specifies the mode (decode/encode) as usual. The second argument, ptr, is a libxml2 tree node pointer (xmlNodePtr) and is a pointer to the Body element of the SOAP package. The handler_data is an opaque pointer to C definitions associated with the SOAP service. The client_data is the pointer which was set as part of the Z_SOAP_handler. Finally, ns is the service namespace. SRU SRU SOAP is just one implementation of a SOAP handler as described in the previous section. The encoder/decoder handler for SRU is defined as follows: #include <yaz/srw.h> int yaz_srw_codec(ODR o, void * pptr, Z_SRW_GDU **handler_data, void *client_data, const char *ns); Here, Z_SRW_GDU is either searchRetrieveRequest or a searchRetrieveResponse. The xQuery and xSortKeys are not handled yet by the SRW implementation of &yaz;. Explain is also missing. Future versions of &yaz; will include these features. The definition of searchRetrieveRequest is: typedef struct { #define Z_SRW_query_type_cql 1 #define Z_SRW_query_type_xcql 2 #define Z_SRW_query_type_pqf 3 int query_type; union { char *cql; char *xcql; char *pqf; } query; #define Z_SRW_sort_type_none 1 #define Z_SRW_sort_type_sort 2 #define Z_SRW_sort_type_xSort 3 int sort_type; union { char *none; char *sortKeys; char *xSortKeys; } sort; int *startRecord; int *maximumRecords; char *recordSchema; char *recordPacking; char *database; } Z_SRW_searchRetrieveRequest; Please observe that data of type xsd:string is represented as a char pointer (char *). A null pointer means that the element is absent. Data of type xsd:integer is represented as a pointer to an int (int *). Again, a null pointer is used for absent elements. The SearchRetrieveResponse has the following definition. typedef struct { int * numberOfRecords; char * resultSetId; int * resultSetIdleTime; Z_SRW_record *records; int num_records; Z_SRW_diagnostic *diagnostics; int num_diagnostics; int *nextRecordPosition; } Z_SRW_searchRetrieveResponse; The num_records and num_diagnostics is number of returned records and diagnostics respectively, and also correspond to the "size of" arrays records and diagnostics. A retrieval record is defined as follows: typedef struct { char *recordSchema; char *recordData_buf; int recordData_len; int *recordPosition; } Z_SRW_record; The record data is defined as a buffer of some length so that data can be of any type. SRW 1.0 currently doesn't allow for this (only XML), but future versions might do. And, a diagnostic as: typedef struct { int *code; char *details; } Z_SRW_diagnostic; Supporting Tools In support of the service API - primarily the ASN module, which provides the programmatic interface to the Z39.50 APDUs, &yaz; contains a collection of tools that support the development of applications. Query Syntax Parsers Since the type-1 (RPN) query structure has no direct, useful string representation, every origin application needs to provide some form of mapping from a local query notation or representation to a Z_RPNQuery structure. Some programmers will prefer to construct the query manually, perhaps using odr_malloc() to simplify memory management. The &yaz; distribution includes three separate, query-generating tools that may be of use to you. Prefix Query Format Since RPN or reverse polish notation is really just a fancy way of describing a suffix notation format (operator follows operands), it would seem that the confusion is total when we now introduce a prefix notation for RPN. The reason is one of simple laziness - it's somewhat simpler to interpret a prefix format, and this utility was designed for maximum simplicity, to provide a baseline representation for use in simple test applications and scripting environments (like Tcl). The demonstration client included with YAZ uses the PQF. The PQF has been adopted by other parties developing Z39.50 software. It is often referred to as Prefix Query Notation - PQN. The PQF is defined by the pquery module in the YAZ library. There are two sets of functions that have similar behavior. First set operates on a PQF parser handle, second set doesn't. First set of functions are more flexible than the second set. Second set is obsolete and is only provided to ensure backwards compatibility. First set of functions all operate on a PQF parser handle: #include <yaz/pquery.h> YAZ_PQF_Parser yaz_pqf_create(void); void yaz_pqf_destroy(YAZ_PQF_Parser p); Z_RPNQuery *yaz_pqf_parse(YAZ_PQF_Parser p, ODR o, const char *qbuf); Z_AttributesPlusTerm *yaz_pqf_scan(YAZ_PQF_Parser p, ODR o, Odr_oid **attributeSetId, const char *qbuf); int yaz_pqf_error(YAZ_PQF_Parser p, const char **msg, size_t *off); A PQF parser is created and destructed by functions yaz_pqf_create and yaz_pqf_destroy respectively. Function yaz_pqf_parse parses the query given by string qbuf. If parsing was successful, a Z39.50 RPN Query is returned which is created using ODR stream o. If parsing failed, a NULL pointer is returned. Function yaz_pqf_scan takes a scan query in qbuf. If parsing was successful, the function returns attributes plus term pointer and modifies attributeSetId to hold attribute set for the scan request - both allocated using ODR stream o. If parsing failed, yaz_pqf_scan returns a NULL pointer. Error information for bad queries can be obtained by a call to yaz_pqf_error which returns an error code and modifies *msg to point to an error description, and modifies *off to the offset within the last query where parsing failed. The second set of functions are declared as follows: #include <yaz/pquery.h> Z_RPNQuery *p_query_rpn(ODR o, oid_proto proto, const char *qbuf); Z_AttributesPlusTerm *p_query_scan(ODR o, oid_proto proto, Odr_oid **attributeSetP, const char *qbuf); int p_query_attset(const char *arg); The function p_query_rpn() takes as arguments an &odr; stream (see section The ODR Module) to provide a memory source (the structure created is released on the next call to odr_reset() on the stream), a protocol identifier (one of the constants PROTO_Z3950 and PROTO_SR), an attribute set reference, and finally a null-terminated string holding the query string. If the parse went well, p_query_rpn() returns a pointer to a Z_RPNQuery structure which can be placed directly into a Z_SearchRequest. If parsing failed, due to syntax error, a NULL pointer is returned. The p_query_attset specifies which attribute set to use if the query doesn't specify one by the @attrset operator. The p_query_attset returns 0 if the argument is a valid attribute set specifier; otherwise the function returns -1. The grammar of the PQF is as follows: query ::= top-set query-struct. top-set ::= [ '@attrset' string ] query-struct ::= attr-spec | simple | complex | '@term' term-type query attr-spec ::= '@attr' [ string ] string query-struct complex ::= operator query-struct query-struct. operator ::= '@and' | '@or' | '@not' | '@prox' proximity. simple ::= result-set | term. result-set ::= '@set' string. term ::= string. proximity ::= exclusion distance ordered relation which-code unit-code. exclusion ::= '1' | '0' | 'void'. distance ::= integer. ordered ::= '1' | '0'. relation ::= integer. which-code ::= 'known' | 'private' | integer. unit-code ::= integer. term-type ::= 'general' | 'numeric' | 'string' | 'oid' | 'datetime' | 'null'. You will note that the syntax above is a fairly faithful representation of RPN, except for the Attribute, which has been moved a step away from the term, allowing you to associate one or more attributes with an entire query structure. The parser will automatically apply the given attributes to each term as required. The @attr operator is followed by an attribute specification (attr-spec above). The specification consists of an optional attribute set, an attribute type-value pair and a sub-query. The attribute type-value pair is packed in one string: an attribute type, an equals sign, and an attribute value, like this: @attr 1=1003. The type is always an integer, but the value may be either an integer or a string (if it doesn't start with a digit character). A string attribute-value is encoded as a Type-1 "complex" attribute with the list of values containing the single string specified, and including no semantic indicators. Version 3 of the Z39.50 specification defines various encoding of terms. Use @term type string, where type is one of: general, numeric or string (for InternationalString). If no term type has been given, the general form is used. This is the only encoding allowed in both versions 2 and 3 of the Z39.50 standard. Using Proximity Operators with PQF This is an advanced topic, describing how to construct queries that make very specific requirements on the relative location of their operands. You may wish to skip this section and go straight to the example PQF queries. Most Z39.50 servers do not support proximity searching, or support only a small subset of the full functionality that can be expressed using the PQF proximity operator. Be aware that the ability to express a query in PQF is no guarantee that any given server will be able to execute it. The proximity operator @prox is a special and more restrictive version of the conjunction operator @and. Its semantics are described in section 3.7.2 (Proximity) of Z39.50 the standard itself, which can be read on-line at In PQF, the proximity operation is represented by a sequence of the form @prox exclusion distance ordered relation which-code unit-code in which the meanings of the parameters are as described in the standard, and they can take the following values: exclusion 0 = false (i.e. the proximity condition specified by the remaining parameters must be satisfied) or 1 = true (the proximity condition specified by the remaining parameters must not be satisfied). distance An integer specifying the difference between the locations of the operands: e.g. two adjacent words would have distance=1 since their locations differ by one unit. ordered 1 = ordered (the operands must occur in the order the query specifies them) or 0 = unordered (they may appear in either order). relation Recognised values are 1 (lessThan), 2 (lessThanOrEqual), 3 (equal), 4 (greaterThanOrEqual), 5 (greaterThan) and 6 (notEqual). which-code known or k (the unit-code parameter is taken from the well-known list of alternatives described below) or private or p (the unit-code parameter has semantics specific to an out-of-band agreement such as a profile). unit-code If the which-code parameter is known then the recognised values are 1 (character), 2 (word), 3 (sentence), 4 (paragraph), 5 (section), 6 (chapter), 7 (document), 8 (element), 9 (subelement), 10 (elementType) and 11 (byte). If which-code is private then the acceptable values are determined by the profile. (The numeric values of the relation and well-known unit-code parameters are taken straight from the ASN.1 of the proximity structure in the standard.) PQF queries PQF queries using simple terms dylan "bob dylan" PQF boolean operators @or "dylan" "zimmerman" @and @or dylan zimmerman when @and when @or dylan zimmerman PQF references to result sets @set Result-1 @and @set seta @set setb Attributes for terms @attr 1=4 computer @attr 1=4 @attr 4=1 "self portrait" @attrset exp1 @attr 1=1 CategoryList @attr gils 1=2008 Copenhagen @attr 1=/book/title computer PQF Proximity queries @prox 0 3 1 2 k 2 dylan zimmerman Here the parameters 0, 3, 1, 2, k and 2 represent exclusion, distance, ordered, relation, which-code and unit-code, in that order. So: exclusion = 0: the proximity condition must hold distance = 3: the terms must be three units apart ordered = 1: they must occur in the order they are specified relation = 2: lessThanOrEqual (to the distance of 3 units) which-code is "known", so the standard unit-codes are used unit-code = 2: word. So the whole proximity query means that the words dylan and zimmerman must both occur in the record, in that order, differing in position by three or fewer words (i.e. with two or fewer words between them.) The query would find "Bob Dylan, aka. Robert Zimmerman", but not "Bob Dylan, born as Robert Zimmerman" since the distance in this case is four. PQF specification of search term type @term string "a UTF-8 string, maybe?" PQF mixed queries @or @and bob dylan @set Result-1 @attr 4=1 @and @attr 1=1 "bob dylan" @attr 1=4 "slow train coming" @and @attr 2=4 @attr gils 1=2038 -114 @attr 2=2 @attr gils 1=2039 -109 The last of these examples is a spatial search: in the GILS attribute set, access point 2038 indicates West Bounding Coordinate and 2030 indicates East Bounding Coordinate, so the query is for areas extending from -114 degrees longitude to no more than -109 degrees longitude. CCL Not all users enjoy typing in prefix query structures and numerical attribute values, even in a minimalistic test client. In the library world, the more intuitive Common Command Language - CCL (ISO 8777) has enjoyed some popularity - especially before the widespread availability of graphical interfaces. It is still useful in applications where you for some reason or other need to provide a symbolic language for expressing boolean query structures. CCL Syntax The CCL parser obeys the following grammar for the FIND argument. The syntax is annotated using lines prefixed by --. CCL-Find ::= CCL-Find Op Elements | Elements. Op ::= "and" | "or" | "not" -- The above means that Elements are separated by boolean operators. Elements ::= '(' CCL-Find ')' | Set | Terms | Qualifiers Relation Terms | Qualifiers Relation '(' CCL-Find ')' | Qualifiers '=' string '-' string -- Elements is either a recursive definition, a result set reference, a -- list of terms, qualifiers followed by terms, qualifiers followed -- by a recursive definition or qualifiers in a range (lower - upper). Set ::= 'set' = string -- Reference to a result set Terms ::= Terms Prox Term | Term -- Proximity of terms. Term ::= Term string | string -- This basically means that a term may include a blank Qualifiers ::= Qualifiers ',' string | string -- Qualifiers is a list of strings separated by comma Relation ::= '=' | '>=' | '<=' | '<>' | '>' | '<' -- Relational operators. This really doesn't follow the ISO8777 -- standard. Prox ::= '%' | '!' -- Proximity operator CCL queries The following queries are all valid: dylan "bob dylan" dylan or zimmerman set=1 (dylan and bob) or set=1 righttrunc? "notrunc?" singlechar#mask Assuming that the qualifiers ti and au and date are defined, we may use: ti=self portrait au=(bob dylan and slow train coming) date>1980 and (ti=((self portrait))) CCL Qualifiers Qualifiers are used to direct the search to a particular searchable index, such as title (ti) and author indexes (au). The CCL standard itself doesn't specify a particular set of qualifiers, but it does suggest a few short-hand notations. You can customize the CCL parser to support a particular set of qualifiers to reflect the current target profile. Traditionally, a qualifier would map to a particular use-attribute within the BIB-1 attribute set. It is also possible to set other attributes, such as the structure attribute. A CCL profile is a set of predefined CCL qualifiers that may be read from a file or set in the CCL API. The YAZ client reads its CCL qualifiers from a file named default.bib. There are four types of lines in a CCL profile: qualifier specification, qualifier alias, comments and directives. Qualifier specification A qualifier specification is of the form: qualifier-name [attributeset,]type=val [attributeset,]type=val ... where qualifier-name is the name of the qualifier to be used (e.g. ti), type is attribute type in the attribute set (Bib-1 is used if no attribute set is given) and val is attribute value. The type can be specified as an integer, or as a single-letter: u for use, r for relation, p for position, s for structure,t for truncation, or c for completeness. The attributes for the special qualifier name term are used when no CCL qualifier is given in a query. Common Bib-1 attributes Type Description u=value Use attribute (1). Common use attributes are 1 Personal-name, 4 Title, 7 ISBN, 8 ISSN, 30 Date, 62 Subject, 1003 Author, 1016 Any. Specify value as an integer. r=value Relation attribute (2). Common values are 1 <, 2 <=, 3 =, 4 >=, 5 >, 6 <>, 100 phonetic, 101 stem, 102 relevance, 103 always matches. p=value Position attribute (3). Values: 1 first in field, 2 first in any subfield, 3 any position in field. s=value Structure attribute (4). Values: 1 phrase, 2 word, 3 key, 4 year, 5 date, 6 word list, 100 date (un), 101 name (norm), 102 name (un), 103 structure, 104 urx, 105 free-form-text, 106 document-text, 107 local-number, 108 string, 109 numeric string. t=value Truncation attribute (5). Values: 1 right, 2 left, 3 left and right, 100 none, 101 process #, 102 regular-1, 103 regular-2, 104 CCL. c=value Completeness attribute (6). Values: 1 incomplete subfield, 2 complete subfield, 3 complete field.
Refer to or the complete list of Bib-1 attributes It is also possible to specify non-numeric attribute values, which are used in combination with certain types. The special combinations are: Special attribute combos Name Description s=pw The structure is set to either word or phrase depending on the number of tokens in a term (phrase-word). s=al Each token in the term is ANDed (and-list). This does not set the structure at all. s=ol Each token in the term is ORed (or-list). This does not set the structure at all. s=ag Tokens that appears as phrases (with blank in them) gets structure phrase attached (4=1). Tokens that appear to be words gets structure word attached (4=2). Phrases and words are ANDed. This is a variant of s=al and s=pw, with the main difference that words are not split (with operator AND) but instead kept in one RPN token. This facility appeared in YAZ 4.2.38. s=sl Tokens are split into sub-phrases of all combinations - in order. This facility appeared in YAZ 5.14.0. r=o Allows ranges and the operators greater-than, less-than, ... equals. This sets Bib-1 relation attribute accordingly (relation ordered). A query construct is only treated as a range if dash is used and that is surrounded by white-space. So -1980 is treated as term "-1980" not <= 1980. If - 1980 is used, however, that is treated as a range. r=r Similar to r=o but assumes that terms are non-negative (not prefixed with -). Thus, a dash will always be treated as a range. The construct 1980-1990 is treated as a range with r=r but as a single term "1980-1990" with r=o. The special attribute r=r is available in YAZ 2.0.24 or later. r=omiteq This will omit relation=equals (@attr 2=3) when r=o / r=r is used. This is useful for servers that somehow break when an explicit relation=equals is used. Omitting the relation is usually safe because "equals" is the default behavior. This tweak was added in YAZ version 5.1.2. t=l Allows term to be left-truncated. If term is of the form ?x, the resulting Type-1 term is x and truncation is left. t=r Allows term to be right-truncated. If term is of the form x?, the resulting Type-1 term is x and truncation is right. t=n If term is does not include ?, the truncation attribute is set to none (100). t=b Allows term to be both left-and-right truncated. If term is of the form ?x?, the resulting term is x and truncation is set to both left and right. t=x Allows masking anywhere in a term, thus fully supporting # (mask one character) and ? (zero or more of any). If masking is used, truncation is set to 102 (regexp-1 in term) and the term is converted accordingly to a regular expression. t=z Allows masking anywhere in a term, thus fully supporting # (mask one character) and ? (zero or more of any). If masking is used, truncation is set to 104 (Z39.58 in term) and the term is converted accordingly to Z39.58 masking term - actually the same truncation as CCL itself.
CCL profile Consider the following definition: ti u=4 s=1 au u=1 s=1 term s=105 ranked r=102 date u=30 r=o ti and au both set structure attribute to phrase (s=1). ti sets the use-attribute to 4. au sets the use-attribute to 1. When no qualifiers are used in the query, the structure-attribute is set to free-form-text (105) (rule for term). The date sets the relation attribute to the relation used in the CCL query and sets the use attribute to 30 (Bib-1 Date). You can combine attributes. To Search for "ranked title" you can do ti,ranked=knuth computer which will set relation=ranked, use=title, structure=phrase. Query date > 1980 is a valid query. But ti > 1980 is invalid. Qualifier alias A qualifier alias is of the form: q q1 q2 .. which declares q to be an alias for q1, q2... such that the CCL query q=x is equivalent to q1=x or q2=x or .... Comments Lines with white space or lines that begin with character # are treated as comments. Directives Directive specifications takes the form @directive value CCL directives Name Description Default truncation Truncation character ? mask Masking character. Requires YAZ 4.2.58 or later # field Specifies how multiple fields are to be combined. There are two modes: or: multiple qualifier fields are ORed, merge: attributes for the qualifier fields are merged and assigned to one term. merge case Specifies if CCL operators and qualifiers should be compared with case sensitivity or not. Specify 1 for case sensitive; 0 for case insensitive. 1 and Specifies token for CCL operator AND. and or Specifies token for CCL operator OR. or not Specifies token for CCL operator NOT. not set Specifies token for CCL operator SET. set
CCL API All public definitions can be found in the header file ccl.h. A profile identifier is of type CCL_bibset. A profile must be created with the call to the function ccl_qual_mk which returns a profile handle of type CCL_bibset. To read a file containing qualifier definitions the function ccl_qual_file may be convenient. This function takes an already opened FILE handle pointer as argument along with a CCL_bibset handle. To parse a simple string with a FIND query use the function struct ccl_rpn_node *ccl_find_str(CCL_bibset bibset, const char *str, int *error, int *pos); which takes the CCL profile (bibset) and query (str) as input. Upon successful completion the RPN tree is returned. If an error occurs, such as a syntax error, the integer pointed to by error holds the error code and pos holds the offset inside query string in which the parsing failed. An English representation of the error may be obtained by calling the ccl_err_msg function. The error codes are listed in ccl.h. To convert the CCL RPN tree (type struct ccl_rpn_node *) to the Z_RPNQuery of YAZ the function ccl_rpn_query must be used. This function which is part of YAZ is implemented in yaz-ccl.c. After calling this function the CCL RPN tree is probably no longer needed. The ccl_rpn_delete destroys the CCL RPN tree. A CCL profile may be destroyed by calling the ccl_qual_rm function. The token names for the CCL operators may be changed by setting the globals (all type char *) ccl_token_and, ccl_token_or, ccl_token_not and ccl_token_set. An operator may have aliases, i.e. there may be more than one name for the operator. To do this, separate each alias with a space character. CQL CQL - Common Query Language - was defined for the SRU protocol. In many ways CQL has a similar syntax to CCL. The objective of CQL is different. Where CCL aims to be an end-user language, CQL is the protocol query language for SRU. If you are new to CQL, read the Gentle Introduction. The CQL parser in &yaz; provides the following: It parses and validates a CQL query. It generates a C structure that allows you to convert a CQL query to some other query language, such as SQL. The parser converts a valid CQL query to PQF, thus providing a way to use CQL for both SRU servers and Z39.50 targets at the same time. The parser converts CQL to XCQL. XCQL is an XML representation of CQL. XCQL is part of the SRU specification. However, since SRU supports CQL only, we don't expect XCQL to be widely used. Furthermore, CQL has the advantage over XCQL that it is easy to read. CQL parsing A CQL parser is represented by the CQL_parser handle. Its contents should be considered &yaz; internal (private). #include <yaz/cql.h> typedef struct cql_parser *CQL_parser; CQL_parser cql_parser_create(void); void cql_parser_destroy(CQL_parser cp); A parser is created by cql_parser_create and is destroyed by cql_parser_destroy. To parse a CQL query string, the following function is provided: int cql_parser_string(CQL_parser cp, const char *str); A CQL query is parsed by the cql_parser_string which takes a query str. If the query was valid (no syntax errors), then zero is returned; otherwise -1 is returned to indicate a syntax error. int cql_parser_stream(CQL_parser cp, int (*getbyte)(void *client_data), void (*ungetbyte)(int b, void *client_data), void *client_data); int cql_parser_stdio(CQL_parser cp, FILE *f); The functions cql_parser_stream and cql_parser_stdio parse a CQL query - just like cql_parser_string. The only difference is that the CQL query can be fed to the parser in different ways. The cql_parser_stream uses a generic byte stream as input. The cql_parser_stdio uses a FILE handle which is opened for reading. CQL tree If the query string is valid, the CQL parser generates a tree representing the structure of the CQL query. struct cql_node *cql_parser_result(CQL_parser cp); cql_parser_result returns a pointer to the root node of the resulting tree. Each node in a CQL tree is represented by a struct cql_node. It is defined as follows: #define CQL_NODE_ST 1 #define CQL_NODE_BOOL 2 #define CQL_NODE_SORT 3 struct cql_node { int which; union { struct { char *index; char *index_uri; char *term; char *relation; char *relation_uri; struct cql_node *modifiers; } st; struct { char *value; struct cql_node *left; struct cql_node *right; struct cql_node *modifiers; } boolean; struct { char *index; struct cql_node *next; struct cql_node *modifiers; struct cql_node *search; } sort; } u; }; There are three node types: search term (ST), boolean (BOOL) and sortby (SORT). A modifier is treated as a search term too. The search term node has five members: index: index for search term. If an index is unspecified for a search term, index will be NULL. index_uri: index URI for search term or NULL if none could be resolved for the index. term: the search term itself. relation: relation for search term. relation_uri: relation URI for search term. modifiers: relation modifiers for search term. The modifiers list itself of cql_nodes each of type ST. The boolean node represents and, or, not + proximity. left and right: left - and right operand respectively. modifiers: proximity arguments. The sort node represents both the SORTBY clause. CQL to PQF conversion Conversion to PQF (and Z39.50 RPN) is tricky by the fact that the resulting RPN depends on the Z39.50 target capabilities (combinations of supported attributes). In addition, the CQL and SRU operates on index prefixes (URI or strings), whereas the RPN uses Object Identifiers for attribute sets. The CQL library of &yaz; defines a cql_transform_t handle. It represents a particular mapping between CQL and RPN. This handle is created and destroyed by the functions: cql_transform_t cql_transform_create(void); int cql_transform_define_fname(cql_transform_t *ct, const char *fname); int cql_transform_define_FILE(cql_trasnform_t *ct, FILE *f); void cql_transform_close(cql_transform_t ct); The first method constructs a handle. The second and third functon extends the configuration by reading from a file or an open FILE handle. The transform handle is destroyed by cql_transform_close in which case no further reference of the handle is allowed. There are also two methods which creates and reads configuration from a file combined: cql_transform_t cql_transform_open_FILE (FILE *f); cql_transform_t cql_transform_open_fname(const char *fname); When a cql_transform_t handle has been created you can convert to RPN. int cql_transform_buf(cql_transform_t ct, struct cql_node *cn, char *out, int max); This function converts the CQL tree cn using handle ct. For the resulting PQF, you supply a buffer out which must be able to hold at at least max characters. If conversion failed, cql_transform_buf returns a non-zero SRU error code; otherwise zero is returned (conversion successful). The meanings of the numeric error codes are listed in the SRU specification somewhere (no direct link anymore). If conversion fails, more information can be obtained by calling int cql_transform_error(cql_transform_t ct, char **addinfop); This function returns the most recently returned numeric error-code and sets the string-pointer at *addinfop to point to a string containing additional information about the error that occurred: for example, if the error code is 15 ("Illegal or unsupported context set"), the additional information is the name of the requested context set that was not recognised. The SRU error-codes may be translated into brief human-readable error messages using const char *cql_strerror(int code); If you wish to be able to produce a PQF result in a different way, there are two alternatives. void cql_transform_pr(cql_transform_t ct, struct cql_node *cn, void (*pr)(const char *buf, void *client_data), void *client_data); int cql_transform_FILE(cql_transform_t ct, struct cql_node *cn, FILE *f); The former function produces output to a user-defined output stream. The latter writes the result to an already open FILE. Specification of CQL to RPN mappings The file supplied to functions cql_transform_open_FILE, cql_transform_open_fname follows a structure found in many Unix utilities. It consists of mapping specifications - one per line. Lines starting with # are ignored (comments). Each line is of the form CQL pattern = RPN equivalent An RPN pattern is a simple attribute list. Each attribute pair takes the form: [set] type=value The attribute set is optional. The type is the attribute type, value the attribute value. The character * (asterisk) has special meaning when used in the RPN pattern. Each occurrence of * is substituted with the CQL matching name (index, relation, qualifier etc). This facility can be used to copy a CQL name verbatim to the RPN result. The following CQL patterns are recognized: index.set.name This pattern is invoked when a CQL index, such as dc.title is converted. set and name are the context set and index name respectively. Typically, the RPN specifies an equivalent use attribute. For terms not bound by an index, the pattern index.cql.serverChoice is used. Here, the prefix cql is defined as http://www.loc.gov/zing/cql/cql-indexes/v1.0/. If this pattern is not defined, the mapping will fail. The pattern, index.set.* is used when no other index pattern is matched. qualifier.set.name (DEPRECATED) For backwards compatibility, this is recognised as a synonym of index.set.name relation.relation This pattern specifies how a CQL relation is mapped to RPN. The pattern is name of relation operator. Since = is used as separator between CQL pattern and RPN, CQL relations including = cannot be used directly. To avoid a conflict, the names ge, eq, le, must be used for CQL operators, greater-than-or-equal, equal, less-than-or-equal respectively. The RPN pattern is supposed to include a relation attribute. For terms not bound by a relation, the pattern relation.scr is used. If the pattern is not defined, the mapping will fail. The special pattern, relation.* is used when no other relation pattern is matched. relationModifier.mod This pattern specifies how a CQL relation modifier is mapped to RPN. The RPN pattern is usually a relation attribute. structure.type This pattern specifies how a CQL structure is mapped to RPN. Note that this CQL pattern is somewhat similar to CQL pattern relation. The type is a CQL relation. The pattern, structure.* is used when no other structure pattern is matched. Usually, the RPN equivalent specifies a structure attribute. position.type This pattern specifies how the anchor (position) of CQL is mapped to RPN. The type is one of first, any, last, firstAndLast. The pattern, position.* is used when no other position pattern is matched. set.prefix This specification defines a CQL context set for a given prefix. The value on the right hand side is the URI for the set - not RPN. All prefixes used in index patterns must be defined this way. set This specification defines a default CQL context set for index names. The value on the right hand side is the URI for the set. CQL to RPN mapping file This simple file defines two context sets, three indexes and three relations, a position pattern and a default structure. With the mappings above, the CQL query computer is converted to the PQF: @attr 1=1016 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "computer" by rules index.cql.serverChoice, relation.scr, structure.*, position.any. CQL query computer^ is rejected, since position.right is undefined. CQL query >my = "http://www.loc.gov/zing/cql/dc-indexes/v1.0/" my.title = x is converted to @attr 1=4 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "x" CQL to RPN string attributes In this example we allow any index to be passed to RPN as a use attribute. The http://bogus/rpn context set is also the default so we can make queries such as title = a which is converted to @attr 2=3 @attr 4=1 @attr 3=3 @attr 1=title "a" CQL to RPN using Bath Profile The file etc/pqf.properties has mappings from the Bath Profile and Dublin Core to RPN. If YAZ is installed as a package it's usually located in /usr/share/yaz/etc and part of the development package, such as libyaz-dev. CQL to XCQL conversion Conversion from CQL to XCQL is trivial and does not require a mapping to be defined. There are three functions to choose from depending on the way you wish to store the resulting output (XML buffer containing XCQL). int cql_to_xml_buf(struct cql_node *cn, char *out, int max); void cql_to_xml(struct cql_node *cn, void (*pr)(const char *buf, void *client_data), void *client_data); void cql_to_xml_stdio(struct cql_node *cn, FILE *f); Function cql_to_xml_buf converts to XCQL and stores the result in a user-supplied buffer of a given max size. cql_to_xml writes the result in a user-defined output stream. cql_to_xml_stdio writes to a a file. PQF to CQL conversion Conversion from PQF to CQL is offered by the two functions shown below. The former uses a generic stream for result. The latter puts result in a WRBUF (string container). #include <yaz/rpn2cql.h> int cql_transform_rpn2cql_stream(cql_transform_t ct, void (*pr)(const char *buf, void *client_data), void *client_data, Z_RPNQuery *q); int cql_transform_rpn2cql_wrbuf(cql_transform_t ct, WRBUF w, Z_RPNQuery *q); The configuration is the same as used in CQL to PQF conversions. Object Identifiers The basic YAZ representation of an OID is an array of integers, terminated with the value -1. This integer is of type Odr_oid. Fundamental OID operations and the type Odr_oid are defined in yaz/oid_util.h. An OID can either be declared as a automatic variable or it can be allocated using the memory utilities or ODR/NMEM. It's guaranteed that an OID can fit in OID_SIZE integers. Create OID on stack We can create an OID for the Bib-1 attribute set with: Odr_oid bib1[OID_SIZE]; bib1[0] = 1; bib1[1] = 2; bib1[2] = 840; bib1[3] = 10003; bib1[4] = 3; bib1[5] = 1; bib1[6] = -1; And OID may also be filled from a string-based representation using dots (.). This is achieved by the function int oid_dotstring_to_oid(const char *name, Odr_oid *oid); This functions returns 0 if name could be converted; -1 otherwise. Using oid_oiddotstring_to_oid We can fill the Bib-1 attribute set OID more easily with: Odr_oid bib1[OID_SIZE]; oid_oiddotstring_to_oid("1.2.840.10003.3.1", bib1); We can also allocate an OID dynamically on an ODR stream with: Odr_oid *odr_getoidbystr(ODR o, const char *str); This creates an OID from a string-based representation using dots. This function take an &odr; stream as parameter. This stream is used to allocate memory for the data elements, which is released on a subsequent call to odr_reset() on that stream. Using odr_getoidbystr We can create an OID for the Bib-1 attribute set with: Odr_oid *bib1 = odr_getoidbystr(odr, "1.2.840.10003.3.1"); The function char *oid_oid_to_dotstring(const Odr_oid *oid, char *oidbuf) does the reverse of oid_oiddotstring_to_oid. It converts an OID to the string-based representation using dots. The supplied char buffer oidbuf holds the resulting string and must be at least OID_STR_MAX in size. OIDs can be copied with oid_oidcpy which takes two OID lists as arguments. Alternatively, an OID copy can be allocated on an ODR stream with: Odr_oid *odr_oiddup(ODR odr, const Odr_oid *o); OIDs can be compared with oid_oidcmp which returns zero if the two OIDs provided are identical; non-zero otherwise. OID database From YAZ version 3 and later, the oident system has been replaced by an OID database. OID database is a misnomer .. the old odient system was also a database. The OID database is really just a map between named Object Identifiers (string) and their OID raw equivalents. Most operations either convert from string to OID or other way around. Unfortunately, whenever we supply a string we must also specify the OID class. The class is necessary because some strings correspond to multiple OIDs. An example of such a string is Bib-1 which may either be an attribute-set or a diagnostic-set. Applications using the YAZ database should include yaz/oid_db.h. A YAZ database handle is of type yaz_oid_db_t. Actually that's a pointer. You need not deal with that. YAZ has a built-in database which can be considered "constant" for most purposes. We can get hold of that by using function yaz_oid_std. All functions with prefix yaz_string_to_oid converts from class + string to OID. We have variants of this operation due to different memory allocation strategies. All functions with prefix yaz_oid_to_string converts from OID to string + class. Create OID with YAZ DB We can create an OID for the Bib-1 attribute set on the ODR stream odr with: Odr_oid *bib1 = yaz_string_to_oid_odr(yaz_oid_std(), CLASS_ATTSET, "Bib-1", odr); This is more complex than using odr_getoidbystr. You would only use yaz_string_to_oid_odr when the string (here Bib-1) is supplied by a user or configuration. Standard OIDs All the object identifiers in the standard OID database as returned by yaz_oid_std can be referenced directly in a program as a constant OID. Each constant OID is prefixed with yaz_oid_ - followed by OID class (lowercase) - then by OID name (normalized and lowercase). See for list of all object identifiers built into YAZ. These are declared in yaz/oid_std.h but are included by yaz/oid_db.h as well. Use a built-in OID We can allocate our own OID filled with the constant OID for Bib-1 with: Odr_oid *bib1 = odr_oiddup(o, yaz_oid_attset_bib1); Nibble Memory Sometimes when you need to allocate and construct a large, interconnected complex of structures, it can be a bit of a pain to release the associated memory again. For the structures describing the Z39.50 PDUs and related structures, it is convenient to use the memory-management system of the &odr; subsystem (see ). However, in some circumstances where you might otherwise benefit from using a simple nibble-memory management system, it may be impractical to use odr_malloc() and odr_reset(). For this purpose, the memory manager which also supports the &odr; streams is made available in the NMEM module. The external interface to this module is given in the nmem.h file. The following prototypes are given: NMEM nmem_create(void); void nmem_destroy(NMEM n); void *nmem_malloc(NMEM n, size_t size); void nmem_reset(NMEM n); size_t nmem_total(NMEM n); void nmem_init(void); void nmem_exit(void); The nmem_create() function returns a pointer to a memory control handle, which can be released again by nmem_destroy() when no longer needed. The function nmem_malloc() allocates a block of memory of the requested size. A call to nmem_reset() or nmem_destroy() will release all memory allocated on the handle since it was created (or since the last call to nmem_reset(). The function nmem_total() returns the number of bytes currently allocated on the handle. The nibble-memory pool is shared amongst threads. POSIX mutexes and WIN32 Critical sections are introduced to keep the module thread safe. Function nmem_init() initializes the nibble-memory library and it is called automatically the first time the YAZ.DLL is loaded. &yaz; uses function DllMain to achieve this. You should not call nmem_init or nmem_exit unless you're absolute sure what you're doing. Note that in previous &yaz; versions you'd have to call nmem_init yourself. Log &yaz; has evolved a fairly complex log system which should be useful both for debugging &yaz; itself, debugging applications that use &yaz;, and for production use of those applications. The log functions are declared in header yaz/log.h and implemented in src/log.c. Due to name clash with syslog and some math utilities the logging interface has been modified as of YAZ 2.0.29. The obsolete interface is still available in header file yaz/log.h. The key points of the interface are: void yaz_log(int level, const char *fmt, ...) void yaz_log_init(int level, const char *prefix, const char *name); void yaz_log_init_file(const char *fname); void yaz_log_init_level(int level); void yaz_log_init_prefix(const char *prefix); void yaz_log_time_format(const char *fmt); void yaz_log_init_max_size(int mx); int yaz_log_mask_str(const char *str); int yaz_log_module_level(const char *name); The reason for the whole log module is the yaz_log function. It takes a bitmask indicating the log levels, a printf-like format string, and a variable number of arguments to log. The log level is a bit mask, that says on which level(s) the log entry should be made, and optionally set some behaviour of the logging. In the most simple cases, it can be one of YLOG_FATAL, YLOG_DEBUG, YLOG_WARN, YLOG_LOG. Those can be combined with bits that modify the way the log entry is written:YLOG_ERRNO, YLOG_NOTIME, YLOG_FLUSH. Most of the rest of the bits are deprecated, and should not be used. Use the dynamic log levels instead. Applications that use &yaz;, should not use the LOG_LOG for ordinary messages, but should make use of the dynamic loglevel system. This consists of two parts, defining the loglevel and checking it. To define the log levels, the (main) program should pass a string to yaz_log_mask_str to define which log levels are to be logged. This string should be a comma-separated list of log level names, and can contain both hard-coded names and dynamic ones. The log level calculation starts with YLOG_DEFAULT_LEVEL and adds a bit for each word it meets, unless the word starts with a '-', in which case it clears the bit. If the string 'none' is found, all bits are cleared. Typically this string comes from the command-line, often identified by -v. The yaz_log_mask_str returns a log level that should be passed to yaz_log_init_level for it to take effect. Each module should check what log bits should be used, by calling yaz_log_module_level with a suitable name for the module. The name is cleared of a preceding path and an extension, if any, so it is quite possible to use __FILE__ for it. If the name has been passed to yaz_log_mask_str, the routine returns a non-zero bitmask, which should then be used in consequent calls to yaz_log. (It can also be tested, so as to avoid unnecessary calls to yaz_log, in time-critical places, or when the log entry would take time to construct.) Yaz uses the following dynamic log levels: server, session, request, requestdetail for the server functionality. zoom for the zoom client API. ztest for the simple test server. malloc, nmem, odr, eventl for internal debugging of yaz itself. Of course, any program using yaz is welcome to define as many new ones as it needs. By default the log is written to stderr, but this can be changed by a call to yaz_log_init_file or yaz_log_init. If the log is directed to a file, the file size is checked at every write, and if it exceeds the limit given in yaz_log_init_max_size, the log is rotated. The rotation keeps one old version (with a .1 appended to the name). The size defaults to 1GB. Setting it to zero will disable the rotation feature. A typical yaz-log looks like this 13:23:14-23/11 yaz-ztest(1) [session] Starting session from tcp:127.0.0.1 (pid=30968) 13:23:14-23/11 yaz-ztest(1) [request] Init from 'YAZ' (81) (ver 2.0.28) OK 13:23:17-23/11 yaz-ztest(1) [request] Search Z: @attrset Bib-1 foo OK:7 hits 13:23:22-23/11 yaz-ztest(1) [request] Present: [1] 2+2 OK 2 records returned 13:24:13-23/11 yaz-ztest(1) [request] Close OK The log entries start with a time stamp. This can be omitted by setting the YLOG_NOTIME bit in the loglevel. This way automatic tests can be hoped to produce identical log files, that are easy to diff. The format of the time stamp can be set with yaz_log_time_format, which takes a format string just like strftime. Next in a log line comes the prefix, often the name of the program. For yaz-based servers, it can also contain the session number. Then comes one or more logbits in square brackets, depending on the logging level set by yaz_log_init_level and the loglevel passed to yaz_log_init_level. Finally comes the format string and additional values passed to yaz_log The log level YLOG_LOGLVL, enabled by the string loglevel, will log all the log-level affecting operations. This can come in handy if you need to know what other log levels would be useful. Grep the logfile for [loglevel]. The log system is almost independent of the rest of &yaz;, the only important dependence is of nmem, and that only for using the semaphore definition there. The dynamic log levels and log rotation were introduced in &yaz; 2.0.28. At the same time, the log bit names were changed from LOG_something to YLOG_something, to avoid collision with syslog.h. MARC YAZ provides a fast utility for working with MARC records. Early versions of the MARC utility only allowed decoding of ISO2709. Today the utility may both encode - and decode to a variety of formats. /* create handler */ yaz_marc_t yaz_marc_create(void); /* destroy */ void yaz_marc_destroy(yaz_marc_t mt); /* set XML mode YAZ_MARC_LINE, YAZ_MARC_SIMPLEXML, ... */ void yaz_marc_xml(yaz_marc_t mt, int xmlmode); #define YAZ_MARC_LINE 0 #define YAZ_MARC_SIMPLEXML 1 #define YAZ_MARC_OAIMARC 2 #define YAZ_MARC_MARCXML 3 #define YAZ_MARC_ISO2709 4 #define YAZ_MARC_XCHANGE 5 #define YAZ_MARC_CHECK 6 #define YAZ_MARC_TURBOMARC 7 #define YAZ_MARC_JSON 8 /* supply iconv handle for character set conversion .. */ void yaz_marc_iconv(yaz_marc_t mt, yaz_iconv_t cd); /* set debug level, 0=none, 1=more, 2=even more, .. */ void yaz_marc_debug(yaz_marc_t mt, int level); /* decode MARC in buf of size bsize. Returns >0 on success; <=0 on failure. On success, result in *result with size *rsize. */ int yaz_marc_decode_buf(yaz_marc_t mt, const char *buf, int bsize, const char **result, size_t *rsize); /* decode MARC in buf of size bsize. Returns >0 on success; <=0 on failure. On success, result in WRBUF */ int yaz_marc_decode_wrbuf(yaz_marc_t mt, const char *buf, int bsize, WRBUF wrbuf); ]]> The synopsis is just a basic subset of all functionality. Refer to the actual header file marcdisp.h for details. A MARC conversion handle must be created by using yaz_marc_create and destroyed by calling yaz_marc_destroy. All other functions operate on a yaz_marc_t handle. The output is specified by a call to yaz_marc_xml. The xmlmode must be one of YAZ_MARC_LINE A simple line-by-line format suitable for display but not recommended for further (machine) processing. YAZ_MARC_MARCXML MARCXML. YAZ_MARC_ISO2709 ISO2709 (sometimes just referred to as "MARC"). YAZ_MARC_XCHANGE MarcXchange. YAZ_MARC_CHECK Pseudo format for validation only. Does not generate any real output except diagnostics. YAZ_MARC_TURBOMARC XML format with same semantics as MARCXML but more compact and geared towards fast processing with XSLT. Refer to for more information. YAZ_MARC_JSON MARC-in-JSON format. The actual conversion functions are yaz_marc_decode_buf and yaz_marc_decode_wrbuf which decodes and encodes a MARC record. The former function operates on simple buffers, and stores the resulting record in a WRBUF handle (WRBUF is a simple string type). Display of MARC record The following program snippet illustrates how the MARC API may be used to convert a MARC record to the line-by-line format: TurboMARC TurboMARC is yet another XML encoding of a MARC record. The format was designed for fast processing with XSLT. Applications like Pazpar2 uses XSLT to convert an XML encoded MARC record to an internal representation. This conversion mostly checks the tag of a MARC field to determine the basic rules in the conversion. This check is costly when that tag is encoded as an attribute in MARCXML. By having the tag value as the element instead, makes processing many times faster (at least for Libxslt). TurboMARC is encoded as follows: Record elements is part of namespace "http://www.indexdata.com/turbomarc". A record is enclosed in element r. A collection of records is enclosed in element collection. The leader is encoded as element l with the leader content as its (text) value. A control field is encoded as element c concatenated with the tag value of the control field if the tag value matches the regular expression [a-zA-Z0-9]*. If the tag value does not match the regular expression [a-zA-Z0-9]* the control field is encoded as element c and attribute code will hold the tag value. This rule ensures that in the rare cases where a tag value might result in a non-well-formed XML, then YAZ will encode it as a coded attribute (as in MARCXML). The control field content is the text value of this element. Indicators are encoded as attribute names i1, i2, etc. and corresponding values for each indicator. A data field is encoded as element d concatenated with the tag value of the data field or using the attribute code as described in the rules for control fields. The children of the data field element are subfield elements. Each subfield element is encoded as s concatenated with the sub field code. The text of the subfield element is the contents of the subfield. Indicators are encoded as attributes for the data field element, similar to the encoding for control fields. Retrieval Facility YAZ version 2.1.20 or later includes a Retrieval facility tool which allows a SRU/Z39.50 to describe itself and perform record conversions. The idea is the following: An SRU/Z39.50 client sends a retrieval request which includes a combination of the following parameters: syntax (format), schema (or element set name). The retrieval facility is invoked with parameters in a server/proxy. The retrieval facility matches the parameters a set of "supported" retrieval types. If there is no match, the retrieval signals an error (syntax and / or schema not supported). For a successful match, the backend is invoked with the same or altered retrieval parameters (syntax, schema). If a record is received from the backend, it is converted to the frontend name / syntax. The resulting record is sent back the client and tagged with the frontend syntax / schema. The Retrieval facility is driven by an XML configuration. The configuration is neither Z39.50 ZeeRex or SRU ZeeRex. But it should be easy to generate both of them from the XML configuration. (Unfortunately the two versions of ZeeRex differ substantially in this regard.) Retrieval XML format All elements should be covered by namespace http://indexdata.com/yaz . The root element node must be retrievalinfo. The retrievalinfo must include one or more retrieval elements. Each retrieval defines specific combination of syntax, name and identifier supported by this retrieval service. The retrieval element may include any of the following attributes: syntax (REQUIRED) Defines the record syntax. Possible values is any of the names defined in YAZ' OID database or a raw OID in (n.n ... n). name (OPTIONAL) Defines the name of the retrieval format. This can be any string. For SRU, the value is equivalent to schema (short-hand); for Z39.50 it's equivalent to simple element set name. For YAZ 3.0.24 and later this name may be specified as a glob expression with operators * and ?. identifier (OPTIONAL) Defines the URI schema name of the retrieval format. This can be any string. For SRU, the value is equivalent to URI schema. For Z39.50, there is no equivalent. The retrieval may include one backend element. If a backend element is given, it specifies how the records are retrieved by some backend and how the records are converted from the backend to the "frontend". The attributes, name and syntax may be specified for the backend element. The semantics of these attributes is equivalent to those for the retrieval. However, these values are passed to the "backend". The backend element may include one or more conversion instructions (as children elements). The supported conversions are: marc The marc element specifies a conversion to - and from ISO2709 encoded MARC and &acro.marcxml;/MarcXchange. The following attributes may be specified: inputformat (REQUIRED) Format of input. Supported values are marc (for ISO2709), xml (MARCXML/MarcXchange) and json (MARC-in-JSON). outputformat (REQUIRED) Format of output. Supported values are line (MARC line format); marcxml (for MARCXML), marc (ISO2709), turbomarc, marcxchange (for MarcXchange), or json (MARC-in-JSON ). inputcharset (OPTIONAL) Encoding of input. For XML input formats, this need not be given, but for ISO2709 based input formats, this should be set to the encoding used. For MARC21 records, a common inputcharset value would be marc-8. If inputformat is marc and inputcharset is marc-8, then effective inputcharset is UTF-8 if leader position has value 'a' (MARC21 rule). outputcharset (OPTIONAL) Encoding of output. If outputformat is XML based, it is strongly recommended to use utf-8. leaderspec (OPTIONAL) Specifies a modification to the leader for the resulting output record. The leaderspec is a comma separated list of pos=value pairs, where pos is an integer offset (0 - 23) for leader. Value is either a quoted string or an integer (character value in decimal). For example, to set leader at offset 9 to a, use 9='a'. This has same effect as -l for . select The select selects one or more text nodes and decodes them as XML. The following attributes may be specified: path (REQUIRED) X-Path expression for selecting text nodes. This conversion is available in YAZ 5.8.0 and later. solrmarc The solrmarc decodes solrmarc records. It assumes that the input is pure solrmarc text (no escaping) and will convert all sequences of the form #XX; to a single character of the hexadecimal value as given by XX. The output, presumably, is a valid ISO2709 buffer. This conversion is available in YAZ 5.0.21 and later. xslt The xslt element specifies a conversion via &acro.xslt;. The following attributes may be specified: stylesheet (REQUIRED) Stylesheet file. In addition, the element can be configured as follows: param (OPTIONAL) A param tag configures a parameter to be passed to the &acro.xslt; stylesheet. Multiple param tags may be defined. rdf-lookup The rdf-lookup element looks up BIBFRAME elements in some suitable service, for example http://id.loc.gov/authorities/names and replaces the URIs for specified elements with URIs it finds at that service. Its configuration consists of debug (OPTIONAL) Attribute to the rdf-lookup tag to enable debug output. A value of "1" makes the filter to add a XML comment next to each key it tried to look up, showing the URL, the result, and timing. This is useful for debugging the configuration. The default is not to add any comments. timeout (OPTIONAL) Attribute of the rdf-lookup tag which defines timeout in seconds for the HTTP based rdf-lookup. namespace (OPTIONAL) A namespace tag declares a namespace to be used in the xpath below. The tag requires two attributes: prefix and href. lookup (REQUIRED) A section that defines one tag to be looked up, for example an author.The xpath attribute (REQUIRED) specifies the path to the element(s). key (REQUIRED) A tag withing the lookup tag specifies the value to be used in the lookup, for example a name or an ID. It is a relative Xpath starting from the tag specified in the lookup. server (OPTIONAL) Specifies the URL for server to use for the lookup. A %s is replaced by the key value to be looked up. If not specified, defaults to the same as the previous lookup section, or lacking one, to . The method attribute can be used to specify the HTTP method to be used in this lookup. The default is GET, and the useful alternative is HEAD. See the example below. This conversion is available in YAZ 5.19.0 and later. Retrieval Facility Examples MARC21 backend A typical way to use the retrieval facility is to enable XML for servers that only supports ISO2709 encoded MARC21 records. ]]> This means that our frontend supports: MARC21 F(ull) records. MARC21 B(rief) records. MARCXML records. Dublin core records. MARCXML backend SRW/SRU and Solr backends return records in XML. If they return MARCXML or MarcXchange, the retrieval module can convert those into ISO2709 formats, most commonly USMARC (AKA MARC21). In this example, the backend returns MARCXML for schema="marcxml". ]]> This means that our frontend supports: MARC21 records (any element set name) in MARC-8 encoding. MARCXML records for element-set=marcxml Dublin core records for element-set=dc. RDF-lookup backend This is a minimal example of the backend configuration for the rdf-lookup. It could well be used with some heavy xslt transforms that make BIBFRAME records out of MarxXml. ]]> The debug=1 attribute tells the filter to add XML comments to the key nodes that indicate what lookup it tried to do, how it went, and how long it took. The namespace prefix bf: is defined in the namespace tags. These namespaces are used in the xpath expressions in the lookup sections. The lookup tag specifies one tag to be looked up. The xpath attribute defines which node to modify. It may make use of the namespace definitions above. The server tag gives the URL to be used for the lookup. A %s in the string will get replaced by the key value. If there is no server tag, the one from the preceding lookup section is used, and if there is no previous section, the id.loc.gov address is used as a default. The default is to make a GET request, this example uses HEAD API It should be easy to use the retrieval systems from applications. Refer to the headers yaz/retrieval.h and yaz/record_conv.h. Sorting This chapter describes sorting and how it is supported in YAZ. Sorting applies to a result-set. The Z39.50 sorting facility takes one or more input result-sets and one result-set as output. The most simple case is that the input-set is the same as the output-set. Z39.50 sorting has a separate APDU (service) that is, thus, performed following a search (two phases). In SRU/Solr, however, the model is different. Here, sorting is specified during the search operation. Note, however, that SRU might perform sort as separate search, by referring to an existing result-set in the query (result-set reference). Using the Z39.50 sort service yaz-client and the ZOOM API support the Z39.50 sort facility. In any case the sort sequence or sort criteria is using a string notation. This notation is a one-line notation suitable for being manually entered or generated, and allows for easy logging (one liner). For the ZOOM API, the sort is specified in the call to ZOOM_query_sortby function. For yaz-client the sort is performed and specified using the sort and sort+ commands. For description of the sort criteria notation refer to the sort command in the yaz-client manual. The ZOOM API might choose one of several sort strategies for sorting. Refer to . Type-7 sort Type-7 sort is an extension to the Bib-1 based RPN query where the sort specification is embedded as an Attribute-Plus-Term. The objectives for introducing Type-7 sorting is that it allows a client to perform sorting even if it does not implement/support Z39.50 sort. Virtually all Z39.50 client software supports RPN queries. It also may improve performance because the sort criteria is specified along with the search query. The sort is triggered by the presence of type 7, and the value of type 7 specifies the sortRelation . The value for type 7 is 1 for ascending and 2 for descending. For the sortElement only the generic part is handled. If generic sortKey is of type sortField, then attribute type 1 is present and the value is sortField (InternationalString). If generic sortKey is of type sortAttributes, then the attributes in the list are used. Generic sortKey of type elementSpec is not supported. The term in the sorting Attribute-Plus-Term combo should hold an integer. The value is 0 for primary sorting criteria, 1 for second criteria, etc. Facets YAZ supports facets in the Solr, SRU 2.0 and Z39.50 protocols. Like Type-1/RPN, YAZ supports a string notation for specifying facets. This notataion maps straight to facets.asn. The notation is parsed by function yaz_pqf_parse_facet_list defined in header yaz/pquery.h. For ZOOM C the facets are specified by option "facets". For yaz-client, the 'facets' command is used. The grammar of this specification is as follows: facet-spec ::= facet-list facet-list ::= facet-list ',' attr-spec | attr-spec attr-spec ::= attr-spec '@attr' string | '@attr' string The notation is inspired by PQF. The string following '@attr' must not include blanks and is of the form type=value, where type is an integer and value is a string or an integer. There is no formal facets attribute set (it is not given in the protocol by the facets, although it could). The following types apply: Facet attributes Type Description 1 Field-name. This is often a string, e.g. "Author", "Year", etc. 2 Sort order. Value should be an integer. Value 0: count descending (frequency). Value 1: alpha ascending. 3 Number of terms requested. 4 Start offset (starting from 1)
The ODR Module Introduction &odr; is the BER-encoding/decoding subsystem of &yaz;. Care has been taken to isolate &odr; from the rest of the package - specifically from the transport interface. &odr; may be used in any context where basic ASN.1/BER representations are used. If you are only interested in writing a Z39.50 implementation based on the PDUs that are already provided with &yaz;, you only need to concern yourself with the section on managing ODR streams (). Only if you need to implement ASN.1 beyond that which has been provided, should you worry about the second half of the documentation (). If you use one of the higher-level interfaces, you can skip this section entirely. This is important, so we'll repeat it for emphasis: You do not need to read to implement Z39.50 with &yaz;. If you need a part of the protocol that isn't already in &yaz;, you should contact the authors before going to work on it yourself: We might already be working on it. Conversely, if you implement a useful part of the protocol before us, we'd be happy to include it in a future release. Using ODR ODR Streams Conceptually, the ODR stream is the source of encoded data in the decoding mode; when encoding, it is the receptacle for the encoded data. Before you can use an ODR stream it must be allocated. This is done with the function ODR odr_createmem(int direction); The odr_createmem() function takes as argument one of three manifest constants: ODR_ENCODE, ODR_DECODE, or ODR_PRINT. An &odr; stream can be in only one mode - it is not possible to change its mode once it's selected. Typically, your program will allocate at least two ODR streams - one for decoding, and one for encoding. When you're done with the stream, you can use void odr_destroy(ODR o); to release the resources allocated for the stream. Memory Management Two forms of memory management take place in the &odr; system. The first one, which has to do with allocating little bits of memory (sometimes quite large bits of memory, actually) when a protocol package is decoded, and turned into a complex of interlinked structures. This section deals with this system, and how you can use it for your own purposes. The next section deals with the memory management which is required when encoding data - to make sure that a large enough buffer is available to hold the fully encoded PDU. The &odr; module has its own memory management system, which is used whenever memory is required. Specifically, it is used to allocate space for data when decoding incoming PDUs. You can use the memory system for your own purposes, by using the function void *odr_malloc(ODR o, size_t size); You can't use the normal free(2) routine to free memory allocated by this function, and &odr; doesn't provide a parallel function. Instead, you can call void odr_reset(ODR o); when you are done with the memory: Everything allocated since the last call to odr_reset() is released. The odr_reset() call is also required to clear up an error condition on a stream. The function size_t odr_total(ODR o); returns the number of bytes allocated on the stream since the last call to odr_reset(). The memory subsystem of &odr; is fairly efficient at allocating and releasing little bits of memory. Rather than managing the individual, small bits of space, the system maintains a free-list of larger chunks of memory, which are handed out in small bits. This scheme is generally known as a nibble-memory system. It is very useful for maintaining short-lived constructions such as protocol PDUs. If you want to retain a bit of memory beyond the next call to odr_reset(), you can use the function ODR_MEM odr_extract_mem(ODR o); This function will give you control of the memory recently allocated on the ODR stream. The memory will live (past calls to odr_reset()), until you call the function void odr_release_mem(ODR_MEM p); The opaque ODR_MEM handle has no other purpose than referencing the memory block for you until you want to release it. You can use odr_extract_mem() repeatedly between allocating data, to retain individual control of separate chunks of data. Encoding and Decoding Data When encoding data, the ODR stream will write the encoded octet string in an internal buffer. To retrieve the data, use the function char *odr_getbuf(ODR o, int *len, int *size); The integer pointed to by len is set to the length of the encoded data, and a pointer to that data is returned. *size is set to the size of the buffer (unless size is null, signaling that you are not interested in the size). The next call to a primitive function using the same &odr; stream will overwrite the data, unless a different buffer has been supplied using the call void odr_setbuf(ODR o, char *buf, int len, int can_grow); which sets the encoding (or decoding) buffer used by o to buf, using the length len. Before a call to an encoding function, you can use odr_setbuf() to provide the stream with an encoding buffer of sufficient size (length). The can_grow parameter tells the encoding &odr; stream whether it is allowed to use realloc(2) to increase the size of the buffer when necessary. The default condition of a new encoding stream is equivalent to the results of calling odr_setbuf(stream, 0, 0, 1); In this case, the stream will allocate and reallocate memory as necessary. The stream reallocates memory by repeatedly doubling the size of the buffer - the result is that the buffer will typically reach its maximum, working size with only a small number of reallocation operations. The memory is freed by the stream when the latter is destroyed, unless it was assigned by the user with the can_grow parameter set to zero (in this case, you are expected to retain control of the memory yourself). To assume full control of an encoded buffer, you must first call odr_getbuf() to fetch the buffer and its length. Next, you should call odr_setbuf() to provide a different buffer (or a null pointer) to the stream. In the simplest case, you will reuse the same buffer over and over again, and you will just need to call odr_getbuf() after each encoding operation to get the length and address of the buffer. Note that the stream may reallocate the buffer during an encoding operation, so it is necessary to retrieve the correct address after each encoding operation. It is important to realize that the ODR stream will not release this memory when you call odr_reset(): It will merely update its internal pointers to prepare for the encoding of a new data value. When the stream is released by the odr_destroy() function, the memory given to it by odr_setbuf will be released only if the can_grow parameter to odr_setbuf() was nonzero. The can_grow parameter, in other words, is a way of signaling who is to own the buffer, you or the ODR stream. If you never call odr_setbuf() on your encoding stream, which is typically the case, the buffer allocated by the stream will belong to the stream by default. When you wish to decode data, you should first call odr_setbuf(), to tell the decoding stream where to find the encoded data, and how long the buffer is (the can_grow parameter is ignored by a decoding stream). After this, you can call the function corresponding to the data you wish to decode (e.g. odr_integer() odr z_APDU()). Encoding and decoding functions int odr_integer(ODR o, Odr_int **p, int optional, const char *name); int z_APDU(ODR o, Z_APDU **p, int optional, const char *name); If the data is absent (or doesn't match the tag corresponding to the type), the return value will be either 0 or 1 depending on the optional flag. If optional is 0 and the data is absent, an error flag will be raised in the stream, and you'll need to call odr_reset() before you can use the stream again. If optional is nonzero, the pointer pointed to/ by p will be set to the null value, and the function will return 1. The name argument is used to pretty-print the tag in question. It may be set to NULL if pretty-printing is not desired. If the data value is found where it's expected, the pointer pointed to by the p argument will be set to point to the decoded type. The space for the type will be allocated and owned by the &odr; stream, and it will live until you call odr_reset() on the stream. You cannot use free(2) to release the memory. You can decode several data elements (by repeated calls to odr_setbuf() and your decoding function), and new memory will be allocated each time. When you do call odr_reset(), everything decoded since the last call to odr_reset() will be released. Encoding and decoding of an integer The use of the double indirection can be a little confusing at first (its purpose will become clear later on, hopefully), so an example is in order. We'll encode an integer value, and immediately decode it again using a different stream. A useless, but informative operation. This looks like a lot of work, offhand. In practice, the &odr; streams will typically be allocated once, in the beginning of your program (or at the beginning of a new network session), and the encoding and decoding will only take place in a few, isolated places in your program, so the overhead is quite manageable. Printing When an ODR stream is created of type ODR_PRINT the ODR module will print the contents of a PDU in a readable format. By default output is written to the stderr stream. This behavior can be changed, however, by calling the function odr_setprint(ODR o, FILE *file); before encoders or decoders are being invoked. It is also possible to direct the output to a buffer (or indeed another file), by using the more generic mechanism: void odr_set_stream(ODR o, void *handle, void (*stream_write)(ODR o, void *handle, int type, const char *buf, int len), void (*stream_close)(void *handle)); Here the user provides an opaque handle and two handlers, stream_write for writing, and stream_close which is supposed to close/free resources associated with handle. The stream_close handler is optional and if NULL for the function is provided, it will not be invoked. The stream_write takes the ODR handle as parameter, the user-defined handle, a type ODR_OCTETSTRING, ODR_VISIBLESTRING which indicates the type of contents being written. Another utility useful for diagnostics (error handling) or as part of the printing facilities is: const char **odr_get_element_path(ODR o); which returns a list of current elements that ODR deals with at the moment. For the returned array, say ar, then ar[0] is the top level element, ar[n] is the last. The last element has the property that ar[n+1] == NULL. Element Path for record For a database record part of a PresentResponse the array returned by odr_get_element is presentResponse, databaseOrSurDiagnostics, ?, record, ?, databaseRecord . The question mark appears due to unnamed constructions. Diagnostics The encoding/decoding functions all return 0 when an error occurs. Until you call odr_reset(), you cannot use the stream again, and any function called will immediately return 0. To provide information to the programmer or administrator, the function void odr_perror(ODR o, char *message); is provided, which prints the message argument to stderr along with an error message from the stream. You can also use the function int odr_geterror(ODR o); to get the current error number from the screen. The number will be one of these constants: ODR Error codes code Description OMEMORYMemory allocation failed. OSYSERRA system- or library call has failed. The standard diagnostic variable errno should be examined to determine the actual error. OSPACENo more space for encoding. This will only occur when the user has explicitly provided a buffer for an encoding stream without allowing the system to allocate more space. OREQUIREDThis is a common protocol error; A required data element was missing during encoding or decoding. OUNEXPECTEDAn unexpected data element was found during decoding. OOTHEROther error. This is typically an indication of misuse of the &odr; system by the programmer, and also that the diagnostic system isn't as good as it should be, yet.
The character string array char *odr_errlist[] can be indexed by the error code to obtain a human-readable representation of the problem. Summary and Synopsis #include <yaz/odr.h> ODR odr_createmem(int direction); void odr_destroy(ODR o); void odr_reset(ODR o); char *odr_getbuf(ODR o, int *len, int *size); void odr_setbuf(ODR o, char *buf, int len, int can_grow); void *odr_malloc(ODR o, int size); NMEM odr_extract_mem(ODR o); int odr_geterror(ODR o); void odr_perror(ODR o, const char *message); extern char *odr_errlist[]; Programming with ODR The API of &odr; is designed to reflect the structure of ASN.1, rather than BER itself. Future releases may be able to represent data in other external forms. There is an ASN.1 tutorial available at this site. This site also has standards for ASN.1 (X.680) and BER (X.690) online. The ODR interface is based loosely on that of the Sun Microsystems XDR routines. Specifically, each function which corresponds to an ASN.1 primitive type has a dual function. Depending on the settings of the ODR stream which is supplied as a parameter, the function may be used either to encode or decode data. The functions that can be built using these primitive functions, to represent more complex data types, share this quality. The result is that you only have to enter the definition for a type once - and you have the functionality of encoding, decoding (and pretty-printing) all in one unit. The resulting C source code is quite compact, and is a pretty straightforward representation of the source ASN.1 specification. In many cases, the model of the XDR functions works quite well in this role. In others, it is less elegant. Most of the hassle comes from the optional SEQUENCE members which don't exist in XDR. The Primitive ASN.1 Types ASN.1 defines a number of primitive types (many of which correspond roughly to primitive types in structured programming languages, such as C). INTEGER The &odr; function for encoding or decoding (or printing) the ASN.1 INTEGER type looks like this: int odr_integer(ODR o, Odr_int **p, int optional, const char *name); The Odr_int is just a simple integer. This form is typical of the primitive &odr; functions. They are named after the type of data that they encode or decode. They take an &odr; stream, an indirect reference to the type in question, and an optional flag (corresponding to the OPTIONAL keyword of ASN.1) as parameters. They all return an integer value of either one or zero. When you use the primitive functions to construct encoders for complex types of your own, you should follow this model as well. This ensures that your new types can be reused as elements in yet more complex types. The o parameter should obviously refer to a properly initialized &odr; stream of the right type (encoding/decoding/printing) for the operation that you wish to perform. When encoding or printing, the function first looks at * p. If * p (the pointer pointed to by p) is a null pointer, this is taken to mean that the data element is absent. If the optional parameter is nonzero, the function will return one (signifying success) without any further processing. If the optional is zero, an internal error flag is set in the &odr; stream, and the function will return 0. No further operations can be carried out on the stream without a call to the function odr_reset(). If *p is not a null pointer, it is expected to point to an instance of the data type. The data will be subjected to the encoding rules, and the result will be placed in the buffer held by the &odr; stream. The other ASN.1 primitives have similar functions that operate in similar manners: BOOLEAN int odr_bool(ODR o, Odr_bool **p, int optional, const char *name); REAL Not defined. NULL int odr_null(ODR o, Odr_null **p, int optional, const char *name); In this case, the value of **p is not important. If *p is different from the null pointer, the null value is present, otherwise it's absent. OCTET STRING typedef struct odr_oct { unsigned char *buf; int len; } Odr_oct; int odr_octetstring(ODR o, Odr_oct **p, int optional, const char *name); The buf field should point to the character array that holds the octetstring. The len field holds the actual length. The character array need not be null-terminated. To make things a little easier, an alternative is given for string types that are not expected to contain embedded NULL characters (e.g. VisibleString): int odr_cstring(ODR o, char **p, int optional, const char *name); which encodes or decodes between OCTETSTRING representations and null-terminated C strings. Functions are provided for the derived string types, e.g.: int odr_visiblestring(ODR o, char **p, int optional, const char *name); BIT STRING int odr_bitstring(ODR o, Odr_bitmask **p, int optional, const char *name); The opaque type Odr_bitmask is only suitable for holding relatively brief bit strings, e.g. for options fields, etc. The constant ODR_BITMASK_SIZE multiplied by 8 gives the maximum possible number of bits. A set of macros are provided for manipulating the Odr_bitmask type: void ODR_MASK_ZERO(Odr_bitmask *b); void ODR_MASK_SET(Odr_bitmask *b, int bitno); void ODR_MASK_CLEAR(Odr_bitmask *b, int bitno); int ODR_MASK_GET(Odr_bitmask *b, int bitno); The functions are modeled after the manipulation functions that accompany the fd_set type used by the select(2) call. ODR_MASK_ZERO should always be called first on a new bitmask, to initialize the bits to zero. OBJECT IDENTIFIER int odr_oid(ODR o, Odr_oid **p, int optional, const char *name); The C OID representation is simply an array of integers, terminated by the value -1 (the Odr_oid type is synonymous with the short type). We suggest that you use the OID database module (see ) to handle object identifiers in your application. Tagging Primitive Types The simplest way of tagging a type is to use the odr_implicit_tag() or odr_explicit_tag() macros: int odr_implicit_tag(ODR o, Odr_fun fun, int class, int tag, int optional, const char *name); int odr_explicit_tag(ODR o, Odr_fun fun, int class, int tag, int optional, const char *name); To create a type derived from the integer type by implicit tagging, you might write: MyInt ::= [210] IMPLICIT INTEGER In the &odr; system, this would be written like: int myInt(ODR o, Odr_int **p, int optional, const char *name) { return odr_implicit_tag(o, odr_integer, p, ODR_CONTEXT, 210, optional, name); } The function myInt() can then be used like any of the primitive functions provided by &odr;. Note that the behavior of odr_explicit_tag() and odr_implicit_tag() macros act exactly the same as the functions they are applied to - they respond to error conditions, etc, in the same manner - they simply have three extra parameters. The class parameter may take one of the values: ODR_CONTEXT, ODR_PRIVATE, ODR_UNIVERSAL, or /ODR_APPLICATION. Constructed Types Constructed types are created by combining primitive types. The &odr; system only implements the SEQUENCE and SEQUENCE OF constructions (although adding the rest of the container types should be simple enough, if the need arises). For implementing SEQUENCEs, the functions int odr_sequence_begin(ODR o, void *p, int size, const char *name); int odr_sequence_end(ODR o); are provided. The odr_sequence_begin() function should be called in the beginning of a function that implements a SEQUENCE type. Its parameters are the &odr; stream, a pointer (to a pointer to the type you're implementing), and the size of the type (typically a C structure). On encoding, it returns 1 if * p is a null pointer. The size parameter is ignored. On decoding, it returns 1 if the type is found in the data stream. size bytes of memory are allocated, and *p is set to point to this space. The odr_sequence_end() is called at the end of the complex function. Assume that a type is defined like this: MySequence ::= SEQUENCE { intval INTEGER, boolval BOOLEAN OPTIONAL } The corresponding &odr; encoder/decoder function and the associated data structures could be written like this: typedef struct MySequence { Odr_int *intval; Odr_bool *boolval; } MySequence; int mySequence(ODR o, MySequence **p, int optional, const char *name) { if (odr_sequence_begin(o, p, sizeof(**p), name) == 0) return optional && odr_ok(o); return odr_integer(o, &(*p)->intval, 0, "intval") && odr_bool(o, &(*p)->boolval, 1, "boolval") && odr_sequence_end(o); } Note the 1 in the call to odr_bool(), to mark that the sequence member is optional. If either of the member types had been tagged, the macros odr_implicit_tag() or odr_explicit_tag() could have been used. The new function can be used exactly like the standard functions provided with &odr;. It will encode, decode or pretty-print a data value of the MySequence type. We like to name types with an initial capital, as done in ASN.1 definitions, and to name the corresponding function with the first character of the name in lower case. You could, of course, name your structures, types, and functions any way you please - as long as you're consistent, and your code is easily readable. odr_ok is just that - a predicate that returns the state of the stream. It is used to ensure that the behavior of the new type is compatible with the interface of the primitive types. Tagging Constructed Types See for information on how to tag the primitive types, as well as types that are already defined. Implicit Tagging Assume the type above had been defined as MySequence ::= [10] IMPLICIT SEQUENCE { intval INTEGER, boolval BOOLEAN OPTIONAL } You would implement this in &odr; by calling the function int odr_implicit_settag(ODR o, int class, int tag); which overrides the tag of the type immediately following it. The macro odr_implicit_tag() works by calling odr_implicit_settag() immediately before calling the function pointer argument. Your type function could look like this: int mySequence(ODR o, MySequence **p, int optional, const char *name) { if (odr_implicit_settag(o, ODR_CONTEXT, 10) == 0 || odr_sequence_begin(o, p, sizeof(**p), name) == 0) return optional && odr_ok(o); return odr_integer(o, &(*p)->intval, 0, "intval") && odr_bool(o, &(*p)->boolval, 1, "boolval") && odr_sequence_end(o); } The definition of the structure MySequence would be the same. Explicit Tagging Explicit tagging of constructed types is a little more complicated, since you are in effect adding a level of construction to the data. Assume the definition: MySequence ::= [10] IMPLICIT SEQUENCE { intval INTEGER, boolval BOOLEAN OPTIONAL } Since the new type has an extra level of construction, two new functions are needed to encapsulate the base type: int odr_constructed_begin(ODR o, void *p, int class, int tag, const char *name); int odr_constructed_end(ODR o); Assume that the IMPLICIT in the type definition above were replaced with EXPLICIT (or that the IMPLICIT keyword was simply deleted, which would be equivalent). The structure definition would look the same, but the function would look like this: int mySequence(ODR o, MySequence **p, int optional, const char *name) { if (odr_constructed_begin(o, p, ODR_CONTEXT, 10, name) == 0) return optional && odr_ok(o); if (o->direction == ODR_DECODE) *p = odr_malloc(o, sizeof(**p)); if (odr_sequence_begin(o, p, sizeof(**p), 0) == 0) { *p = 0; /* this is almost certainly a protocol error */ return 0; } return odr_integer(o, &(*p)->intval, 0, "intval") && odr_bool(o, &(*p)->boolval, 1, "boolval") && odr_sequence_end(o) && odr_constructed_end(o); } Notice that the interface here gets kind of nasty. The reason is simple: Explicitly tagged, constructed types are fairly rare in the protocols that we care about, so the aesthetic annoyance (not to mention the dangers of a cluttered interface) is less than the time that would be required to develop a better interface. Nevertheless, it is far from satisfying, and it's a point that will be worked on in the future. One option for you would be to simply apply the odr_explicit_tag() macro to the first function, and not have to worry about odr_constructed_* yourself. Incidentally, as you might have guessed, the odr_sequence_ functions are themselves implemented using the /odr_constructed_ functions. SEQUENCE OF To handle sequences (arrays) of a specific type, the function int odr_sequence_of(ODR o, int (*fun)(ODR o, void *p, int optional), void *p, int *num, const char *name); The fun parameter is a pointer to the decoder/encoder function of the type. p is a pointer to an array of pointers to your type. num is the number of elements in the array. Assume a type MyArray ::= SEQUENCE OF INTEGER The C representation might be typedef struct MyArray { int num_elements; Odr_int **elements; } MyArray; And the function might look like int myArray(ODR o, MyArray **p, int optional, const char *name) { if (o->direction == ODR_DECODE) *p = odr_malloc(o, sizeof(**p)); if (odr_sequence_of(o, odr_integer, &(*p)->elements, &(*p)->num_elements, name)) return 1; *p = 0; return optional && odr_ok(o); } CHOICE Types The choice type is used fairly often in some ASN.1 definitions, so some work has gone into streamlining its interface. CHOICE types are handled by the function: int odr_choice(ODR o, Odr_arm arm[], void *p, void *whichp, const char *name); The arm array is used to describe each of the possible types that the CHOICE type may assume. Internally in your application, the CHOICE type is represented as a discriminated union. That is, a C union accompanied by an integer (or enum) identifying the active 'arm' of the union. whichp is a pointer to the union discriminator. When encoding, it is examined to determine the current type. When decoding, it is set to reference the type that was found in the input stream. The Odr_arm type is defined thus: typedef struct odr_arm { int tagmode; int class; int tag; int which; Odr_fun fun; char *name; } Odr_arm; The interpretation of the fields are: tagmode Either ODR_IMPLICIT, ODR_EXPLICIT, or ODR_NONE (-1) to mark no tagging. which The value of the discriminator that corresponds to this CHOICE element. Typically, it will be a #defined constant, or an enum member. fun A pointer to a function that implements the type of the CHOICE member. It may be either a standard &odr; type or a type defined by yourself. name Name of tag. A handy way to prepare the array for use by the odr_choice() function is to define it as a static, initialized array in the beginning of your decoding/encoding function. Assume the type definition: MyChoice ::= CHOICE { untagged INTEGER, tagged [99] IMPLICIT INTEGER, other BOOLEAN } Your C type might look like typedef struct MyChoice { enum { MyChoice_untagged, MyChoice_tagged, MyChoice_other } which; union { Odr_int *untagged; Odr_int *tagged; Odr_bool *other; } u; }; And your function could look like this: int myChoice(ODR o, MyChoice **p, int optional, const char *name) { static Odr_arm arm[] = { {-1, -1, -1, MyChoice_untagged, odr_integer, "untagged"}, {ODR_IMPLICIT, ODR_CONTEXT, 99, MyChoice_tagged, odr_integer, "tagged"}, {-1, -1, -1, MyChoice_other, odr_boolean, "other"}, {-1, -1, -1, -1, 0} }; if (o->direction == ODR_DECODE) *p = odr_malloc(o, sizeof(**p); else if (!*p) return optional && odr_ok(o); if (odr_choice(o, arm, &(*p)->u, &(*p)->which), name) return 1; *p = 0; return optional && odr_ok(o); } In some cases (say, a non-optional choice which is a member of a sequence), you can "embed" the union and its discriminator in the structure belonging to the enclosing type, and you won't need to fiddle with memory allocation to create a separate structure to wrap the discriminator and union. The corresponding function is somewhat nicer in the Sun XDR interface. Most of the complexity of this interface comes from the possibility of declaring sequence elements (including CHOICEs) optional. The ASN.1 specifications naturally require that each member of a CHOICE have a distinct tag, so they can be told apart on decoding. Sometimes it can be useful to define a CHOICE that has multiple types that share the same tag. You'll need some other mechanism, perhaps keyed to the context of the CHOICE type. In effect, we would like to introduce a level of context-sensitiveness to our ASN.1 specification. When encoding an internal representation, we have no problem, as long as each CHOICE member has a distinct discriminator value. For decoding, we need a way to tell the choice function to look for a specific arm of the table. The function void odr_choice_bias(ODR o, int what); provides this functionality. When called, it leaves a notice for the next call to odr_choice() to be called on the decoding stream o, that only the arm entry with a which field equal to what should be tried. The most important application (perhaps the only one, really) is in the definition of application-specific EXTERNAL encoders/decoders which will automatically decode an ANY member given the direct or indirect reference. Debugging The protocol modules are suffering somewhat from a lack of diagnostic tools at the moment. Specifically ways to pretty-print PDUs that aren't recognized by the system. We'll include something to this end in a not-too-distant release. In the meantime, what we do when we get packages we don't understand is to compile the ODR module with ODR_DEBUG defined. This causes the module to dump tracing information as it processes data units. With this output and the protocol specification (Z39.50), it is generally fairly easy to see what goes wrong. The COMSTACK Module Synopsis (blocking mode) Introduction The &comstack; subsystem provides a transparent interface to different types of transport stacks for the exchange of BER-encoded data and HTTP packets. At present, the RFC1729 method (BER over TCP/IP), local UNIX socket and an experimental SSL stack are supported, but others may be added in time. The philosophy of the module is to provide a simple interface by hiding unused options and facilities of the underlying libraries. This is always done at the risk of losing generality, and it may prove that the interface will need extension later on. There hasn't been interest in the XTImOSI stack for some years. Therefore, it is no longer supported. The interface is implemented in such a fashion that only the sub-layers constructed to the transport methods that you wish to use in your application are linked in. You will note that even though simplicity was a goal in the design, the interface is still orders of magnitudes more complex than the transport systems found in many other packages. One reason is that the interface needs to support the somewhat different requirements of the different lower-layer communications stacks; another important reason is that the interface seeks to provide a more or less industrial-strength approach to asynchronous event-handling. When no function is allowed to block, things get more complex - particularly on the server side. We urge you to have a look at the demonstration client and server provided with the package. They are meant to be easily readable and instructive, while still being at least moderately useful. Common Functions Managing Endpoints COMSTACK cs_create(CS_TYPE type, int blocking, int protocol); Creates an instance of the protocol stack - a communications endpoint. The type parameter determines the mode of communication. At present the following values are supported: tcpip_type TCP/IP (BER over TCP/IP or HTTP over TCP/IP) ssl_type Secure Socket Layer (SSL). This COMSTACK is experimental and is not fully implemented. If HTTP is used, this effectively is HTTPS. unix_type Unix socket (unix only). Local Transfer via file socket. See unix 7. The cs_create function returns a null-pointer if a system error occurs. The blocking parameter should be '1' if you wish the association to operate in blocking mode, and '0' otherwise. The protocol field should be PROTO_Z3950 or PROTO_HTTP. Protocol PROTO_SR is no longer supported. void cs_close(COMSTACK handle); Closes the connection (as elegantly as the lower layers will permit), and releases the resources pointed to by the handle parameter. The handle should not be referenced again after this call. We really need a soft disconnect, don't we? Data Exchange int cs_put(COMSTACK handle, char *buf, int len); Sends buf down the wire. In blocking mode, this function will return only when a full buffer has been written, or an error has occurred. In nonblocking mode, it's possible that the function will be unable to send the full buffer at once, which will be indicated by a return value of 1. The function will keep track of the number of octets already written; you should call it repeatedly with the same values of buf and len, until the buffer has been transmitted. When a full buffer has been sent, the function will return 0 for success. The return value -1 indicates an error condition (see below). int cs_get(COMSTACK handle, char **buf, int *size); Receives a PDU or HTTP Response from the peer. Returns the number of bytes read. In nonblocking mode, it is possible that not all of the packet can be read at once. In this case, the function returns 1. To simplify the interface, the function is responsible for managing the size of the buffer. It will be reallocated if necessary to contain large packages, and will sometimes be moved around internally by the subsystem when partial packages are read. Before calling cs_get for the first time, the buffer can be initialized to the null pointer, and the length should also be set to 0 (cs_get will perform a malloc(2) on the buffer for you). When a full buffer has been read, the size of the package is returned (which will always be greater than 1). The return value -1 indicates an error condition. See also the cs_more() function below. int cs_more(COMSTACK handle); The cs_more() function should be used in conjunction with cs_get and select(2). The cs_get() function will sometimes (notably in the TCP/IP mode) read more than a single protocol package off the network. When this happens, the extra package is stored by the subsystem. After calling cs_get(), and before waiting for more input, You should always call cs_more() to check if there's a full protocol package already read. If cs_more() returns 1, cs_get() can be used to immediately fetch the new package. For the mOSI subsystem, the function should always return 0, but if you want your stuff to be protocol independent, you should use it. The cs_more() function is required because the RFC1729-method does not provide a way of separating individual PDUs, short of partially decoding the BER. Some other implementations will carefully nibble at the packet by calling read(2) several times. This was felt to be too inefficient (or at least clumsy) - hence the call for this extra function. int cs_look(COMSTACK handle); This function is useful when you're operating in nonblocking mode. Call it when select(2) tells you there's something happening on the line. It returns one of the following values: CS_NONE No event is pending. The data found on the line was not a complete package. CS_CONNECT A response to your connect request has been received. Call cs_rcvconnect to process the event and to finalize the connection establishment. CS_DISCON The other side has closed the connection (or maybe sent a disconnect request - but do we care? Maybe later). Call cs_close to close your end of the association as well. CS_LISTEN A connect request has been received. Call cs_listen to process the event. CS_DATA There's data to be found on the line. Call cs_get to get it. You should be aware that even if cs_look() tells you that there's an event event pending, the corresponding function may still return and tell you there was nothing to be found. This means that only part of a package was available for reading. The same event will show up again, when more data has arrived. int cs_fileno(COMSTACK h); returns the file descriptor of the association. Use this when file-level operations on the endpoint are required (select(2) operations, specifically). Client Side int cs_connect(COMSTACK handle, void *address); Initiate a connection with the target at address (more on addresses below). The function will return 0 on success, and 1 if the operation does not complete immediately (this will only happen on a nonblocking endpoint). In this case, use cs_rcvconnect to complete the operation, when select(2) or poll(2) reports input pending on the association. int cs_rcvconnect(COMSTACK handle); Complete a connect operation initiated by cs_connect(). It will return 0 on success; 1 if the operation has not yet completed (in this case, call the function again later); -1 if an error has occurred. Server Side To establish a server under the inetd server, you can use COMSTACK cs_createbysocket(int socket, CS_TYPE type, int blocking, int protocol); The socket parameter is an established socket (when your application is invoked from inetd, the socket will typically be 0. The following parameters are identical to the ones for cs_create. int cs_bind(COMSTACK handle, void *address, int mode) Binds a local address to the endpoint. Read about addresses below. The mode parameter should be either CS_CLIENT or CS_SERVER. int cs_listen(COMSTACK handle, char *addr, int *addrlen); Call this to process incoming events on an endpoint that has been bound in listening mode. It will return 0 to indicate that the connect request has been received, 1 to signal a partial reception, and -1 to indicate an error condition. COMSTACK cs_accept(COMSTACK handle); This finalizes the server-side association establishment, after cs_listen has completed successfully. It returns a new connection endpoint, which represents the new association. The application will typically wish to fork off a process to handle the association at this point, and continue listen for new connections on the old handle. You can use the call const char *cs_addrstr(COMSTACK); on an established connection to retrieve the host-name of the remote host. You may need to use this function with some care if your name server service is slow or unreliable. Addresses The low-level format of the addresses are different depending on the mode of communication you have chosen. A function is provided by each of the lower layers to map a user-friendly string-form address to the binary form required by the lower layers. void *cs_straddr(COMSTACK handle, const char *str); The format for TCP/IP and SSL addresses is: <host> [ ':' <portnum> ] The hostname can be either a domain name or an IP address. The port number, if omitted, defaults to 210. For TCP/IP and SSL, the special hostnames @, maps to IN6ADDR_ANY_INIT with IPV4 binding as well (bindv6only=0), The special hostname @4 binds to INADDR_ANY (IPV4 only listener). The special hostname @6 binds to IN6ADDR_ANY_INIT with bindv6only=1 (IPV6 only listener). For UNIX sockets, the format of an address is the socket filename. When a connection has been established, you can use const char *cs_addrstr(COMSTACK h); to retrieve the host name of the peer system. The function returns a pointer to a static area, which is overwritten on the next call to the function. A fairly recent addition to the &comstack; module is the utility function COMSTACK cs_create_host (const char *str, int blocking, void **vp); which is just a wrapper for cs_create and cs_straddr. The str is similar to that described for cs_straddr but with a prefix denoting the &comstack; type. Prefixes supported are tcp: and unix: and ssl: for TCP/IP and UNIX and SSL respectively. If no prefix is given, then TCP/IP is used. The blocking is passed to function cs_create. The third parameter vp is a pointer to &comstack; stack type specific values. Parameter vp is reserved for future use. Set it to NULL. SSL void *cs_get_ssl(COMSTACK cs); Returns the SSL handle, SSL * for comstack. If comstack is not of type SSL, then NULL is returned. int cs_set_ssl_ctx(COMSTACK cs, void *ctx); Sets SSL context for comstack. The parameter is expected to be of type SSL_CTX *. This function should be called just after comstack has been created (before connect, bind, etc). This function returns 1 for success; 0 for failure. int cs_set_ssl_certificate_file(COMSTACK cs, const char *fname); Sets SSL certificate for comstack as a PEM file. This function returns 1 for success; 0 for failure. int cs_get_ssl_peer_certificate_x509(COMSTACK cs, char **buf, int *len); This function returns the peer certificate. If successful, *buf and *len holds X509 buffer and length respectively. Buffer should be freed with xfree. This function returns 1 for success; 0 for failure. Diagnostics All functions return -1 if an error occurs. Typically, the functions will return 0 on success, but the data exchange functions (cs_get, cs_put, cs_more) follow special rules. Consult their descriptions. The error code for the COMSTACK can be retrieved using C macro cs_errno which will return one of the error codes CSYSERR, CSOUTSTATE, CSNODATA, ... int cs_errno(COMSTACK handle); You can the textual representation of the error code by using cs_errmsg, which works like strerror(3). const char *cs_errmsg(int n); It is also possible to get straight to the textual representation without the error code, by using cs_strerror. const char *cs_strerror(COMSTACK h); Summary and Synopsis #include /* this is for TCP/IP and SSL support */ #include /* this is for UNIX socket support */ COMSTACK cs_create(CS_TYPE type, int blocking, int protocol); COMSTACK cs_createbysocket(int s, CS_TYPE type, int blocking, int protocol); COMSTACK cs_create_host(const char *str, int blocking, void **vp); int cs_bind(COMSTACK handle, int mode); int cs_connect(COMSTACK handle, void *address); int cs_rcvconnect(COMSTACK handle); int cs_listen(COMSTACK handle); COMSTACK cs_accept(COMSTACK handle); int cs_put(COMSTACK handle, char *buf, int len); int cs_get(COMSTACK handle, char **buf, int *size); int cs_more(COMSTACK handle); void cs_close(COMSTACK handle); int cs_look(COMSTACK handle); void *cs_straddr(COMSTACK handle, const char *str); const char *cs_addrstr(COMSTACK h); ]]> Future Directions We have a new and better version of the front-end server on the drawing board. Resources and external commitments will govern when we'll be able to do something real with it. Features should include greater flexibility, greater support for access/resource control, and easy support for Explain (possibly with Zebra as an extra database engine). &yaz; is a BER toolkit and as such should support all protocols out there based on that. We'd like to see running ILL applications. It shouldn't be that hard. Another thing that would be interesting is LDAP. Maybe a generic framework for doing IR using both LDAP and Z39.50 transparently. The SOAP implementation is incomplete. In the future we hope to add more features to it. Perhaps make a WSDL/XML Schema compiler. The authors of libxml2 are already working on XML Schema and RELAX NG compilers so this may not be too hard. It would be neat to have a proper module mechanism for the Generic Frontend Server so that backend would be dynamically loaded (as shared objects / DLLs). Other than that, &yaz; generally moves in the directions which appear to make the most people happy (including ourselves, as prime users of the software). If there's something you'd like to see in here, then drop us a note and let's see what we can come up with. Reference The material in this chapter is drawn directly from the individual manual entries. &manref; List of Object Identifiers These is a list of object identifiers that are built into YAZ. &std-oid-table; Bib-1 diagnostics List of Bib-1 diagnostics that are known to YAZ. &bib1-diag-table; SRU diagnostics List of SRU diagnostics that are known to YAZ. &srw-diag-table; License Index Data Copyright Copyright © ©right-year; Index Data. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Index Data nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY INDEX DATA ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL INDEX DATA BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. About Index Data Index Data is a consulting and software-development enterprise that specializes in library and information management systems. Our interests and expertise span a broad range of related fields, and one of our primary, long-term objectives is the development of a powerful information management system with open network interfaces and hyper-media capabilities. We make this software available free of charge, on a fairly unrestrictive license; as a service to the networking community, and to further the development of quality software for open network communication. We'll be happy to answer questions about the software, and about ourselves in general. The Hacker's Jargon File has the following to say about the use of the prefix "YA" in the name of a software product. Yet Another. adj. 1. Of your own work: A humorous allusion often used in titles to acknowledge that the topic is not original, though the content is. As in "Yet Another AI Group" or "Yet Another Simulated Annealing Algorithm". 2. Of others' work: Describes something of which there are already far too many. Credits This appendix lists individuals that have contributed in the development of &yaz;. Some have contributed with code, while others have provided bug fixes or suggestions. If we're missing somebody, of if you, for whatever reason, don't like to be listed here, let us know. Gary Anderson Dimitrios Andreadis Morten Bøgeskov Rocco Carbone Matthew Carey Hans van Dalen Irina Dijour Larry E. Dixson Hans van den Dool Mads Bondo Dydensborg Franck Falcoz Kevin Gamiel Morten Garkier Hendriksen Morten Holmqvist Ian Ibbotson Shigeru Ishida Heiko Jansen David Johnson Oleg Kolobov Giannis Kosmas Kang-Jin Lee Pieter Van Lierop Stefan Lohrum Ronald van der Meer Thomas W. Place Peter Popovics Jacob Chr. Poulsen Ko van der Sloot Mike Taylor Rustam T. Usmanov Charles Woodfield Tom André Øverland Hugh McMaster Guillaume Jactat yaz-5.37.0/doc/credits.html0000644000175000017500000000717115130444232014133 0ustar00adamadamAppendix F. Credits
Appendix F. Credits
Prev   

Appendix F. Credits

This appendix lists individuals that have contributed in the development of YAZ. Some have contributed with code, while others have provided bug fixes or suggestions. If we're missing somebody, of if you, for whatever reason, don't like to be listed here, let us know.

  • Gary Anderson

  • Dimitrios Andreadis

  • Morten Bøgeskov

  • Rocco Carbone

  • Matthew Carey

  • Hans van Dalen

  • Irina Dijour

  • Larry E. Dixson

  • Hans van den Dool

  • Mads Bondo Dydensborg

  • Franck Falcoz

  • Kevin Gamiel

  • Morten Garkier Hendriksen

  • Morten Holmqvist

  • Ian Ibbotson

  • Shigeru Ishida

  • Heiko Jansen

  • David Johnson

  • Oleg Kolobov

  • Giannis Kosmas

  • Kang-Jin Lee

  • Pieter Van Lierop

  • Stefan Lohrum

  • Ronald van der Meer

  • Thomas W. Place

  • Peter Popovics

  • Jacob Chr. Poulsen

  • Ko van der Sloot

  • Mike Taylor

  • Rustam T. Usmanov

  • Charles Woodfield

  • Tom André Øverland

  • Hugh McMaster

  • Guillaume Jactat

Prev   
Appendix E. About Index Data Home 
yaz-5.37.0/doc/yaz-json-parse.html0000644000175000017500000000544515130444232015362 0ustar00adamadamyaz-json-parse
yaz-json-parse
Prev Reference Next

Name

yaz-json-parse — YAZ JSON parser

Synopsis

yaz-json-parse [-p]

DESCRIPTION

yaz-json-parse is a utility which demonstrates the JSON API of YAZ. (yaz/json.h).

The program attempts to parse a JSON from standard input (stdin). It will return exit code 1 if parsing fails and the parsing error message will be printed to standard error (stderr). The program returns exit code 0 if parsing succeeds, and returns no output unless -p is given (see below).

OPTIONS

-p

Makes the JSON parser echo the JSON result string to standard output, if parsing from stdin was successful. If -p is given twice, then the output is a multi-line output with indentation (pretty print).

SEE ALSO

yaz(7)

Prev Up Next
Bib-1 Attribute Set Home yaz-record-iconv
yaz-5.37.0/doc/yaz-json-parse-man.xml0000644000175000017500000000404415123757344015776 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-json-parse 1 Commands yaz-json-parse YAZ JSON parser yaz-json-parse -p DESCRIPTION yaz-json-parse is a utility which demonstrates the JSON API of YAZ. (yaz/json.h). The program attempts to parse a JSON from standard input (stdin). It will return exit code 1 if parsing fails and the parsing error message will be printed to standard error (stderr). The program returns exit code 0 if parsing succeeds, and returns no output unless -p is given (see below). OPTIONS -p Makes the JSON parser echo the JSON result string to standard output, if parsing from stdin was successful. If -p is given twice, then the output is a multi-line output with indentation (pretty print). SEE ALSO yaz 7 yaz-5.37.0/doc/comstack.introduction.html0000644000175000017500000000671015130444232017020 0ustar00adamadam2. Introduction
2. Introduction
Prev Chapter 9. The COMSTACK Module Next

2. Introduction

The COMSTACK subsystem provides a transparent interface to different types of transport stacks for the exchange of BER-encoded data and HTTP packets. At present, the RFC1729 method (BER over TCP/IP), local UNIX socket and an experimental SSL stack are supported, but others may be added in time. The philosophy of the module is to provide a simple interface by hiding unused options and facilities of the underlying libraries. This is always done at the risk of losing generality, and it may prove that the interface will need extension later on.

Note

There hasn't been interest in the XTImOSI stack for some years. Therefore, it is no longer supported.

The interface is implemented in such a fashion that only the sub-layers constructed to the transport methods that you wish to use in your application are linked in.

You will note that even though simplicity was a goal in the design, the interface is still orders of magnitudes more complex than the transport systems found in many other packages. One reason is that the interface needs to support the somewhat different requirements of the different lower-layer communications stacks; another important reason is that the interface seeks to provide a more or less industrial-strength approach to asynchronous event-handling. When no function is allowed to block, things get more complex - particularly on the server side. We urge you to have a look at the demonstration client and server provided with the package. They are meant to be easily readable and instructive, while still being at least moderately useful.

Prev Up Next
Chapter 9. The COMSTACK Module Home 3. Common Functions
yaz-5.37.0/doc/zoom.extendedservices.html0000644000175000017500000004520515130444232017025 0ustar00adamadam7. Extended Services
7. Extended Services
Prev Chapter 3. ZOOM Next

7. Extended Services

ZOOM offers an interface to a subset of the Z39.50 extended services as well as a few privately defined ones:

To create an extended service operation, a ZOOM_package must be created. The operation is a five step operation. The package is created, package is configured by means of options, the package is sent, result is inspected (by means of options), the package is destroyed. 

    ZOOM_package ZOOM_connection_package(ZOOM_connection c,
                                         ZOOM_options options);

    const char *ZOOM_package_option_get(ZOOM_package p,
                                        const char *key);
    void ZOOM_package_option_set(ZOOM_package p, const char *key,
                                 const char *val);
    void ZOOM_package_send(ZOOM_package p, const char *type);

    void ZOOM_package_destroy(ZOOM_package p);

The ZOOM_connection_package creates a package for the connection given using the options specified.

Functions ZOOM_package_option_get and ZOOM_package_option_set gets and sets options.

ZOOM_package_send sends the package the via connection specified in ZOOM_connection_package. The type specifies the actual extended service package type to be sent.

Table 3.6. Extended Service Type

TypeDescription
itemorderItem Order
updateRecord Update
createDatabase Create
dropDatabase Drop
commitCommit Operation

Table 3.7. Extended Service Common Options

OptionDescriptionDefault
package-nameExtended Service Request package name. Must be specified as part of a request.none
user-idUser ID of Extended Service Package. Is a request option.none
function Function of package - one of create, delete, modify. Is a request option. create
waitAction Wait action for package. Possible values: wait, waitIfPossible, dontWait or dontReturnPackage. waitIfPossible
operationStatus Read after response. One of: done, accepted or failure. Inspect with ZOOM_pacakage_option_get. none
targetReference Target Reference. This is part of the response as returned by the target. Read it after a successful operation. Inspect with ZOOM_pacakage_option_get. none
taskStatus Read after response: One of: pending, active, complete, aborted. none
esError Read after response: is set to diagnostic code for response. none
esAddinfo Read after response: is set to additional info for response. none

7.1. Item Order

For Item Order, type must be set to itemorder in ZOOM_package_send.

Table 3.8. Item Order Options

OptionDescriptionDefault
contact-nameILL contact namenone
contact-phoneILL contact phonenone
contact-emailILL contact emailnone
itemorder-setnameName of result set for recorddefault
itemorder-itemPosition for item (record) requested. An integer1

There are two variants of item order: ILL-variant and XML document variant. In order to use the XML variant the setting doc must hold the XML item order document. If that setting is unset, the ILL-variant is used.

Table 3.9. ILL Request Options

Option
protocol-version-num
transaction-id,initial-requester-id,person-or-institution-symbol,person
transaction-id,initial-requester-id,person-or-institution-symbol,institution
transaction-id,initial-requester-id,name-of-person-or-institution,name-of-person
transaction-id,initial-requester-id,name-of-person-or-institution,name-of-institution
transaction-id,transaction-group-qualifier
transaction-id,transaction-qualifier
transaction-id,sub-transaction-qualifier
service-date-time,this,date
service-date-time,this,time
service-date-time,original,date
service-date-time,original,time
requester-id,person-or-institution-symbol,person
requester-id,person-or-institution-symbol,institution
requester-id,name-of-person-or-institution,name-of-person
requester-id,name-of-person-or-institution,name-of-institution
responder-id,person-or-institution-symbol,person
responder-id,person-or-institution-symbol,institution
responder-id,name-of-person-or-institution,name-of-person
responder-id,name-of-person-or-institution,name-of-institution
transaction-type
delivery-address,postal-address,name-of-person-or-institution,name-of-person
delivery-address,postal-address,name-of-person-or-institution,name-of-institution
delivery-address,postal-address,extended-postal-delivery-address
delivery-address,postal-address,street-and-number
delivery-address,postal-address,post-office-box
delivery-address,postal-address,city
delivery-address,postal-address,region
delivery-address,postal-address,country
delivery-address,postal-address,postal-code
delivery-address,electronic-address,telecom-service-identifier
delivery-address,electronic-address,telecom-service-addreess
billing-address,postal-address,name-of-person-or-institution,name-of-person
billing-address,postal-address,name-of-person-or-institution,name-of-institution
billing-address,postal-address,extended-postal-delivery-address
billing-address,postal-address,street-and-number
billing-address,postal-address,post-office-box
billing-address,postal-address,city
billing-address,postal-address,region
billing-address,postal-address,country
billing-address,postal-address,postal-code
billing-address,electronic-address,telecom-service-identifier
billing-address,electronic-address,telecom-service-addreess
ill-service-type
requester-optional-messages,can-send-RECEIVED
requester-optional-messages,can-send-RETURNED
requester-optional-messages,requester-SHIPPED
requester-optional-messages,requester-CHECKED-IN
search-type,level-of-service
search-type,need-before-date
search-type,expiry-date
search-type,expiry-flag
place-on-hold
client-id,client-name
client-id,client-status
client-id,client-identifier
item-id,item-type
item-id,call-number
item-id,author
item-id,title
item-id,sub-title
item-id,sponsoring-body
item-id,place-of-publication
item-id,publisher
item-id,series-title-number
item-id,volume-issue
item-id,edition
item-id,publication-date
item-id,publication-date-of-component
item-id,author-of-article
item-id,title-of-article
item-id,pagination
item-id,ISBN
item-id,ISSN
item-id,additional-no-letters
item-id,verification-reference-source
copyright-complicance
retry-flag
forward-flag
requester-note
forward-note

7.2. Record Update

For Record Update, type must be set to update in ZOOM_package_send.

Table 3.10. Record Update Options

OptionDescriptionDefault
action The update action. One of specialUpdate, recordInsert, recordReplace, recordDelete, elementUpdate. specialUpdate (recordInsert for updateVersion=1 which does not support specialUpdate)
recordIdOpaqueOpaque Record IDnone
recordIdNumberRecord ID numbernone
recordIdStringRecord ID stringnone
recordThe record itselfnone
recordOpaqueSpecifies an opaque record which is encoded as an ASN.1 ANY type with the OID as given by option syntax (see below). Option recordOpaque is an alternative to record - and record option (above) is ignored if recordOpaque is set. This option is only available in YAZ 3.0.35 and later, and is meant to facilitate Updates with servers from OCLC. none
syntaxThe record syntax (transfer syntax). Is a string that is a known record syntax. no syntax
databaseNameDatabase from connection objectDefault
correlationInfo.noteCorrelation Info Note (string)none
correlationInfo.idCorrelation Info ID (integer)none
elementSetNameElement Set for Recordnone
updateVersionRecord Update version which holds one of the values 1, 2 or 3. Each version has a distinct OID: 1.2.840.10003.9.5 (first version) , 1.2.840.10003.9.5.1 (second version) and 1.2.840.10003.9.5.1.1 (third and newest version). 3

7.3. Database Create

For Database Create, type must be set to create in ZOOM_package_send.

Table 3.11. Database Create Options

OptionDescriptionDefault
databaseNameDatabase from connection objectDefault

7.4. Database Drop

For Database Drop, type must be set to drop in ZOOM_package_send.

Table 3.12. Database Drop Options

OptionDescriptionDefault
databaseNameDatabase from connection objectDefault

7.5. Commit Operation

For Commit, type must be set to commit in ZOOM_package_send.

7.6. Protocol behavior

All the extended services are Z39.50-only.

Note

The database create, drop, and commit services are privately defined operations. Refer to esadmin.asn in YAZ for the ASN.1 definitions.

Prev Up Next
6. Scan Home 8. Options
yaz-5.37.0/doc/yaz-client-man.xml0000644000175000017500000010752115123757344015177 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-client 1 Commands yaz-client Z39.50/SRU client for implementors yaz-client server-addr DESCRIPTION yaz-client is a Z39.50/SRU client (origin) with a simple command line interface that allows you to test behavior and performance of Z39.50 targets and SRU servers. From YAZ version 4.1.0 yaz-client may also operate as a Solr Web Service client. If the server-addr is specified, the client creates a connection to the Z39.50/SRU target at the address given. When yaz-client is started it tries to read commands from one of the following files: Command file if it is given by option -f. .yazclientrc in current working directory. .yazclientrc in the user's home directory. The value of the $HOME environment variable is used to determine the home directory. Normally, $HOME is only set on POSIX systems such as Linux, FreeBSD, Solaris. OPTIONS -a filename If specified, logging of protocol packages will be appended to the file given. If filename is specified as -, the output is written to stdout. -b filename If specified, YAZ will dump BER data in readable notation to the file specified. If filename is specified as - the output is written to stdout. -c filename If specified, CCL configuration will be read from the file given. -d dump If specified, YAZ will dump BER data for all PDUs sent and received to individual files, named dump.DDD.raw, where DDD is 001, 002, 003, ... -f cmdfile Reads commands from cmdfile. When this option is used, YAZ client does not read .yazclientrc from current directory or home directory. -k size Sets preferred messages and maximum record size for Initialize Request in kilobytes. Default value is 65536 (64 MB). -m filename If specified, retrieved records will be appended to the file given. -p proxy-addr If specified, the client will use the proxy at the address given. YAZ client will connect to a proxy on the address and port given. The actual target will be specified as part of the InitRequest to inform the proxy about the actual target. -q filename If specified, CQL configuration will be read from the file given. -t displaycharset If displaycharset is given, it specifies name of the character set of the output (on the terminal on which YAZ client is running). -u auth If specified, the auth string will be used for authentication. -v level Sets the LOG level to level. Level is a sequence of tokens separated by comma. Each token is a integer or a named LOG item - one of fatal, debug, warn, log, malloc, all, none. -V Prints YAZ version. -x Makes the YAZ client print hex dumps of packages sent and received on standard output. COMMANDS The YAZ client accepts the following commands. open zurl Opens a connection to a server. The syntax for zurl is the same as described above for connecting from the command line. Syntax: [(tcp|ssl|unix|http)':']host [:port][/base] quit Quits YAZ client find query Sends a Search Request using the query given. By default the query is assumed to be PQF. See command querytype for more information. delete setname Deletes result set with name setname on the server. base base1 base2 ... Sets the name(s) of the database(s) to search. One or more databases may be specified, separated by blanks. This command overrides the database given in zurl. show [start[+number [+resultset]]] Fetches records by sending a Present Request from the start position given by start and a number of records given by number, from the result set resultset. If start is not given, then the client will fetch from the position of the last retrieved record plus 1. If number is not given, then one record will be fetched at a time. If resultset is not given, the most recently retrieved result set is used. scan term Scans database index for a term. The syntax resembles the syntax for find. If you want to scan for the word water you could write scan water but if you want to scan only in, say the title field, you would write scan @attr 1=4 water setscan set term Scans database index for a term within a result set. This is similar to the scan command but has a result set as its first argument. scanpos pos Sets preferred position for scan. This value is used in the next scan. By default, position is 1. scansize size Sets number of entries to be returned by scan. Default number of entries is 20. scanstep step Set step-size for scan. This value is used in the next scan sent to the target. By default step-size is 0. sort sortspecs Sorts a result set. The sort command takes a sequence of space-separated sort specifications, with each sort specification consisting of two space-separated words (so that the whole specification list is made up of an even number of words). The first word of each specification holds a field (sort criterion) and the second holds flags. If the sort criterion includes = it is assumed that the SortKey is of type sortAttributes using Bib-1: in this case the integer before = is the attribute type and the integer following = is the attribute value. If no = character is in the criterion, it is treated as a sortfield of type InternationalString. The flags word of each sort specification must consist of s for case sensitive or i for case insensitive, and < for ascending order or > for descending order. Example using sort criterion with attributes use=local-number and structure=numeric and ascending flag: 1=12,4=109 < Another example with "Title" sort field and descending flag: Title > sort+ Same as sort but stores the sorted result set in a new result set. authentication [auth1 [auth2 [auth3]]] Configures authentication strings to be sent to server. Zero, 1, 2 or 3 arguments may follow the auth command. If no (0) arguments are given, no authentication string is sent. If one argument is given, the Z39.50 v2 OpenStyle authentication is used. A common convention for the auth1 string is that the username and password is separated by a slash, e.g. myusername/mysecret. If two or more arguments is given Z39.50 v3 authentication is used, in which cased the first argument is used, second argument is group and third argument is password. If only two arguments are given the group is assumed to be empty. As for other commands in yaz-client, the arguments are separated by whitespace. A backslash character can be used to include a character verbatim. For example, auth myuser a\ b is a two argument auth command where user is myuser and password is a b. The authentication string is first sent to the server when the open command is issued and the Z39.50 Initialize Request is sent, so this command must be used before open in order to be effective. sru method version Selects Web Service method and version. Must be one of post, get, soap (default) or solr. Version should be either 1.1, 1.2 or 2.0 for SRU. Other versions are allowed - for testing purposes (version negotiation with SRU server). The version is currently not used for Solr Web Services list_all This command displays status and values for many settings. lslb n Sets the limit for when no records should be returned together with the search result. See the Z39.50 standard on set bounds for more details. ssub n Sets the limit for when all records should be returned with the search result. See the Z39.50 standard on set bounds for more details. mspn n Sets the number of records that should be returned if the number of records in the result set is between the values of lslb and ssub. See the Z39.50 standard on set bounds for more details. status Displays the values of lslb, ssub and mspn. setname Switches named result sets on and off. Default is on. cancel Sends a Trigger Resource Control Request to the target. facets spec Specifies requested facets to be used in search. The notation is specified in . format oid Sets the preferred transfer syntax for retrieved records. yaz-client supports all the record syntaxes that currently are registered. See Z39.50 Record Syntax Identifiers for more details. Commonly used records syntaxes include usmarc, sutrs and xml. elements e Sets the element set name for the records. Many targets support element sets B (for brief) and F (for full). close Sends a Z39.50 Close APDU and closes connection with the peer querytype type Sets the query type as used by command find. The following is supported: prefix for Prefix Query Notation (Type-1 Query); ccl for CCL search (Type-2 Query), cql for CQL (Type-104 search with CQL OID), ccl2rpn for CCL to RPN conversion (Type-1 Query), cql2rpn for CQL to RPN conversion (Type-1 Query). attributeset set Sets attribute set OID for prefix queries (RPN, Type-1). refid id Sets reference ID for Z39.50 Request(s). itemorder type no Sends an Item Order Request using the ILL External. type is either 1 or 2 which corresponds to ILL-Profile 1 and 2 respectively. The no is the Result Set position of the record to be ordered. update action recid doc Sends Item Update Request. The action argument must be the action type: one of insert, replace, delete and update. The second argument, recid, is the record identifier (any string). Third argument which is optional is the record document for the request. If doc is preceded with "<", then the following characters are treated as a filename with the records to be updated. Otherwise doc is treated as a document itself. The doc may also be quoted in double quotes. If doc is omitted, the last received record (as part of present response or piggybacked search response) is used for the update. source filename Executes list of commands from file filename, just like 'source' on most UNIX shells. A single dot (.) can be used as an alternative. ! args Executes command args in subshell using the system call. push_command command The push_command takes another command as its argument. That command is then added to the history information (so you can retrieve it later). The command itself is not executed. This command only works if you have GNU readline/history enabled. set_apdufile filename Sets that APDU should be logged to file filename. Another way to achieve APDU log is by using command-line option -a. set_auto_reconnect flag Specifies whether YAZ client automatically reconnects if the target closes connection (Z39.50 only). flag must be either on or off. set_auto_wait flag Specifies whether YAZ client should wait for response protocol packages after a request. By default YAZ client waits (on) for response packages immediately after a command (find, show) has been issued. If off is used, YAZ client does not attempt to receive packages automatically. These will have to be manually received when command wait_response is used. flag must be either on or off. set_marcdump filename Specifies that all retrieved records should be appended to file filename. This command does the same thing as option -m. schema schemaid Specifies schema for retrieval. Schema may be specified as an OID for Z39.50. For SRU, schema is a simple string URI. charset negotiationcharset [displaycharset] [[marccharset]] Specifies character set (encoding) for Z39.50 negotiation / SRU encoding and/or character set for output (terminal). negotiationcharset is the name of the character set to be negotiated by the server. The special name - for negotiationcharset specifies no character set to be negotiated. If displaycharset is given, it specifies name of the character set of the output (on the terminal on which YAZ client is running). To disable conversion of characters to the output encoding, the special name - (dash) can be used. If the special name auto is given, YAZ client will convert strings to the encoding of the terminal as returned by nl_langinfo call. If marccharset is given, it specifies name of the character set of retrieved MARC records from server. See also marccharset command. Since character set negotiation takes effect in the Z39.50 Initialize Request you should issue this command before command open is used. MARC records are not covered by Z39.50 character set negotiation, so that's why there is a separate character that must be known in order to do meaningful conversion(s). negcharset charset Specifies character set for negotiation (Z39.50). The argument is the same as second argument for command charset. displaycharset charset Specifies character set for output (display). The argument is the same as second argument for command charset. marccharset charset Specifies character set for retrieved MARC records so that YAZ client can display them in a character suitable for your display. See charset command. If auto is given, YAZ will assume that MARC21/USMARC is using MARC8/UTF8 and ISO-8859-1 for all other MARC variants. The charset argument is the same as third argument for command charset. querycharset charset Specifies character set for query terms for Z39.50 RPN queries and Z39.50 Scan Requests (termListAndStartPoint). This is a pure client-side conversion which converts from displayCharset to queryCharset. set_cclfile filename Specifies that CCL fields should be read from file file filename. This command does the same thing as option -c. set_cqlfile filename Specifies that CQL fields should be read from file file filename. This command does the same thing as option -q. register_oid name class OID This command allows you to register your own object identifier - so that instead of entering a long dot-notation you can use a short name instead. The name is your name for the OID, class is the class, and OID is the raw OID in dot notation. Class is one of: appctx, absyn, attet, transyn, diagset, recsyn, resform, accform, extserv, userinfo, elemspec, varset, schema, tagset, general. If you're in doubt use the general class. register_tab command string This command registers a TAB completion string for the command given. sleep seconds This command makes YAZ client sleep (be idle) for the number of seconds given. wait_response [ number] This command makes YAZ client wait for a number of response packages from target. If number is omitted, 1 is assumed. This command is rarely used and is only useful if command set_auto_wait is set to off. xmles OID doc Sends XML Extended Services request using the OID and doc given. zversion ver This command sets Z39.50 version for negotiation. Should be used before open. By default 3 (version 3) is used. options op1 op2.. This command sets Z39.50 options for negotiation. Should be used before open. The following options are supported: search, present, delSet, resourceReport, triggerResourceCtrl, resourceCtrl, accessCtrl, scan, sort, extendedServices, level_1Segmentation, level_2Segmentation, concurrentOperations, namedResultSets, encapsulation, resultCount, negotiationModel, duplicationDetection, queryType104, pQESCorrection, stringSchema. EXAMPLE The simplest example of a Prefix Query would be something like f knuth or f "donald knuth" In those queries, no attributes were specified. This leaves it up to the server what fields to search but most servers will search in all fields. Some servers do not support this feature though, and require that some attributes are defined. To add one attribute you could do: f @attr 1=4 computer where we search in the title field, since the use(1) is title(4). If we want to search in the author field and in the title field, and in the title field using right truncation it could look something like this: f @and @attr 1=1003 knuth @attr 1=4 @attr 5=1 computer Finally using a mix of Bib-1 and GILS attributes could look something like this: f @attrset Bib-1 @and @attr GILS 1=2008 Washington @attr 1=21 weather FILES yaz-<version>/client/client.c $HOME/.yazclientrc $HOME/.yazclient.history SEE ALSO yaz 7 bib1-attr 7 yaz-5.37.0/doc/soap.xml.html0000644000175000017500000001262315130444232014235 0ustar00adamadam3. SOAP Packages
3. SOAP Packages
Prev Chapter 6. SOAP and SRU Next

3. SOAP Packages

Every SOAP package in YAZ is represented as follows: 

#include <yaz/soap.h>

typedef struct {
    char *fault_code;
    char *fault_string;
    char *details;
} Z_SOAP_Fault;

typedef struct {
    int no;
    char *ns;
    void *p;
} Z_SOAP_Generic;

#define Z_SOAP_fault 1
#define Z_SOAP_generic 2
#define Z_SOAP_error 3
typedef struct {
    int which;
    union {
        Z_SOAP_Fault   *fault;
        Z_SOAP_Generic *generic;
        Z_SOAP_Fault   *soap_error;
    } u;
    const char *ns;
} Z_SOAP;

The fault and soap_error arms both represent a SOAP fault - struct Z_SOAP_Fault. Any other generic (valid) package is represented by Z_SOAP_Generic.

The ns as part of Z_SOAP is the namespace for SOAP itself and reflects the SOAP version. For version 1.1 it is http://schemas.xmlsoap.org/soap/envelope/, for version 1.2 it is http://www.w3.org/2001/06/soap-envelope. 

int z_soap_codec(ODR o, Z_SOAP **pp,
                 char **content_buf, int *content_len,
                 Z_SOAP_Handler *handlers);

The content_buf and content_len is XML buffer and length of buffer respectively.

The handlers is a list of SOAP codec handlers - one handler for each service namespace. For SRU SOAP, the namespace would be http://www.loc.gov/zing/srw/v1.0/.

When decoding, the z_soap_codec inspects the XML content and tries to match one of the services namespaces of the supplied handlers. If there is a match. a handler function is invoked which decodes that particular SOAP package. If successful, the returned Z_SOAP package will be of type Z_SOAP_Generic. Member no is set the offset of the handler that matched; ns is set to namespace of the matching handler; the void pointer p is set to the C data structure associated with the handler.

When a NULL namespace is met (member ns below), that specifies end-of-list.

Each handler is defined as follows: 

typedef struct {
    char *ns;
    void *client_data;
    Z_SOAP_fun f;
} Z_SOAP_Handler;

The ns is the namespace of the service associated with handler f. The client_data is user-defined data which is passed to the handler.

The prototype for a SOAP service handler is: 

int handler(ODR o, void * ptr, void **handler_data,
            void *client_data, const char *ns);

The o specifies the mode (decode/encode) as usual. The second argument, ptr, is a libxml2 tree node pointer (xmlNodePtr) and is a pointer to the Body element of the SOAP package. The handler_data is an opaque pointer to C definitions associated with the SOAP service. The client_data is the pointer which was set as part of the Z_SOAP_handler. Finally, ns is the service namespace.

Prev Up Next
2. HTTP Home 4. SRU
yaz-5.37.0/doc/installation.win32.html0000644000175000017500000003303715130444232016140 0ustar00adamadam3. Windows
3. Windows
Prev Chapter 2. Compilation and Installation Next

3. Windows

The easiest way to install YAZ on Windows is by downloading an installer from Index Data's Windows support area . The installer comes with source too - in case you wish to compile YAZ with different compiler options, etc.

3.1. Compiling from Source on Windows

YAZ is shipped with "makefiles" for the NMAKE tool that comes with Microsoft Visual Studio. It has been tested with Microsoft Visual Studio 2019 and 2022.

Start a command prompt and switch the sub directory WIN where the file makefile is located. Customize the installation by editing the makefile file (for example by using notepad). The following summarizes the most important settings in that file:

DEBUG

If set to 1, the software is compiled with debugging libraries (code generation is multi-threaded debug DLL). If set to 0, the software is compiled with release libraries (code generation is multi-threaded DLL).

HAVE_TCL, TCL

If HAVE_TCL is set to 1, nmake will use the ASN.1 compiler (Tcl based). You must set TCL to the full path of the Tcl interpreter. A Windows version of Tcl is part of Git for Windows.

If you do not have Tcl installed, set HAVE_TCL to 0.

HAVE_BISON, BISON

If GNU Bison is present, you might set HAVE_BISON to 1 and specify the Bison executable in BISON. Bison is only required if you use the Git version of YAZ or if you modify the grammar for CQL (cql.y).

A Windows version of GNU Bison can be fetched from here: Index Data's Windows support area .

HAVE_ICONV, ICONV_DIR

If HAVE_ICONV is set to 1, YAZ is compiled with iconv support. In this configuration, set ICONV_DIR to the iconv source directory.

HAVE_LIBXML2, LIBXML2_DIR

If HAVE_LIBXML2 is set to 1, YAZ is compiled with SRU support. In this configuration, set LIBXML2_DIR to the libxml2 source directory.

You can get pre-compiled Libxml2+Libxslt DLLs and headers from here. Should you with to compile those libraries yourself, refer to to Section 3.3, “Compiling Libxml2 and Libxslt on windows”

HAVE_LIBXSLT, LIBXSLT_DIR

If HAVE_LIBXSLT is set to 1, YAZ is compiled with XSLT support. In this configuration, set LIBXSLT_DIR to the libxslt source directory.

Note

libxslt depends on libxml2.

HAVE_ICU, ICU_DIR

If HAVE_ICU is set to 1, YAZ is compiled with ICU support. In this configuration, set ICU_DIR to the ICU source directory.

Pre-compiled ICU libraries for various versions of Visual Studio can be found here or from Index Data's Windows support site.

When satisfied with the settings in the makefile, type 

      nmake

Note

If the nmake command is not found on your system you probably haven't defined the environment variables required to use that tool. To fix that, find and run the batch file vcvarsall.bat. You need to run it from within the command prompt or set the environment variables "globally"; otherwise it doesn't work.

If you wish to recompile YAZ - for example if you modify settings in the makefile you can delete object files, etc by running. 

      nmake clean

The following files are generated upon successful compilation:

bin/yaz5.dll / bin/yaz5d.dll

YAZ Release/Debug DLL.

lib/yaz5.lib / lib/yaz5d.lib

Import library for yaz5.dll / yaz5d.dll.

bin/yaz_cond5.dll / bin/yaz_cond5d.dll

Release/Debug DLL for condition variable utilities (condvar.c).

lib/yaz_cond5.lib / lib/yaz_cond5d.lib

Import library for yaz_cond5.dll / yaz_cond5d.dll.

bin/yaz_icu5.dll / bin/yaz_icu5d.dll

Release/Debug DLL for the ICU wrapper utility. Only build if HAVE_ICU is 1.

lib/yaz_icu5.lib / lib/yaz_icu5d.lib

Import library for yaz_icu5.dll / yaz_icu5d.dll.

bin/yaz-ztest.exe

Z39.50 multi-threaded test/example server. It's a WIN32 console application.

bin/yaz-client.exe

YAZ Z39.50 client application. It's a WIN32 console application. See chapter YAZ client for more information.

bin/yaz-icu.exe

This program exposes the ICU wrapper library if that is enabled for YAZ. Only if ICU is available this program is built.

bin/zoomsh.exe

Simple console application implemented on top of the ZOOM functions. The application is a command line shell that allows you to enter simple commands to perform ZOOM operations.

bin/zoomtst1.exe, bin/zoomtst2.exe, ..

Several small applications that demonstrate the ZOOM API.

3.2. How to make apps using YAZ on Windows

This section will go though the process of linking your Windows applications with YAZ.

Some people are confused by the fact that we use the nmake tool to build YAZ. They think they have to do that too - in order to make their Windows applications work with YAZ. The good news is that you don't have to. You can use the integrated environment of Visual Studio if desired for your own application.

When setting up a project or Makefile you have to set the following:

include path

Set it to the include directory of YAZ.

import library yaz5.lib

You must link with this library. It's located in the sub directory lib of YAZ. If you want to link with the debug version of YAZ, you must link against yaz5d.lib instead.

dynamic link library yaz5.dll

This DLL must be in your execution path when you invoke your application. Specifically, you should distribute this DLL with your application.

3.3. Compiling Libxml2 and Libxslt on windows

Download libxml2 and Libxslt source and unpack it. In the example below we install Libxml2 2.9.2 and Libxslt 1.1.28 for 32-bit, so we use the destination directories libxml2.2.9.2.win32 and libxslt-1.1.28.win32 to reflect both version and architecture. 

      cd win32
      cscript configure.js prefix=c:\libxml2-2.9.2.win32 iconv=no
      nmake
      nmake install

Note

There's an error in configure.js for Libxml2 2.9.2. Line 17 should be assigned to configure.ac rather than configure.in.

For Libxslt it is similar. We must ensure that compilation of Libxslt links against the already installed libxml2. 

      cd win32
      cscript configure.js prefix=c:\libxslt-1.1.28.win32 iconv=no \
          lib=c:\libxml2-2.9.2.win32\lib \
	  include=c:\libxml2-2.9.2.win32\include\libxml2
      nmake
      nmake install

Prev Up Next
2. UNIX/macOS Home Chapter 3. ZOOM
yaz-5.37.0/doc/asn.html0000644000175000017500000000632215130444232013254 0ustar00adamadamChapter 5. The Z39.50 ASN.1 Module
Chapter 5. The Z39.50 ASN.1 Module
Prev   Next

Chapter 5. The Z39.50 ASN.1 Module

Table of Contents

1. Introduction
2. Preparing PDUs
3. EXTERNAL Data
4. PDU Contents Table

1. Introduction

The Z39.50 ASN.1 module provides you with a set of C struct definitions for the various PDUs of the Z39.50 protocol, as well as for the complex types appearing within the PDUs. For the primitive data types, the C representation often takes the form of an ordinary C language type, such as Odr_int which is equivalent to an integral C integer. For ASN.1 constructs that have no direct representation in C, such as general octet strings and bit strings, the ODR module (see section The ODR Module) provides auxiliary definitions.

The Z39.50 ASN.1 module is located in sub directory z39.50. There you'll find C files that implement encoders and decoders for the Z39.50 types. You'll also find the protocol definitions: z3950v3.asn, esupdate.asn, and others.

Prev   Next
7. GFS Configuration and Virtual Hosts Home 2. Preparing PDUs
yaz-5.37.0/doc/srw-diag-table.xml0000644000175000017500000002040215130444224015125 0ustar00adamadam Code Text 1 Permanent system error 2 System temporarily unavailable 3 Authentication error 4 Unsupported operation 5 Unsupported version 6 Unsupported parameter value 7 Mandatory parameter not supplied 8 Unsupported parameter 10 Query syntax error 11 Unsupported query type 12 Too many characters in query 13 Invalid or unsupported use of parentheses 14 Invalid or unsupported use of quotes 15 Unsupported context set 16 Unsupported index 17 Unsupported combination of index and context set 18 Unsupported combination of indexes 19 Unsupported relation 20 Unsupported relation modifier 21 Unsupported combination of relation modifiers 22 Unsupported combination of relation and index 23 Too many characters in term 24 Unsupported combination of relation and term 25 Special characters not quoted in term 26 Non special character escaped in term 27 Empty term unsupported 28 Masking character not supported 29 Masked words too short 30 Too many masking characters in term 31 Anchoring character not supported 32 Anchoring character in unsupported position 33 Combination of proximity/adjacency and masking characters not supported 34 Combination of proximity/adjacency and anchoring characters not supported 35 Term contains only stopwords 36 Term in invalid format for index or relation 37 Unsupported boolean operator 38 Too many boolean operators in query 39 Proximity not supported 40 Unsupported proximity relation 41 Unsupported proximity distance 42 Unsupported proximity unit 43 Unsupported proximity ordering 44 Unsupported combination of proximity modifiers 45 Prefix assigned to multiple identifiers 46 Unsupported boolean modifier 47 Cannot process query; reason unknown 48 Query feature unsupported 49 Masking character in unsupported position 50 Result sets not supported 51 Result set does not exist 52 Result set temporarily unavailable 53 Result sets only supported for retrieval 54 Retrieval may only occur from an existing result set 55 Combination of result sets with search terms not supported 56 Only combination of single result set with search terms supported 57 Result set created but no records available 58 Result set created with unpredictable partial results available 59 Result set created with valid partial results available 60 Result set not created: too many matching records 61 First record position out of range 62 Negative number of records requested 63 System error in retrieving records 64 Record temporarily unavailable 65 Record does not exist 66 Unknown schema for retrieval 67 Record not available in this schema 68 Not authorised to send record 69 Not authorised to send record in this schema 70 Record too large to send 71 Unsupported record packing 72 XPath retrieval unsupported 73 XPath expression contains unsupported feature 74 Unable to evaluate XPath expression 80 Sort not supported 81 Unsupported sort type 82 Unsupported sort sequence 83 Too many records to sort 84 Too many sort keys to sort 85 Duplicate sort keys 86 Cannot sort: incompatible record formats 87 Unsupported schema for sort 88 Unsupported path for sort 89 Path unsupported for schema 90 Unsupported direction value 91 Unsupported case value 92 Unsupported missing value action 93 Sort ended due to missing value 100 Explain not supported 101 Explain request type not supported (SOAP vs GET) 102 Explain record temporarily unavailable 110 Stylesheets not supported 111 Unsupported stylesheet 120 Response position out of range 121 Too many terms requested 235 Database does not exist 236 Access to specified database denied 1015 Init/AC: Maximum number of simultaneous sessions for Userid 1074 Proxy failure yaz-5.37.0/doc/comstack.server.html0000644000175000017500000000732315130444232015606 0ustar00adamadam5. Server Side
5. Server Side
Prev Chapter 9. The COMSTACK Module Next

5. Server Side

To establish a server under the inetd server, you can use 

    COMSTACK cs_createbysocket(int socket, CS_TYPE type, int blocking,
                               int protocol);

The socket parameter is an established socket (when your application is invoked from inetd, the socket will typically be 0. The following parameters are identical to the ones for cs_create. 

    int cs_bind(COMSTACK handle, void *address, int mode)

Binds a local address to the endpoint. Read about addresses below. The mode parameter should be either CS_CLIENT or CS_SERVER. 

    int cs_listen(COMSTACK handle, char *addr, int *addrlen);

Call this to process incoming events on an endpoint that has been bound in listening mode. It will return 0 to indicate that the connect request has been received, 1 to signal a partial reception, and -1 to indicate an error condition. 

    COMSTACK cs_accept(COMSTACK handle);

This finalizes the server-side association establishment, after cs_listen has completed successfully. It returns a new connection endpoint, which represents the new association. The application will typically wish to fork off a process to handle the association at this point, and continue listen for new connections on the old handle.

You can use the call 

    const char *cs_addrstr(COMSTACK);

on an established connection to retrieve the host-name of the remote host.

Note

You may need to use this function with some care if your name server service is slow or unreliable.

Prev Up Next
4. Client Side Home 6. Addresses
yaz-5.37.0/doc/comstack.summary.html0000644000175000017500000000523715130444232015777 0ustar00adamadam9. Summary and Synopsis
9. Summary and Synopsis
Prev Chapter 9. The COMSTACK Module Next

9. Summary and Synopsis

    #include <yaz/comstack.h>

    #include <yaz/tcpip.h>  /* this is for TCP/IP and SSL support */
    #include <yaz/unix.h>   /* this is for UNIX socket support */

    COMSTACK cs_create(CS_TYPE type, int blocking, int protocol);

    COMSTACK cs_createbysocket(int s, CS_TYPE type, int blocking,
                               int protocol);
    COMSTACK cs_create_host(const char *str, int blocking,
                            void **vp);

    int cs_bind(COMSTACK handle, int mode);

    int cs_connect(COMSTACK handle, void *address);

    int cs_rcvconnect(COMSTACK handle);

    int cs_listen(COMSTACK handle);

    COMSTACK cs_accept(COMSTACK handle);

    int cs_put(COMSTACK handle, char *buf, int len);

    int cs_get(COMSTACK handle, char **buf, int *size);

    int cs_more(COMSTACK handle);

    void cs_close(COMSTACK handle);

    int cs_look(COMSTACK handle);

    void *cs_straddr(COMSTACK handle, const char *str);

    const char *cs_addrstr(COMSTACK h);
Prev Up Next
8. Diagnostics Home Chapter 10. Future Directions
yaz-5.37.0/doc/server.backend.html0000644000175000017500000000432515130444232015370 0ustar00adamadam3. The Backend API
3. The Backend API
Prev Chapter 4. Generic server Next

3. The Backend API

The header file that you need to use the interface are in the include/yaz directory. It's called backend.h. It will include other files from the include/yaz directory, so you'll probably want to use the -I option of your compiler to tell it where to find the files. When you run make in the top-level YAZ directory, everything you need to create your server is to link with the lib/libyaz.la library.

Prev Up Next
2. The Database Frontend Home 4. Your main() Routine
yaz-5.37.0/doc/server.html0000644000175000017500000001205715130444232014003 0ustar00adamadamChapter 4. Generic server
Chapter 4. Generic server
Prev   Next

Chapter 4. Generic server

Table of Contents

1. Introduction
2. The Database Frontend
3. The Backend API
4. Your main() Routine
5. The Backend Functions
5.1. Init
5.2. Search and Retrieve
5.3. Delete
5.4. Scan
6. Application Invocation
7. GFS Configuration and Virtual Hosts

1. Introduction

If you aren't into documentation, a good way to learn how the back end interface works is to look at the backend.h file. Then, look at the small dummy-server in ztest/ztest.c. The backend.h file also makes a good reference, once you've chewed your way through the prose of this file.

If you have a database system that you would like to make available by means of Z39.50 or SRU, YAZ basically offers two options. You can use the APIs provided by the Z39.50 ASN.1, ODR, and COMSTACK modules to create and decode PDUs, and exchange them with a client. Using this low-level interface gives you access to all fields and options of the protocol, and you can construct your server as close to your existing database as you like. It is also a fairly involved process, requiring you to set up an event-handling mechanism, protocol state machine, etc. To simplify server implementation, we have implemented a compact and simple, but reasonably full-functioned server-frontend that will handle most of the protocol mechanics, while leaving you to concentrate on your database interface.

Note

The backend interface was designed in anticipation of a specific integration task, while still attempting to achieve some degree of generality. We realize fully that there are points where the interface can be improved significantly. If you have specific functions or parameters that you think could be useful, send us a mail (or better, sign on to the mailing list referred to in the top-level README file). We will try to fit good suggestions into future releases, to the extent that it can be done without requiring too many structural changes in existing applications.

Note

The YAZ server does not support XCQL.

Prev   Next
10. Events Home 2. The Database Frontend
yaz-5.37.0/doc/yaz-asncomp.html0000644000175000017500000002437515130444232014744 0ustar00adamadamyaz-asncomp
yaz-asncomp
Prev Reference Next

Name

yaz-asncomp — YAZ ASN.1 compiler

Synopsis

yaz-asncomp [-v] [-c cfile] [-h hfile] [-p pfile] [-d config] [-I includeout] [-i includedir] [-m module] [filename]

DESCRIPTION

yaz-asncomp is an ASN.1 compiler that reads an ASN.1 specification in filename and produces C/C++ definitions and BER encoders/decoders for it.

The produced C/C++ code and header files uses the ODR module of YAZ which is a library that encodes/decodes/prints BER packages. yaz-asncomp allows you to specify name of resulting source via options. Alternatively, you can specify a DEFINITIONS file, which provides customized output to many output files - if the ASN.1 specification file consists of many modules.

This utility is written in Tcl. Any version of Tcl should work.

OPTIONS

-v

Makes the ASN.1 compiler print more verbose about the various stages of operations.

-c cfile

Specifies the name of the C/C++ file with encoders/decoders.

-h hfile

Specifies the name of header file with definitions.

-p pfile

Specifies the name of the a private header file with definitions. By default all definitions are put in header file (option -h).

-d dfile

Specifies the name of a definitions file.

-I iout

Specifies first part of directory in which header files are written.

-i idir

Specifies second part of directory in which header files are written.

-m module

Specifies that ASN.1 compiler should only process the module given. If this option is not specified, all modules in the ASN.1 file are processed.

DEFINITIONS FILE

The definitions file is really a Tcl script but follows traditional rules for Shell like configuration files. That is # denotes the beginning of a comment. Definitions are line oriented. The definitions files usually consist of a series of variable assignments of the form:

set name value

Available variables are:

default-prefix

Sets prefix for names in the produced output. The value consists of three tokens: C function prefix, C typedef prefix and preprocessor prefix respectively.

prefix(module)

This value sets prefix values for module module. The value has same form as default-prefix.

filename(module)

Specifies filename for C/header file for module module.

init(module,h)

Code fragment to be put in first part of public header for module module.

body(module,h)

Code fragment to be put in last part of public header for module module (trailer).

init(module,c)

Code fragment to be put in first part of C based encoder/decoder for module module.

body(module,c)

Code fragment to be put in last part of C based encoder/decoder for module module (trailer).

map(module,name)

Maps ASN.1 type in module module of name to value.

membermap(module,name,member)

Maps member member in SEQUENCE/CHOICE of name in module module to value. The value consists of one or two tokens. First token is name of C preprocessor part. Second token is resulting C member name. If second token is omitted the value (one token) is both preprocessor part and C struct,union.

unionmap(module,name,member)

Maps member member in CHOICE of name in module module to value. Value consists of two or three tokens. The first token is name of the integer in the union that is used as selector for the union itself. The second token is name of the union. The third token overrides the name of the CHOICE member; if omitted the member name is used.

FILES

/usr/share/yaz/z39.50/z.tcl

/usr/share/yaz/z39.50/*.asn

SEE ALSO

yaz(7)

Section "The ODR Module" in the YAZ manual.

Prev Up Next
zoomsh Home yaz-marcdump
yaz-5.37.0/doc/yaz-ztest-man.xml0000644000175000017500000001305515123757344015070 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-ztest 8 System management commands yaz-ztest Z39.50/SRU Test Server &gfs-synopsis; DESCRIPTION yaz-ztest is a Z39.50/SRU test server that uses the YAZ generic front-end server (GFS) API. The server acts as a real Z39.50/SRU server but does not use a database. It returns a random hit count and returns a subset of a few built-in records. The listener-spec consists of a transport mode followed by a colon, followed by a listener address. The transport mode is either tcp, unix, or ssl. For TCP and SSL, an address has the form: hostname | IP-number [ : portnumber ] For UNIX local socket, the address is the filename of the local socket. OPTIONS &gfs-options; TESTING yaz-ztest normally returns a random hit count between 0 and 24. However, if a query term includes leading digits, then the integer value of that term is used as hit count. This allows testers to return any number of hits. yaz-ztest includes 24 MARC records for testing. Hit counts exceeding 24 will make yaz-ztest return the same record batch over and over. So record at position 1, 25, 49, etc. are equivalent. For XML, if no element set is given or element has value "marcxml", MARCXML is returned (each of the 24 dummy records converted from ISO2709 to XML). For element set OP, then OPAC XML is returned. yaz-ztest may also return predefined XML records (for testing). This is enabled if YAZ_ZTEST_XML_FETCH environment variable is defined. A record is fetched from a file (one record per file). The path for the filename is FE.d.xml where F is the YAZ_ZTEST_XML_FETCH value (possibly empty), E is element-set, d is record position (starting from 1). The following databases are honored by yaz-ztest: Default, slow and db.* (all databases with prefix "db"). Any other database will make yaz-ztest return diagnostic 109: "Database unavailable". Options for search may be included in the form or URL get arguments included as part of the Z39.50 database name. The following database options are present: search-delay, present-delay, fetch-delay and seed. The former, delay type options, specify a fake delay (sleep) that yaz-ztest will perform when searching, presenting, fetching records respectively. The value of the delay may either be a fixed floating point value which specifies the delay in seconds. Alternatively the value may be given as two floating point numbers separated by colon, which will make yaz-ztest perform a random sleep between the first and second number. The database parameter seed takes an integer as value. This will call srand with this integer to ensure that the random behavior can be re-played. Suppose we want searches to take between 0.1 and 0.5 seconds and a fetch to take 0.2 second. To access test database Default we'd use: Default?search-delay=0.1:0.5&fetch-delay=0.2. GFS CONFIGURATION AND VIRTUAL HOSTS &gfs-virtual; FILES yaz-<version>/ztest/yaz-ztest.c yaz-<version>/include/yaz/backend.h SEE ALSO yaz 7 yaz-log 7 yaz-5.37.0/doc/gfs-options.xml0000644000175000017500000001634215123757344014617 0ustar00adamadam -a file Specify a file for dumping PDUs (for diagnostic purposes). The special name - (dash) sends output to stderr. -S 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. -1 Like -S but after one session the server exits. This mode is for debugging only. -T Operate the server in threaded mode. The server creates a thread for each connection rather than fork a process. Only available on UNIX systems that offer POSIX threads. -s Use the SR protocol (obsolete). -z Use the Z39.50 protocol (default). This option and -s 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. -l file The logfile. -c config A user option that serves as a specifier for some sort of configuration, usually a filename. The argument to this option is transferred to member configname of the statserv_options_block. -f vconfig This specifies an XML file that describes one or more YAZ frontend virtual servers. -C fname Sets SSL certificate file name for server (PEM). -v level The log level. Use a comma-separated list of members of the set {fatal,debug,warn,log,malloc,all,none}. -u uid 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. -w dir The server changes to this directory before listening to incoming connections. This option is useful when the server is operating from the inetd daemon (see -i). -p pidfile Specifies that the server should write its Process ID to the file given by pidfile. A typical location would be /var/run/yaz-ztest.pid. -i Use this to make the the server run from the inetd server (UNIX only). -D Use this to make the server put itself in the background and run as a daemon. If neither -i nor -D is given, the server starts in the foreground. -install 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. -installa Use this to install the server as an NT service and mark it as "auto-start. Control the server by going to the Services in the Control Panel. -remove Use this to remove the server from the NT services (Windows NT/2000/XP only). -t minutes Idle session timeout, in minutes. -k size Maximum record size/message size, in kilobytes. -K Forces no-keepalive for HTTP sessions. By default GFS will keep sessions alive for HTTP 1.1 sessions (as defined by the standard). Using this option will force GFS to close the connection for each operation. -r size Maximum size of log file before rotation occurs, in kilobytes. Default size is 1048576 k (=1 GB). -d daemon Set name of daemon to be used in hosts access file. See hosts_access 5 and tcpd 8 . -m time-format Sets the format of time-stamps in the log-file. Specify a string in the input format to strftime(). -V Display YAZ version and exit. yaz-5.37.0/doc/comstack.common.html0000644000175000017500000002312415130444232015565 0ustar00adamadam3. Common Functions
3. Common Functions
Prev Chapter 9. The COMSTACK Module Next

3. Common Functions

3.1. Managing Endpoints

     COMSTACK cs_create(CS_TYPE type, int blocking, int protocol);

Creates an instance of the protocol stack - a communications endpoint. The type parameter determines the mode of communication. At present the following values are supported:

tcpip_type

TCP/IP (BER over TCP/IP or HTTP over TCP/IP)

ssl_type

Secure Socket Layer (SSL). This COMSTACK is experimental and is not fully implemented. If HTTP is used, this effectively is HTTPS.

unix_type

Unix socket (unix only). Local Transfer via file socket. See unix(7).

The cs_create function returns a null-pointer if a system error occurs. The blocking parameter should be '1' if you wish the association to operate in blocking mode, and '0' otherwise. The protocol field should be PROTO_Z3950 or PROTO_HTTP. Protocol PROTO_SR is no longer supported. 

     void cs_close(COMSTACK handle);

Closes the connection (as elegantly as the lower layers will permit), and releases the resources pointed to by the handle parameter. The handle should not be referenced again after this call.

Note

We really need a soft disconnect, don't we?

3.2. Data Exchange

     int cs_put(COMSTACK handle, char *buf, int len);

Sends buf down the wire. In blocking mode, this function will return only when a full buffer has been written, or an error has occurred. In nonblocking mode, it's possible that the function will be unable to send the full buffer at once, which will be indicated by a return value of 1. The function will keep track of the number of octets already written; you should call it repeatedly with the same values of buf and len, until the buffer has been transmitted. When a full buffer has been sent, the function will return 0 for success. The return value -1 indicates an error condition (see below). 

     int cs_get(COMSTACK handle, char **buf, int *size);

Receives a PDU or HTTP Response from the peer. Returns the number of bytes read. In nonblocking mode, it is possible that not all of the packet can be read at once. In this case, the function returns 1. To simplify the interface, the function is responsible for managing the size of the buffer. It will be reallocated if necessary to contain large packages, and will sometimes be moved around internally by the subsystem when partial packages are read. Before calling cs_get for the first time, the buffer can be initialized to the null pointer, and the length should also be set to 0 (cs_get will perform a malloc(2) on the buffer for you). When a full buffer has been read, the size of the package is returned (which will always be greater than 1). The return value -1 indicates an error condition.

See also the cs_more() function below. 

     int cs_more(COMSTACK handle);

The cs_more() function should be used in conjunction with cs_get and select(2). The cs_get() function will sometimes (notably in the TCP/IP mode) read more than a single protocol package off the network. When this happens, the extra package is stored by the subsystem. After calling cs_get(), and before waiting for more input, You should always call cs_more() to check if there's a full protocol package already read. If cs_more() returns 1, cs_get() can be used to immediately fetch the new package. For the mOSI subsystem, the function should always return 0, but if you want your stuff to be protocol independent, you should use it.

Note

The cs_more() function is required because the RFC1729-method does not provide a way of separating individual PDUs, short of partially decoding the BER. Some other implementations will carefully nibble at the packet by calling read(2) several times. This was felt to be too inefficient (or at least clumsy) - hence the call for this extra function. 

     int cs_look(COMSTACK handle);

This function is useful when you're operating in nonblocking mode. Call it when select(2) tells you there's something happening on the line. It returns one of the following values:

CS_NONE

No event is pending. The data found on the line was not a complete package.

CS_CONNECT

A response to your connect request has been received. Call cs_rcvconnect to process the event and to finalize the connection establishment.

CS_DISCON

The other side has closed the connection (or maybe sent a disconnect request - but do we care? Maybe later). Call cs_close to close your end of the association as well.

CS_LISTEN

A connect request has been received. Call cs_listen to process the event.

CS_DATA

There's data to be found on the line. Call cs_get to get it.

Note

You should be aware that even if cs_look() tells you that there's an event event pending, the corresponding function may still return and tell you there was nothing to be found. This means that only part of a package was available for reading. The same event will show up again, when more data has arrived. 

     int cs_fileno(COMSTACK h);

returns the file descriptor of the association. Use this when file-level operations on the endpoint are required (select(2) operations, specifically).

Prev Up Next
2. Introduction Home 4. Client Side
yaz-5.37.0/doc/asn.preparing.html0000644000175000017500000001507115130444232015243 0ustar00adamadam2. Preparing PDUs
2. Preparing PDUs
Prev Chapter 5. The Z39.50 ASN.1 Module Next

2. Preparing PDUs

A structure representing a complex ASN.1 type doesn't in itself contain the members of that type. Instead, the structure contains pointers to the members of the type. This is necessary, in part, to allow a mechanism for specifying which of the optional structure (SEQUENCE) members are present, and which are not. It follows that you will need to somehow provide space for the individual members of the structure, and set the pointers to refer to the members.

The conversion routines don't care how you allocate and maintain your C structures - they just follow the pointers that you provide. Depending on the complexity of your application, and your personal taste, there are at least three different approaches that you may take when you allocate the structures.

You can use static or automatic local variables in the function that prepares the PDU. This is a simple approach, and it provides the most efficient form of memory management. While it works well for flat PDUs like the InitRequest, it will generally not be sufficient for say, the generation of an arbitrarily complex RPN query structure.

You can individually create the structure and its members using the malloc(2) function. If you want to ensure that the data is freed when it is no longer needed, you will have to define a function that individually releases each member of a structure before freeing the structure itself.

You can use the odr_malloc() function (see Section 2, “Using ODR” for details). When you use odr_malloc(), you can release all of the allocated data in a single operation, independent of any pointers and relations between the data. The odr_malloc() function is based on a "nibble-memory" scheme, in which large portions of memory are allocated, and then gradually handed out with each call to odr_malloc(). The next time you call odr_reset(), all of the memory allocated since the last call is recycled for future use (actually, it is placed on a free-list).

You can combine all of the methods described here. This will often be the most practical approach. For instance, you might use odr_malloc() to allocate an entire structure and some of its elements, while you leave other elements pointing to global or per-session default variables.

The Z39.50 ASN.1 module provides an important aid in creating new PDUs. For each of the PDU types (say, Z_InitRequest), a function is provided that allocates and initializes an instance of that PDU type for you. In the case of the InitRequest, the function is simply named zget_InitRequest(), and it sets up reasonable default value for all of the mandatory members. The optional members are generally initialized to null pointers. This last aspect is very important: it ensures that if the PDU definitions are extended after you finish your implementation (to accommodate new versions of the protocol, say), you won't get into trouble with uninitialized pointers in your structures. The functions use odr_malloc() to allocate the PDUs and its members, so you can free everything again with a single call to odr_reset(). We strongly recommend that you use the zget_* functions whenever you are preparing a PDU (in a C++ API, the zget_ functions would probably be promoted to constructors for the individual types).

The prototype for the individual PDU types generally look like this: 

    Z_<type> *zget_<type>(ODR o);

e.g.: 

    Z_InitRequest *zget_InitRequest(ODR o);

The ODR handle should generally be your encoding stream, but it needn't be.

As well as the individual PDU functions, a function zget_APDU() is provided, which allocates a top-level Z-APDU of the type requested: 

    Z_APDU *zget_APDU(ODR o, int which);

The which parameter is (of course) the discriminator belonging to the Z_APDU CHOICE type. All of the interface described here is provided by the Z39.50 ASN.1 module, and you access it through the proto.h header file.

Prev Up Next
Chapter 5. The Z39.50 ASN.1 Module Home 3. EXTERNAL Data
yaz-5.37.0/doc/yaz-asncomp-man.xml0000644000175000017500000002241415123757344015356 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-asncomp 1 Commands yaz-asncomp YAZ ASN.1 compiler yaz-asncomp filename DESCRIPTION yaz-asncomp is an ASN.1 compiler that reads an ASN.1 specification in filename and produces C/C++ definitions and BER encoders/decoders for it. The produced C/C++ code and header files uses the ODR module of YAZ which is a library that encodes/decodes/prints BER packages. yaz-asncomp allows you to specify name of resulting source via options. Alternatively, you can specify a DEFINITIONS file, which provides customized output to many output files - if the ASN.1 specification file consists of many modules. This utility is written in Tcl. Any version of Tcl should work. OPTIONS -v Makes the ASN.1 compiler print more verbose about the various stages of operations. -c cfile Specifies the name of the C/C++ file with encoders/decoders. -h hfile Specifies the name of header file with definitions. -p pfile Specifies the name of the a private header file with definitions. By default all definitions are put in header file (option -h). -d dfile Specifies the name of a definitions file. -I iout Specifies first part of directory in which header files are written. -i idir Specifies second part of directory in which header files are written. -m module Specifies that ASN.1 compiler should only process the module given. If this option is not specified, all modules in the ASN.1 file are processed. DEFINITIONS FILE The definitions file is really a Tcl script but follows traditional rules for Shell like configuration files. That is # denotes the beginning of a comment. Definitions are line oriented. The definitions files usually consist of a series of variable assignments of the form: set name value Available variables are: default-prefix Sets prefix for names in the produced output. The value consists of three tokens: C function prefix, C typedef prefix and preprocessor prefix respectively. prefix(module) This value sets prefix values for module module. The value has same form as default-prefix. filename(module) Specifies filename for C/header file for module module. init(module,h) Code fragment to be put in first part of public header for module module. body(module,h) Code fragment to be put in last part of public header for module module (trailer). init(module,c) Code fragment to be put in first part of C based encoder/decoder for module module. body(module,c) Code fragment to be put in last part of C based encoder/decoder for module module (trailer). map(module,name) Maps ASN.1 type in module module of name to value. membermap(module,name,member) Maps member member in SEQUENCE/CHOICE of name in module module to value. The value consists of one or two tokens. First token is name of C preprocessor part. Second token is resulting C member name. If second token is omitted the value (one token) is both preprocessor part and C struct,union. unionmap(module,name,member) Maps member member in CHOICE of name in module module to value. Value consists of two or three tokens. The first token is name of the integer in the union that is used as selector for the union itself. The second token is name of the union. The third token overrides the name of the CHOICE member; if omitted the member name is used. FILES /usr/share/yaz/z39.50/z.tcl /usr/share/yaz/z39.50/*.asn SEE ALSO yaz 7 Section "The ODR Module" in the YAZ manual. yaz-5.37.0/doc/yaz-ztest.80000644000175000017500000003705315130444225013657 0ustar00adamadam'\" t .\" Title: yaz-ztest .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: System management commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-ZTEST" "8" "01/10/2026" "YAZ 5.37.0" "System management commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-ztest \- Z39\&.50/SRU Test Server .SH "SYNOPSIS" .HP \w'\fBapplication\fR\ 'u \fBapplication\fR [\fB\-install\fR] [\fB\-installa\fR] [\fB\-remove\fR] [\fB\-a\ \fR\fB\fIfile\fR\fR] [\fB\-v\ \fR\fB\fIlevel\fR\fR] [\fB\-l\ \fR\fB\fIfile\fR\fR] [\fB\-u\ \fR\fB\fIuid\fR\fR] [\fB\-c\ \fR\fB\fIconfig\fR\fR] [\fB\-f\ \fR\fB\fIvconfig\fR\fR] [\fB\-C\ \fR\fB\fIfname\fR\fR] [\fB\-t\ \fR\fB\fIminutes\fR\fR] [\fB\-k\ \fR\fB\fIkilobytes\fR\fR] [\fB\-K\fR] [\fB\-d\ \fR\fB\fIdaemon\fR\fR] [\fB\-w\ \fR\fB\fIdir\fR\fR] [\fB\-p\ \fR\fB\fIpidfile\fR\fR] [\fB\-r\ \fR\fB\fIkilobytes\fR\fR] [\fB\-ziDSTV1\fR] [listener\-spec...] .SH "DESCRIPTION" .PP \fByaz\-ztest\fR is a Z39\&.50/SRU test server that uses the YAZ generic front\-end server (GFS) API\&. The server acts as a real Z39\&.50/SRU server but does not use a database\&. It returns a random hit count and returns a subset of a few built\-in records\&. .PP The \fIlistener\-spec\fR consists of a transport mode followed by a colon, followed by a listener address\&. The transport mode is either tcp, unix, or ssl\&. .PP For TCP and SSL, an address has the form: .sp .if n \{\ .RS 4 .\} .nf hostname | IP\-number [ : portnumber ] .fi .if n \{\ .RE .\} .PP For UNIX local socket, the address is the filename of the local socket\&. .SH "OPTIONS" .PP \-a \fIfile\fR .RS 4 Specify a file for dumping PDUs (for diagnostic purposes)\&. The special name \- (dash) sends output to stderr\&. .RE .PP \-S .RS 4 Don\*(Aqt 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\&. .RE .PP \-1 .RS 4 Like \-S but after one session the server exits\&. This mode is for debugging \fIonly\fR\&. .RE .PP \-T .RS 4 Operate the server in threaded mode\&. The server creates a thread for each connection rather than fork a process\&. Only available on UNIX systems that offer POSIX threads\&. .RE .PP \-s .RS 4 Use the SR protocol (obsolete)\&. .RE .PP \-z .RS 4 Use the Z39\&.50 protocol (default)\&. This option and \-s 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\&. .RE .PP \-l \fIfile\fR .RS 4 The logfile\&. .RE .PP \-c \fIconfig\fR .RS 4 A user option that serves as a specifier for some sort of configuration, usually a filename\&. The argument to this option is transferred to member configname of the statserv_options_block\&. .RE .PP \-f \fIvconfig\fR .RS 4 This specifies an XML file that describes one or more YAZ frontend virtual servers\&. .RE .PP \-C \fIfname\fR .RS 4 Sets SSL certificate file name for server (PEM)\&. .RE .PP \-v \fIlevel\fR .RS 4 The log level\&. Use a comma\-separated list of members of the set {fatal,debug,warn,log,malloc,all,none}\&. .RE .PP \-u \fIuid\fR .RS 4 Set user ID\&. Sets the real UID of the server process to that of the given user\&. It\*(Aqs useful if you aren\*(Aqt comfortable with having the server run as root, but you need to start it as such to bind a privileged port\&. .RE .PP \-w \fIdir\fR .RS 4 The server changes to this directory before listening to incoming connections\&. This option is useful when the server is operating from the inetd daemon (see \-i)\&. .RE .PP \-p \fIpidfile\fR .RS 4 Specifies that the server should write its Process ID to the file given by \fIpidfile\fR\&. A typical location would be /var/run/yaz\-ztest\&.pid\&. .RE .PP \-i .RS 4 Use this to make the the server run from the inetd server (UNIX only)\&. .RE .PP \-D .RS 4 Use this to make the server put itself in the background and run as a daemon\&. If neither \-i nor \-D is given, the server starts in the foreground\&. .RE .PP \-install .RS 4 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\&. .RE .PP \-installa .RS 4 Use this to install the server as an NT service and mark it as "auto\-start\&. Control the server by going to the Services in the Control Panel\&. .RE .PP \-remove .RS 4 Use this to remove the server from the NT services (Windows NT/2000/XP only)\&. .RE .PP \-t \fIminutes\fR .RS 4 Idle session timeout, in minutes\&. .RE .PP \-k \fIsize\fR .RS 4 Maximum record size/message size, in kilobytes\&. .RE .PP \-K .RS 4 Forces no\-keepalive for HTTP sessions\&. By default GFS will keep sessions alive for HTTP 1\&.1 sessions (as defined by the standard)\&. Using this option will force GFS to close the connection for each operation\&. .RE .PP \-r \fIsize\fR .RS 4 Maximum size of log file before rotation occurs, in kilobytes\&. Default size is 1048576 k (=1 GB)\&. .RE .PP \-d \fIdaemon\fR .RS 4 Set name of daemon to be used in hosts access file\&. See \fBhosts_access\fR(5) and \fBtcpd\fR(8)\&. .RE .PP \-m \fItime\-format\fR .RS 4 Sets the format of time\-stamps in the log\-file\&. Specify a string in the input format to strftime()\&. .RE .PP \-V .RS 4 Display YAZ version and exit\&. .RE .SH "TESTING" .PP \fByaz\-ztest\fR normally returns a random hit count between 0 and 24\&. However, if a query term includes leading digits, then the integer value of that term is used as hit count\&. This allows testers to return any number of hits\&. \fByaz\-ztest\fR includes 24 MARC records for testing\&. Hit counts exceeding 24 will make \fByaz\-ztest\fR return the same record batch over and over\&. So record at position 1, 25, 49, etc\&. are equivalent\&. .PP For XML, if no element set is given or element has value "marcxml", MARCXML is returned (each of the 24 dummy records converted from ISO2709 to XML)\&. For element set OP, then OPAC XML is returned\&. .PP yaz\-ztest may also return predefined XML records (for testing)\&. This is enabled if YAZ_ZTEST_XML_FETCH environment variable is defined\&. A record is fetched from a file (one record per file)\&. The path for the filename is \fIF\fR\fIE\fR\&.\fId\fR\&.xml where \fIF\fR is the YAZ_ZTEST_XML_FETCH value (possibly empty), \fIE\fR is element\-set, \fId\fR is record position (starting from 1)\&. .PP The following databases are honored by \fByaz\-ztest\fR: Default, slow and db\&.* (all databases with prefix "db")\&. Any other database will make \fByaz\-ztest\fR return diagnostic 109: "Database unavailable"\&. .PP Options for search may be included in the form or URL get arguments included as part of the Z39\&.50 database name\&. The following database options are present: search\-delay, present\-delay, fetch\-delay and seed\&. .PP The former, delay type options, specify a fake delay (sleep) that \fByaz\-ztest\fR will perform when searching, presenting, fetching records respectively\&. The value of the delay may either be a fixed floating point value which specifies the delay in seconds\&. Alternatively the value may be given as two floating point numbers separated by colon, which will make \fByaz\-ztest\fR perform a random sleep between the first and second number\&. .PP The database parameter seed takes an integer as value\&. This will call srand with this integer to ensure that the random behavior can be re\-played\&. .PP Suppose we want searches to take between 0\&.1 and 0\&.5 seconds and a fetch to take 0\&.2 second\&. To access test database Default we\*(Aqd use: Default?search\-delay=0\&.1:0\&.5&fetch\-delay=0\&.2\&. .SH "GFS CONFIGURATION AND VIRTUAL HOSTS" .PP The Virtual hosts mechanism allows a YAZ front\-end server to support multiple back\-ends\&. A back\-end is selected on the basis of the TCP/IP binding (port+listening address) and/or the virtual host\&. .PP A back\-end can be configured to execute in a particular working directory\&. Or the YAZ front\-end may perform CQL to RPN conversion, thus allowing traditional Z39\&.50 back\-ends to be offered as a SRW/SRU service\&. SRW/SRU Explain information for a particular back\-end may also be specified\&. .PP For the HTTP protocol, the virtual host is specified in the Host header\&. For the Z39\&.50 protocol, the virtual host is specified as in the Initialize Request in the OtherInfo, OID 1\&.2\&.840\&.10003\&.10\&.1000\&.81\&.1\&. .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBNote\fR .ps -1 .br .PP Not all Z39\&.50 clients allow the VHOST information to be set\&. For those, the selection of the back\-end must rely on the TCP/IP information alone (port and address)\&. .sp .5v .RE .PP The YAZ front\-end server uses XML to describe the back\-end configurations\&. Command\-line option \-f specifies filename of the XML configuration\&. .PP The configuration uses the root element yazgfs\&. This element includes a list of listen elements, followed by one or more server elements\&. .PP The listen describes listener (transport end point), such as TCP/IP, Unix file socket or SSL server\&. Content for a listener: .PP CDATA (required) .RS 4 The CDATA for the listen element holds the listener string, such as tcp:@:210, tcp:server1:2100, etc\&. .RE .PP attribute id (optional) .RS 4 Identifier for this listener\&. This may be referred to from server sections\&. .RE .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBNote\fR .ps -1 .br .PP We expect more information to be added for the listen section in a future version, such as CERT file for SSL servers\&. .sp .5v .RE .PP The server describes a server and the parameters for this server type\&. Content for a server: .PP attribute id (optional) .RS 4 Identifier for this server\&. Currently not used for anything, but it might be for logging purposes\&. .RE .PP attribute listenref (optional) .RS 4 Specifies one or more listeners for this server\&. Each server ID is separated by a comma\&. If this attribute is not given, the server is accessible from all listeners\&. In order for the server to be used for real, however, the virtual host must match if specified in the configuration\&. .RE .PP element config (optional) .RS 4 Specifies the server configuration\&. This is equivalent to the config specified using command line option \-c\&. .RE .PP element directory (optional) .RS 4 Specifies a working directory for this backend server\&. If specified, the YAZ 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)\&. .RE .PP element host (optional) .RS 4 Specifies the virtual host for this server\&. If this is specified a client \fImust\fR specify this host string in order to use this backend\&. .RE .PP element cql2rpn (optional) .RS 4 Specifies a filename that includes CQL to RPN conversion for this backend server\&. See ???\&. If given, the backend server will only "see" a Type\-1/RPN query\&. .RE .PP element ccl2rpn (optional) .RS 4 Specifies a filename that includes CCL to RPN conversion for this backend server\&. See ???\&. If given, the backend server will only "see" a Type\-1/RPN query\&. .RE .PP element stylesheet (optional) .RS 4 Specifies the stylesheet reference to be part of SRU HTTP responses when the client does not specify one\&. If none is given, then if the client does not specify one, then no stylesheet reference is part of the SRU HTTP response\&. .RE .PP element client_query_charset (optional) .RS 4 If specified, a conversion from the character set given to UTF\-8 is performed by the generic frontend server\&. It is only executed for Z39\&.50 search requests (SRU/Solr are assumed to be UTF\-8 encoded already)\&. .RE .PP element docpath (optional) .RS 4 Specifies a path for local file access using HTTP\&. All URLs with a leading prefix (/ excluded) that matches the value of docpath are used for file access\&. For example, if the server is to offer access in directory xsl, the docpath would be xsl and all URLs of the form http://host/xsl will result in a local file access\&. .RE .PP element explain (optional) .RS 4 Specifies SRW/SRU ZeeRex content for this server\&. Copied verbatim to the client\&. As things are now, some of the Explain content seem redundant because host information, etc\&. is also stored elsewhere\&. .RE .PP element maximumrecordsize (optional) .RS 4 Specifies maximum record size/message size, in bytes\&. This value also serves as the maximum size of \fIincoming\fR packages (for Record Updates etc)\&. It\*(Aqs the same value as that given by the \-k option\&. .RE .PP element retrievalinfo (optional) .RS 4 Enables the retrieval facility to support conversions and specifications of record formats/types\&. See ??? for more information\&. .RE .PP The XML 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 public and the other server internal\&. .sp .if n \{\ .RS 4 .\} .nf tcp:@:9900 unix:/var/tmp/socket server1\&.mydomain /var/www/s1 config\&.cfg server2\&.mydomain /var/www/s2 config\&.cfg \&.\&./etc/pqf\&.properties server2\&.mydomain 9900 a /var/www/s3 config\&.cfg .fi .if n \{\ .RE .\} .PP There are three configured backend servers\&. The first two servers, "server1" and "server2", can be reached by both listener addresses\&. "server1" is reached by all (two) since no listenref attribute is specified\&. "server2" is reached by the two listeners specified\&. In order to distinguish between the two, a virtual host has been specified for each server in the host elements\&. .PP For "server2" elements for CQL to RPN conversion is supported and explain information has been added (a short one here to keep the example small)\&. .PP The third server, "server3" can only be reached via listener "internal"\&. .SH "FILES" .PP yaz\-/ztest/yaz\-ztest\&.c .PP yaz\-/include/yaz/backend\&.h .SH "SEE ALSO" .PP \fByaz\fR(7) \fByaz-log\fR(7) .SH "AUTHORS" .PP \fBIndex Data\fR yaz-5.37.0/doc/manref.xml0000644000175000017500000042103415130444225013602 0ustar00adamadam YAZ 5.37.0 Index Data yaz-client 1 Commands yaz-client Z39.50/SRU client for implementors yaz-client server-addr DESCRIPTION yaz-client is a Z39.50/SRU client (origin) with a simple command line interface that allows you to test behavior and performance of Z39.50 targets and SRU servers. From YAZ version 4.1.0 yaz-client may also operate as a Solr Web Service client. If the server-addr is specified, the client creates a connection to the Z39.50/SRU target at the address given. When yaz-client is started it tries to read commands from one of the following files: Command file if it is given by option -f. .yazclientrc in current working directory. .yazclientrc in the user's home directory. The value of the $HOME environment variable is used to determine the home directory. Normally, $HOME is only set on POSIX systems such as Linux, FreeBSD, Solaris. OPTIONS -a filename If specified, logging of protocol packages will be appended to the file given. If filename is specified as -, the output is written to stdout. -b filename If specified, YAZ will dump BER data in readable notation to the file specified. If filename is specified as - the output is written to stdout. -c filename If specified, CCL configuration will be read from the file given. -d dump If specified, YAZ will dump BER data for all PDUs sent and received to individual files, named dump.DDD.raw, where DDD is 001, 002, 003, ... -f cmdfile Reads commands from cmdfile. When this option is used, YAZ client does not read .yazclientrc from current directory or home directory. -k size Sets preferred messages and maximum record size for Initialize Request in kilobytes. Default value is 65536 (64 MB). -m filename If specified, retrieved records will be appended to the file given. -p proxy-addr If specified, the client will use the proxy at the address given. YAZ client will connect to a proxy on the address and port given. The actual target will be specified as part of the InitRequest to inform the proxy about the actual target. -q filename If specified, CQL configuration will be read from the file given. -t displaycharset If displaycharset is given, it specifies name of the character set of the output (on the terminal on which YAZ client is running). -u auth If specified, the auth string will be used for authentication. -v level Sets the LOG level to level. Level is a sequence of tokens separated by comma. Each token is a integer or a named LOG item - one of fatal, debug, warn, log, malloc, all, none. -V Prints YAZ version. -x Makes the YAZ client print hex dumps of packages sent and received on standard output. COMMANDS The YAZ client accepts the following commands. open zurl Opens a connection to a server. The syntax for zurl is the same as described above for connecting from the command line. Syntax: [(tcp|ssl|unix|http)':']host [:port][/base] quit Quits YAZ client find query Sends a Search Request using the query given. By default the query is assumed to be PQF. See command querytype for more information. delete setname Deletes result set with name setname on the server. base base1 base2 ... Sets the name(s) of the database(s) to search. One or more databases may be specified, separated by blanks. This command overrides the database given in zurl. show [start[+number [+resultset]]] Fetches records by sending a Present Request from the start position given by start and a number of records given by number, from the result set resultset. If start is not given, then the client will fetch from the position of the last retrieved record plus 1. If number is not given, then one record will be fetched at a time. If resultset is not given, the most recently retrieved result set is used. scan term Scans database index for a term. The syntax resembles the syntax for find. If you want to scan for the word water you could write scan water but if you want to scan only in, say the title field, you would write scan @attr 1=4 water setscan set term Scans database index for a term within a result set. This is similar to the scan command but has a result set as its first argument. scanpos pos Sets preferred position for scan. This value is used in the next scan. By default, position is 1. scansize size Sets number of entries to be returned by scan. Default number of entries is 20. scanstep step Set step-size for scan. This value is used in the next scan sent to the target. By default step-size is 0. sort sortspecs Sorts a result set. The sort command takes a sequence of space-separated sort specifications, with each sort specification consisting of two space-separated words (so that the whole specification list is made up of an even number of words). The first word of each specification holds a field (sort criterion) and the second holds flags. If the sort criterion includes = it is assumed that the SortKey is of type sortAttributes using Bib-1: in this case the integer before = is the attribute type and the integer following = is the attribute value. If no = character is in the criterion, it is treated as a sortfield of type InternationalString. The flags word of each sort specification must consist of s for case sensitive or i for case insensitive, and < for ascending order or > for descending order. Example using sort criterion with attributes use=local-number and structure=numeric and ascending flag: 1=12,4=109 < Another example with "Title" sort field and descending flag: Title > sort+ Same as sort but stores the sorted result set in a new result set. authentication [auth1 [auth2 [auth3]]] Configures authentication strings to be sent to server. Zero, 1, 2 or 3 arguments may follow the auth command. If no (0) arguments are given, no authentication string is sent. If one argument is given, the Z39.50 v2 OpenStyle authentication is used. A common convention for the auth1 string is that the username and password is separated by a slash, e.g. myusername/mysecret. If two or more arguments is given Z39.50 v3 authentication is used, in which cased the first argument is used, second argument is group and third argument is password. If only two arguments are given the group is assumed to be empty. As for other commands in yaz-client, the arguments are separated by whitespace. A backslash character can be used to include a character verbatim. For example, auth myuser a\ b is a two argument auth command where user is myuser and password is a b. The authentication string is first sent to the server when the open command is issued and the Z39.50 Initialize Request is sent, so this command must be used before open in order to be effective. sru method version Selects Web Service method and version. Must be one of post, get, soap (default) or solr. Version should be either 1.1, 1.2 or 2.0 for SRU. Other versions are allowed - for testing purposes (version negotiation with SRU server). The version is currently not used for Solr Web Services list_all This command displays status and values for many settings. lslb n Sets the limit for when no records should be returned together with the search result. See the Z39.50 standard on set bounds for more details. ssub n Sets the limit for when all records should be returned with the search result. See the Z39.50 standard on set bounds for more details. mspn n Sets the number of records that should be returned if the number of records in the result set is between the values of lslb and ssub. See the Z39.50 standard on set bounds for more details. status Displays the values of lslb, ssub and mspn. setname Switches named result sets on and off. Default is on. cancel Sends a Trigger Resource Control Request to the target. facets spec Specifies requested facets to be used in search. The notation is specified in . format oid Sets the preferred transfer syntax for retrieved records. yaz-client supports all the record syntaxes that currently are registered. See Z39.50 Record Syntax Identifiers for more details. Commonly used records syntaxes include usmarc, sutrs and xml. elements e Sets the element set name for the records. Many targets support element sets B (for brief) and F (for full). close Sends a Z39.50 Close APDU and closes connection with the peer querytype type Sets the query type as used by command find. The following is supported: prefix for Prefix Query Notation (Type-1 Query); ccl for CCL search (Type-2 Query), cql for CQL (Type-104 search with CQL OID), ccl2rpn for CCL to RPN conversion (Type-1 Query), cql2rpn for CQL to RPN conversion (Type-1 Query). attributeset set Sets attribute set OID for prefix queries (RPN, Type-1). refid id Sets reference ID for Z39.50 Request(s). itemorder type no Sends an Item Order Request using the ILL External. type is either 1 or 2 which corresponds to ILL-Profile 1 and 2 respectively. The no is the Result Set position of the record to be ordered. update action recid doc Sends Item Update Request. The action argument must be the action type: one of insert, replace, delete and update. The second argument, recid, is the record identifier (any string). Third argument which is optional is the record document for the request. If doc is preceded with "<", then the following characters are treated as a filename with the records to be updated. Otherwise doc is treated as a document itself. The doc may also be quoted in double quotes. If doc is omitted, the last received record (as part of present response or piggybacked search response) is used for the update. source filename Executes list of commands from file filename, just like 'source' on most UNIX shells. A single dot (.) can be used as an alternative. ! args Executes command args in subshell using the system call. push_command command The push_command takes another command as its argument. That command is then added to the history information (so you can retrieve it later). The command itself is not executed. This command only works if you have GNU readline/history enabled. set_apdufile filename Sets that APDU should be logged to file filename. Another way to achieve APDU log is by using command-line option -a. set_auto_reconnect flag Specifies whether YAZ client automatically reconnects if the target closes connection (Z39.50 only). flag must be either on or off. set_auto_wait flag Specifies whether YAZ client should wait for response protocol packages after a request. By default YAZ client waits (on) for response packages immediately after a command (find, show) has been issued. If off is used, YAZ client does not attempt to receive packages automatically. These will have to be manually received when command wait_response is used. flag must be either on or off. set_marcdump filename Specifies that all retrieved records should be appended to file filename. This command does the same thing as option -m. schema schemaid Specifies schema for retrieval. Schema may be specified as an OID for Z39.50. For SRU, schema is a simple string URI. charset negotiationcharset [displaycharset] [[marccharset]] Specifies character set (encoding) for Z39.50 negotiation / SRU encoding and/or character set for output (terminal). negotiationcharset is the name of the character set to be negotiated by the server. The special name - for negotiationcharset specifies no character set to be negotiated. If displaycharset is given, it specifies name of the character set of the output (on the terminal on which YAZ client is running). To disable conversion of characters to the output encoding, the special name - (dash) can be used. If the special name auto is given, YAZ client will convert strings to the encoding of the terminal as returned by nl_langinfo call. If marccharset is given, it specifies name of the character set of retrieved MARC records from server. See also marccharset command. Since character set negotiation takes effect in the Z39.50 Initialize Request you should issue this command before command open is used. MARC records are not covered by Z39.50 character set negotiation, so that's why there is a separate character that must be known in order to do meaningful conversion(s). negcharset charset Specifies character set for negotiation (Z39.50). The argument is the same as second argument for command charset. displaycharset charset Specifies character set for output (display). The argument is the same as second argument for command charset. marccharset charset Specifies character set for retrieved MARC records so that YAZ client can display them in a character suitable for your display. See charset command. If auto is given, YAZ will assume that MARC21/USMARC is using MARC8/UTF8 and ISO-8859-1 for all other MARC variants. The charset argument is the same as third argument for command charset. querycharset charset Specifies character set for query terms for Z39.50 RPN queries and Z39.50 Scan Requests (termListAndStartPoint). This is a pure client-side conversion which converts from displayCharset to queryCharset. set_cclfile filename Specifies that CCL fields should be read from file file filename. This command does the same thing as option -c. set_cqlfile filename Specifies that CQL fields should be read from file file filename. This command does the same thing as option -q. register_oid name class OID This command allows you to register your own object identifier - so that instead of entering a long dot-notation you can use a short name instead. The name is your name for the OID, class is the class, and OID is the raw OID in dot notation. Class is one of: appctx, absyn, attet, transyn, diagset, recsyn, resform, accform, extserv, userinfo, elemspec, varset, schema, tagset, general. If you're in doubt use the general class. register_tab command string This command registers a TAB completion string for the command given. sleep seconds This command makes YAZ client sleep (be idle) for the number of seconds given. wait_response [ number] This command makes YAZ client wait for a number of response packages from target. If number is omitted, 1 is assumed. This command is rarely used and is only useful if command set_auto_wait is set to off. xmles OID doc Sends XML Extended Services request using the OID and doc given. zversion ver This command sets Z39.50 version for negotiation. Should be used before open. By default 3 (version 3) is used. options op1 op2.. This command sets Z39.50 options for negotiation. Should be used before open. The following options are supported: search, present, delSet, resourceReport, triggerResourceCtrl, resourceCtrl, accessCtrl, scan, sort, extendedServices, level_1Segmentation, level_2Segmentation, concurrentOperations, namedResultSets, encapsulation, resultCount, negotiationModel, duplicationDetection, queryType104, pQESCorrection, stringSchema. EXAMPLE The simplest example of a Prefix Query would be something like f knuth or f "donald knuth" In those queries, no attributes were specified. This leaves it up to the server what fields to search but most servers will search in all fields. Some servers do not support this feature though, and require that some attributes are defined. To add one attribute you could do: f @attr 1=4 computer where we search in the title field, since the use(1) is title(4). If we want to search in the author field and in the title field, and in the title field using right truncation it could look something like this: f @and @attr 1=1003 knuth @attr 1=4 @attr 5=1 computer Finally using a mix of Bib-1 and GILS attributes could look something like this: f @attrset Bib-1 @and @attr GILS 1=2008 Washington @attr 1=21 weather FILES yaz-<version>/client/client.c $HOME/.yazclientrc $HOME/.yazclient.history SEE ALSO yaz 7 bib1-attr 7 YAZ 5.37.0 Index Data yaz-ztest 8 System management commands yaz-ztest Z39.50/SRU Test Server application listener-spec DESCRIPTION yaz-ztest is a Z39.50/SRU test server that uses the YAZ generic front-end server (GFS) API. The server acts as a real Z39.50/SRU server but does not use a database. It returns a random hit count and returns a subset of a few built-in records. The listener-spec consists of a transport mode followed by a colon, followed by a listener address. The transport mode is either tcp, unix, or ssl. For TCP and SSL, an address has the form: hostname | IP-number [ : portnumber ] For UNIX local socket, the address is the filename of the local socket. OPTIONS -a file Specify a file for dumping PDUs (for diagnostic purposes). The special name - (dash) sends output to stderr. -S 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. -1 Like -S but after one session the server exits. This mode is for debugging only. -T Operate the server in threaded mode. The server creates a thread for each connection rather than fork a process. Only available on UNIX systems that offer POSIX threads. -s Use the SR protocol (obsolete). -z Use the Z39.50 protocol (default). This option and -s 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. -l file The logfile. -c config A user option that serves as a specifier for some sort of configuration, usually a filename. The argument to this option is transferred to member configname of the statserv_options_block. -f vconfig This specifies an XML file that describes one or more YAZ frontend virtual servers. -C fname Sets SSL certificate file name for server (PEM). -v level The log level. Use a comma-separated list of members of the set {fatal,debug,warn,log,malloc,all,none}. -u uid 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. -w dir The server changes to this directory before listening to incoming connections. This option is useful when the server is operating from the inetd daemon (see -i). -p pidfile Specifies that the server should write its Process ID to the file given by pidfile. A typical location would be /var/run/yaz-ztest.pid. -i Use this to make the the server run from the inetd server (UNIX only). -D Use this to make the server put itself in the background and run as a daemon. If neither -i nor -D is given, the server starts in the foreground. -install 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. -installa Use this to install the server as an NT service and mark it as "auto-start. Control the server by going to the Services in the Control Panel. -remove Use this to remove the server from the NT services (Windows NT/2000/XP only). -t minutes Idle session timeout, in minutes. -k size Maximum record size/message size, in kilobytes. -K Forces no-keepalive for HTTP sessions. By default GFS will keep sessions alive for HTTP 1.1 sessions (as defined by the standard). Using this option will force GFS to close the connection for each operation. -r size Maximum size of log file before rotation occurs, in kilobytes. Default size is 1048576 k (=1 GB). -d daemon Set name of daemon to be used in hosts access file. See hosts_access 5 and tcpd 8 . -m time-format Sets the format of time-stamps in the log-file. Specify a string in the input format to strftime(). -V Display YAZ version and exit. TESTING yaz-ztest normally returns a random hit count between 0 and 24. However, if a query term includes leading digits, then the integer value of that term is used as hit count. This allows testers to return any number of hits. yaz-ztest includes 24 MARC records for testing. Hit counts exceeding 24 will make yaz-ztest return the same record batch over and over. So record at position 1, 25, 49, etc. are equivalent. For XML, if no element set is given or element has value "marcxml", MARCXML is returned (each of the 24 dummy records converted from ISO2709 to XML). For element set OP, then OPAC XML is returned. yaz-ztest may also return predefined XML records (for testing). This is enabled if YAZ_ZTEST_XML_FETCH environment variable is defined. A record is fetched from a file (one record per file). The path for the filename is FE.d.xml where F is the YAZ_ZTEST_XML_FETCH value (possibly empty), E is element-set, d is record position (starting from 1). The following databases are honored by yaz-ztest: Default, slow and db.* (all databases with prefix "db"). Any other database will make yaz-ztest return diagnostic 109: "Database unavailable". Options for search may be included in the form or URL get arguments included as part of the Z39.50 database name. The following database options are present: search-delay, present-delay, fetch-delay and seed. The former, delay type options, specify a fake delay (sleep) that yaz-ztest will perform when searching, presenting, fetching records respectively. The value of the delay may either be a fixed floating point value which specifies the delay in seconds. Alternatively the value may be given as two floating point numbers separated by colon, which will make yaz-ztest perform a random sleep between the first and second number. The database parameter seed takes an integer as value. This will call srand with this integer to ensure that the random behavior can be re-played. Suppose we want searches to take between 0.1 and 0.5 seconds and a fetch to take 0.2 second. To access test database Default we'd use: Default?search-delay=0.1:0.5&fetch-delay=0.2. GFS CONFIGURATION AND VIRTUAL HOSTS The Virtual hosts mechanism allows a YAZ front-end server to support multiple back-ends. A back-end is selected on the basis of the TCP/IP binding (port+listening address) and/or the virtual host. A back-end can be configured to execute in a particular working directory. Or the YAZ front-end may perform CQL to RPN conversion, thus allowing traditional Z39.50 back-ends to be offered as a SRW/SRU service. SRW/SRU Explain information for a particular back-end may also be specified. For the HTTP protocol, the virtual host is specified in the Host header. For the Z39.50 protocol, the virtual host is specified as in the Initialize Request in the OtherInfo, OID 1.2.840.10003.10.1000.81.1. Not all Z39.50 clients allow the VHOST information to be set. For those, the selection of the back-end must rely on the TCP/IP information alone (port and address). The YAZ front-end server uses XML to describe the back-end configurations. Command-line option -f specifies filename of the XML configuration. The configuration uses the root element yazgfs. This element includes a list of listen elements, followed by one or more server elements. The listen describes listener (transport end point), such as TCP/IP, Unix file socket or SSL server. Content for a listener: CDATA (required) The CDATA for the listen element holds the listener string, such as tcp:@:210, tcp:server1:2100, etc. attribute id (optional) Identifier for this listener. This may be referred to from server sections. We expect more information to be added for the listen section in a future version, such as CERT file for SSL servers. The server describes a server and the parameters for this server type. Content for a server: attribute id (optional) Identifier for this server. Currently not used for anything, but it might be for logging purposes. attribute listenref (optional) Specifies one or more listeners for this server. Each server ID is separated by a comma. If this attribute is not given, the server is accessible from all listeners. In order for the server to be used for real, however, the virtual host must match if specified in the configuration. element config (optional) Specifies the server configuration. This is equivalent to the config specified using command line option -c. element directory (optional) Specifies a working directory for this backend server. If specified, the YAZ 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). element host (optional) Specifies the virtual host for this server. If this is specified a client must specify this host string in order to use this backend. element cql2rpn (optional) Specifies a filename that includes CQL to RPN conversion for this backend server. See . If given, the backend server will only "see" a Type-1/RPN query. element ccl2rpn (optional) Specifies a filename that includes CCL to RPN conversion for this backend server. See . If given, the backend server will only "see" a Type-1/RPN query. element stylesheet (optional) Specifies the stylesheet reference to be part of SRU HTTP responses when the client does not specify one. If none is given, then if the client does not specify one, then no stylesheet reference is part of the SRU HTTP response. element client_query_charset (optional) If specified, a conversion from the character set given to UTF-8 is performed by the generic frontend server. It is only executed for Z39.50 search requests (SRU/Solr are assumed to be UTF-8 encoded already). element docpath (optional) Specifies a path for local file access using HTTP. All URLs with a leading prefix (/ excluded) that matches the value of docpath are used for file access. For example, if the server is to offer access in directory xsl, the docpath would be xsl and all URLs of the form http://host/xsl will result in a local file access. element explain (optional) Specifies SRW/SRU ZeeRex content for this server. Copied verbatim to the client. As things are now, some of the Explain content seem redundant because host information, etc. is also stored elsewhere. element maximumrecordsize (optional) Specifies maximum record size/message size, in bytes. This value also serves as the maximum size of incoming packages (for Record Updates etc). It's the same value as that given by the -k option. element retrievalinfo (optional) Enables the retrieval facility to support conversions and specifications of record formats/types. See for more information. The XML 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 public and the other server internal. <yazgfs> <listen id="public">tcp:@:9900</listen> <listen id="internal">unix:/var/tmp/socket</listen> <server id="server1"> <host>server1.mydomain</host> <directory>/var/www/s1</directory> <config>config.cfg</config> </server> <server id="server2" listenref="public,internal"> <host>server2.mydomain</host> <directory>/var/www/s2</directory> <config>config.cfg</config> <cql2rpn>../etc/pqf.properties</cql2rpn> <explain xmlns="http://explain.z3950.org/dtd/2.0/"> <serverInfo> <host>server2.mydomain</host> <port>9900</port> <database>a</database> </serverInfo> </explain> </server> <server id="server3" listenref="internal"> <directory>/var/www/s3</directory> <config>config.cfg</config> </server> </yazgfs> There are three configured backend servers. The first two servers, "server1" and "server2", can be reached by both listener addresses. "server1" is reached by all (two) since no listenref attribute is specified. "server2" is reached by the two listeners specified. In order to distinguish between the two, a virtual host has been specified for each server in the host elements. For "server2" elements for CQL to RPN conversion is supported and explain information has been added (a short one here to keep the example small). The third server, "server3" can only be reached via listener "internal". FILES yaz-<version>/ztest/yaz-ztest.c yaz-<version>/include/yaz/backend.h SEE ALSO yaz 7 yaz-log 7 YAZ 5.37.0 Index Data yaz-config 1 Commands yaz-config Script to get information about YAZ. yaz-config libraries DESCRIPTION yaz-config is a script that returns information that your own software should use to build software that uses YAZ. The following libraries are supported: threads Use the threaded version of YAZ. OPTIONS --prefix[=DIR] Returns prefix of YAZ or assume a different one if DIR is specified. --version Returns version of YAZ. --libs Library specification be used when using YAZ. --lalibs Return library specification. --cflags Return C Compiler flags. --include Return C compiler includes for YAZ header files (-Ipath). --comp Returns full path to YAZ' ASN.1 compiler: yaz-asncomp. -V Returns YAZ SHA1 ID (from Git) and version. FILES /usr/bin/yaz-config /usr/lib/libyaz*.a /usr/include/yaz/*.h SEE ALSO yaz(7) Section "How to make apps using YAZ on UNIX" in the YAZ manual. YAZ 5.37.0 Index Data yaz 7 Conventions and miscellaneous yaz Z39.50 toolkit. DESCRIPTION YAZ is a C/C++ programmer's toolkit supporting the development of Z39.50v3 clients and servers. The YAZ toolkit offers several different levels of access to the ISO23950/Z39.50, SRU Solr (client only) and ILL protocols. The level that you need to use depends on your requirements, and the role (server or client) that you want to implement. COPYRIGHT Copyright © 1995-2026 Index Data. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Index Data nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. SEE ALSO yaz-client 1 , yaz-ztest 8 , yaz-config 8 , zoomsh 1 bib1-attr 7 YAZ manual ( /usr/share/doc/yaz) YAZ home page. Z39.50 Maintenance Agency Page. YAZ 5.37.0 Index Data zoomsh 1 Commands zoomsh ZOOM shell zoomsh commands DESCRIPTION zoomsh is a ZOOM client with a simple command line interface. The client demonstrates the ZOOM API and is useful for testing targets. You may pass one or more commands to zoomsh. These commands are invoked first. OPTIONS -a apdufile Logs protocol packages into apdufile (APDU log). -e Makes zoomsh stop processing commands as soon as an error occur. The exit code of zoomsh is 1 if error occurs; 0 otherwise. -v loglevel Sets YAZ log level to loglevel. EXAMPLES If you start the yaz-ztest in one console you can use the ZOOM shell as follows: $ zoomsh ZOOM>connect localhost:9999 ZOOM>search computer localhost:9999: 7 hits ZOOM>show 0 1 1 Default USmarc 001 11224466 003 DLC 005 00000000000000.0 008 910710c19910701nju 00010 eng 010 $a 11224466 040 $a DLC $c DLC 050 00 $a 123-xyz 100 10 $a Jack Collins 245 10 $a How to program a computer 260 1 $a Penguin 263 $a 8710 300 $a p. cm. ZOOM>quit You can also achieve the same result by passing the commands as arguments on a single command line: $ zoomsh "connect localhost:9999" "search computer" "show 0 1" quit COMMANDS connect zurl Connects to the target given by zurl. close [zurl] Closes connection to target given by zurl or all targets if zurl was omitted. show [start [count]] Displays count records starting at offset given by start. First records has offset 0 (unlike the Z39.50 protocol). quit Quits zoomsh. set name [value] Sets option name to value. get name Prints value of option name. help Prints list of available commands. SEE ALSO yaz 7 , yaz-ztest 8 , Section "Building clients with ZOOM" in the YAZ manual. ZOOM home page. YAZ 5.37.0 Index Data yaz-asncomp 1 Commands yaz-asncomp YAZ ASN.1 compiler yaz-asncomp filename DESCRIPTION yaz-asncomp is an ASN.1 compiler that reads an ASN.1 specification in filename and produces C/C++ definitions and BER encoders/decoders for it. The produced C/C++ code and header files uses the ODR module of YAZ which is a library that encodes/decodes/prints BER packages. yaz-asncomp allows you to specify name of resulting source via options. Alternatively, you can specify a DEFINITIONS file, which provides customized output to many output files - if the ASN.1 specification file consists of many modules. This utility is written in Tcl. Any version of Tcl should work. OPTIONS -v Makes the ASN.1 compiler print more verbose about the various stages of operations. -c cfile Specifies the name of the C/C++ file with encoders/decoders. -h hfile Specifies the name of header file with definitions. -p pfile Specifies the name of the a private header file with definitions. By default all definitions are put in header file (option -h). -d dfile Specifies the name of a definitions file. -I iout Specifies first part of directory in which header files are written. -i idir Specifies second part of directory in which header files are written. -m module Specifies that ASN.1 compiler should only process the module given. If this option is not specified, all modules in the ASN.1 file are processed. DEFINITIONS FILE The definitions file is really a Tcl script but follows traditional rules for Shell like configuration files. That is # denotes the beginning of a comment. Definitions are line oriented. The definitions files usually consist of a series of variable assignments of the form: set name value Available variables are: default-prefix Sets prefix for names in the produced output. The value consists of three tokens: C function prefix, C typedef prefix and preprocessor prefix respectively. prefix(module) This value sets prefix values for module module. The value has same form as default-prefix. filename(module) Specifies filename for C/header file for module module. init(module,h) Code fragment to be put in first part of public header for module module. body(module,h) Code fragment to be put in last part of public header for module module (trailer). init(module,c) Code fragment to be put in first part of C based encoder/decoder for module module. body(module,c) Code fragment to be put in last part of C based encoder/decoder for module module (trailer). map(module,name) Maps ASN.1 type in module module of name to value. membermap(module,name,member) Maps member member in SEQUENCE/CHOICE of name in module module to value. The value consists of one or two tokens. First token is name of C preprocessor part. Second token is resulting C member name. If second token is omitted the value (one token) is both preprocessor part and C struct,union. unionmap(module,name,member) Maps member member in CHOICE of name in module module to value. Value consists of two or three tokens. The first token is name of the integer in the union that is used as selector for the union itself. The second token is name of the union. The third token overrides the name of the CHOICE member; if omitted the member name is used. FILES /usr/share/yaz/z39.50/z.tcl /usr/share/yaz/z39.50/*.asn SEE ALSO yaz 7 Section "The ODR Module" in the YAZ manual. YAZ 5.37.0 Index Data yaz-marcdump 1 Commands yaz-marcdump MARC record dump utility yaz-marcdump file DESCRIPTION yaz-marcdump reads MARC records from one or more files. It parses each record and supports output in line-format, ISO2709, MARCXML, MARC-in-JSON, MarcXchange as well as Hex output. This utility parses records ISO2709(raw MARC), line format, MARC-in-JSON format as well as XML if that is structured as MARCXML/MarcXchange. MARC-in-JSON encoding/decoding is supported in YAZ 5.0.5 and later. As of YAZ 2.1.18, OAI-MARC is no longer supported. OAI-MARC is deprecated. Use MARCXML instead. By default, each record is written to standard output in a line format with newline for each field, $x for each sub-field x. The output format may be changed with option -o, yaz-marcdump can also be requested to perform character set conversion of each record. OPTIONS -i format Specifies input format. Must be one of marcxml, marc (ISO2709), marcxchange (ISO25577), line (line mode MARC), turbomarc (Turbo MARC), or json (MARC-in-JSON). -o format Specifies output format. Must be one of marcxml, marc (ISO2709), marcxchange (ISO25577), line (line mode MARC), turbomarc (Turbo MARC), or json (MARC-in-JSON). -f from Specify the character set of the input MARC record. Should be used in conjunction with option -t. Refer to the yaz-iconv man page for supported character sets. -t to Specify the character set of the output. Should be used in conjunction with option -f. Refer to the yaz-iconv man page for supported character sets. -l leaderspec Specify a simple modification string for MARC leader. The leaderspec is a list of pos=value pairs, where pos is an integer offset (0 - 23) for leader. Value is either a quoted string or an integer (character value in decimal). Pairs are comma separated. For example, to set leader at offset 9 to a, use 9='a'. -s prefix Writes a chunk of records to a separate file with prefix given, i.e. splits a record batch into files with only at most "chunk" ISO2709 records per file. By default chunk is 1 (one record per file). See option -C. -C chunksize Specifies chunk size; to be used conjunction with option -s. -O offset Integer offset for at what position records whould be written. 0=first record, 1=second, .. With -L option, this allows a specific range of records to be processed. -L limit Integer limit for how many records should at most be written. With -O option, this allows a specific range of records to be processed. -p Makes yaz-marcdump print record number and input file offset of each record read. -n MARC output is omitted so that MARC input is only checked. -r Writes to stderr a summary about number of records read by yaz-marcdump. -v Writes more information about the parsing process. Useful if you have ill-formatted ISO2709 records as input. -V Prints YAZ version. EXAMPLES The following command converts MARC21/USMARC in MARC-8 encoding to MARC21/USMARC in UTF-8 encoding. Leader offset 9 is set to 'a'. Both input and output records are ISO2709 encoded. yaz-marcdump -f MARC-8 -t UTF-8 -o marc -l 9=97 marc21.raw >marc21.utf8.raw The same records may be converted to MARCXML instead in UTF-8: yaz-marcdump -f MARC-8 -t UTF-8 -o marcxml marc21.raw >marcxml.xml Turbo MARC is a compact XML notation with same semantics as MARCXML, but which allows for faster processing via XSLT. In order to generate Turbo MARC records encoded in UTF-8 from MARC21 (ISO), one could use: yaz-marcdump -f MARC8 -t UTF8 -o turbomarc -i marc marc21.raw >out.xml FILES prefix/bin/yaz-marcdump prefix/include/yaz/marcdisp.h SEE ALSO yaz 7 yaz-iconv 1 YAZ 5.37.0 Index Data yaz-iconv 1 Commands yaz-iconv YAZ Character set conversion utility yaz-iconv file DESCRIPTION yaz-iconv converts data in the character set specified by from to output in the character set as specified by to. This yaz-iconv utility is similar to the iconv found on many POSIX systems (Glibc, Solaris, etc). If no file is specified, yaz-iconv reads from standard input. OPTIONS -ffrom] Specify the character set from of the input file. Should be used in conjunction with option -t. -tto] Specify the character set of of the output. Should be used in conjunction with option -f. -v Print more information about the conversion process. ENCODINGS The yaz-iconv command and the API as defined in yaz/yaz-iconv.h is a wrapper for the library system call iconv. But YAZ' iconv utility also implements conversions on its own. The table below lists characters sets (or encodings) that are supported by YAZ. Each character set is marked with either encode or decode. If an encoding is encode-enabled, YAZ may convert to the designated encoding. If an encoding is decode-enabled, YAZ may convert from the designated encoding. marc8 (encode, decode) The MARC8 encoding as defined by the Library of Congress. Most MARC21/USMARC records use this encoding. marc8s (encode, decode) Like MARC8 but conversion prefers non-combined characters in the Latin-1 plane over combined characters. marc8lossy (encode) Lossy encoding of MARC-8. marc8lossless (encode) Lossless encoding of MARC8. utf8 (encode, decode) The most commonly used UNICODE encoding on the Internet. iso8859-1 (encode, decode) ISO-8859-1, AKA Latin-1. iso5426 (decode) ISO 5426. Some MARC records (UNIMARC) use this encoding. iso5428:1984 (encode, decode) ISO 5428:1984. advancegreek (encode, decode) An encoding for Greek in use by some vendors (Advance). danmarc (decode) Danmarc (in danish) is an encoding based on UNICODE which is used for DanMARC2 records. EXAMPLES The following command converts from ISO-8859-1 (Latin-1) to UTF-8. yaz-iconv -f ISO-8859-1 -t UTF-8 <input.lst >output.lst FILES prefix/bin/yaz-iconv prefix/include/yaz/yaz-iconv.h SEE ALSO yaz(7) iconv(1) YAZ 5.37.0 Index Data yaz-log 7 Conventions and miscellaneous yaz-log Log handling in all yaz-based programs yaz-XXXX DESCRIPTION All YAZ-based programs use a common log subsystem, and should support common command line options for controlling it. This man page documents those. OPTIONS -l logfile Specify the file where the log is to be written. If none is specified, stderr is used. The log is appended to this file. If the file grows overly large, it is silently rotated: It is renamed to logfile.1, logfile.2, .., 9 (old such file is deleted), and a new file is opened. The limit defaults to 1GB, but can be set by the program. The rotating limit can be specified with option -r for the YAZ frontend server (yaz-ztest). Rotation can also be implicitly enabled by using a filename which gets changed for a given date, due to substitutions as given by the strftime(3) function. -v loglevel Specify the logging level. The argument is a set of log level names, separated by commas (no whitespace!), optionally preceded by a '-' to negate that level. Most programs have their own default, often containing fatal,warn,log, and some application-specific values. The default list can be cleared with the word none, or individual bits can be removed by prefixing them with a dash '-'. LOG LEVELS TO CONTROL LOGGING Some of the log levels control the way the log is written. flush causes the log to be flushed after every write. This can have serious implications to performance, and should not be used in production. On the other hand, when debugging a program crash, this can be extremely useful. The option debug implies flush as well. notime prevents the writing of time stamps. This is intended for automatic test scripts, which should produce predictable log files that are easy to compare. GENERAL LOG LEVELS IN YAZ ITSELF YAZ itself uses the following log levels: fatal for fatal errors, that prevent further execution of the program. warn for warnings about things that should be corrected. debug for debugging. This flag may be used temporarily when developing or debugging yaz, or a program that uses yaz. It is practically deprecated, you should be defining and using your own log levels (see below). all turns on almost all hard-coded log levels. loglevel logs information about the log levels used by the program. Every time the log level is changed, lists all bits that are on. Every time a module asks for its log bits, this is logged. This can be used for getting an idea of what log levels are available in any program that uses yaz-log. Start the program with -v none,loglevel, and do some common operations with it. Another way is to grep for yaz_log_module_level in the source code, as in find . -name '*.[ch]' -print | xargs grep yaz_log_module_level | grep '"' | cut -d'"' -f2 | sort -u eventl, malloc, nmem, odr are used internally for debugging yaz. LOG LEVELS FOR CLIENTS zoom logs the calls to the zoom API, which may be useful in debugging client applications. LOG LEVELS FOR SERVERS server logs the server functions on a high level, starting up, listening on a port, etc. session logs individual sessions (connections). request logs a one-liner for each request (init, search, etc.). requestdetail logs the details of every request, before it is passed to the back-end, and the results received from it. Each server program (zebra, etc.) is supposed to define its own log levels in addition to these. As they depend on the server in question, they can not be described here. See above how to find out about them. LOGGING EXAMPLES See what log levels yaz-ztest is using: yaz-ztest -1 -v none,loglevel 14:43:29-23/11 [loglevel] Setting log level to 4096 = 0x00001000 14:43:29-23/11 [loglevel] Static log bit 00000001 'fatal' is off 14:43:29-23/11 [loglevel] Static log bit 00000002 'debug' is off 14:43:29-23/11 [loglevel] Static log bit 00000004 'warn' is off 14:43:29-23/11 [loglevel] Static log bit 00000008 'log' is off 14:43:29-23/11 [loglevel] Static log bit 00000080 'malloc' is off 14:43:29-23/11 [loglevel] Static log bit 00000800 'flush' is off 14:43:29-23/11 [loglevel] Static log bit 00001000 'loglevel' is ON 14:43:29-23/11 [loglevel] Static log bit 00002000 'server' is off 14:43:29-23/11 [loglevel] Dynamic log bit 00004000 'session' is off 14:43:29-23/11 [loglevel] Dynamic log bit 00008000 'request' is off 14:44:13-23/11 yaz-ztest [loglevel] returning log bit 0x4000 for 'session' 14:44:13-23/11 yaz-ztest [loglevel] returning log bit 0x2000 for 'server' 14:44:13-23/11 yaz-ztest [loglevel] returning NO log bit for 'eventl' 14:44:20-23/11 yaz-ztest [loglevel] returning log bit 0x4000 for 'session' 14:44:20-23/11 yaz-ztest [loglevel] returning log bit 0x8000 for 'request' 14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'requestdetail' 14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'odr' 14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'ztest' See the details of the requests for yaz-ztest ./yaz-ztest -1 -v requestdetail 14:45:35-23/11 yaz-ztest [server] Adding static Z3950 listener on tcp:@:9999 14:45:35-23/11 yaz-ztest [server] Starting server ./yaz-ztest pid=32200 14:45:38-23/11 yaz-ztest [session] Starting session from tcp:127.0.0.1 (pid=32200) 14:45:38-23/11 yaz-ztest [requestdetail] Got initRequest 14:45:38-23/11 yaz-ztest [requestdetail] Id: 81 14:45:38-23/11 yaz-ztest [requestdetail] Name: YAZ 14:45:38-23/11 yaz-ztest [requestdetail] Version: 2.0.28 14:45:38-23/11 yaz-ztest [requestdetail] Negotiated to v3: srch prst del extendedServices namedresults scan sort 14:45:38-23/11 yaz-ztest [request] Init from 'YAZ' (81) (ver 2.0.28) OK 14:45:39-23/11 yaz-ztest [requestdetail] Got SearchRequest. 14:45:39-23/11 yaz-ztest [requestdetail] ResultSet '1' 14:45:39-23/11 yaz-ztest [requestdetail] Database 'Default' 14:45:39-23/11 yaz-ztest [requestdetail] RPN query. Type: Bib-1 14:45:39-23/11 yaz-ztest [requestdetail] term 'foo' (general) 14:45:39-23/11 yaz-ztest [requestdetail] resultCount: 7 14:45:39-23/11 yaz-ztest [request] Search Z: @attrset Bib-1 foo OK:7 hits 14:45:41-23/11 yaz-ztest [requestdetail] Got PresentRequest. 14:45:41-23/11 yaz-ztest [requestdetail] Request to pack 1+1 1 14:45:41-23/11 yaz-ztest [requestdetail] pms=1048576, mrs=1048576 14:45:41-23/11 yaz-ztest [request] Present: [1] 1+1 OK 1 records returned LOG FILENAME EXAMPLES A file with format my_YYYYMMDD.log (where Y, M, D is year, month, and day digits) is given as follows: -l my_%Y%m%d.log . And since the filename is depending on day, rotation will occur on midnight. A weekly log could be specified as -l my_%Y%U.log. FILES prefix/include/yaz/log.h prefix/src/log.c SEE ALSO yaz 7 yaz-ztest 8 yaz-client 1 strftime 3 YAZ 5.37.0 Index Data yaz-illclient 1 Commands yaz-illclient ILL client yaz-illclient name=value server-addr DESCRIPTION yaz-illclient is a client which sends an ISO ILL request to a remote server and decodes the response from it. Exactly one server address ( server-addr ) must be specified. OPTIONS -f filename] Specify filename. -v loglevel] Specify the log level. -D name=value] Defines name & value pair. -o Enable OCLC authentication. -u user] Specify user. -p password] Specify password. -V Show yaz-illclient version. EXAMPLES None yet. FILES None yet. SEE ALSO yaz(7) YAZ 5.37.0 Index Data yaz-icu 1 Commands yaz-icu YAZ ICU utility yaz-icu -c config -p opt -s -x infile DESCRIPTION yaz-icu is a utility which demonstrates the ICU chain module of yaz. (yaz/icu.h). The utility can be used in two ways. It may read some text using an XML configuration for configuring ICU and show text analysis. This mode is triggered by option -c which specifies the configuration to be used. The input file is read from standard input or from a file if infile is specified. The utility may also show ICU information. This is triggered by option -p. OPTIONS -c config Specifies the file containing ICU chain configuration which is XML based. -p type Specifies extra information to be printed about the ICU system. If type is c then ICU converters are printed. If type is l, then available locales are printed. If type is t, then available transliterators are printed. -s Specifies that output should include sort key as well. Note that sort key differs between ICU versions. -x Specifies that output should be XML based rather than "text" based. ICU chain configuration The ICU chain configuration specifies one or more rules to convert text data into tokens. The configuration format is XML based. The toplevel element must be named icu_chain. The icu_chain element has one required attribute locale which specifies the ICU locale to be used in the conversion steps. The icu_chain element must include elements where each element specifies a conversion step. The conversion is performed in the order in which the conversion steps are specified. Each conversion element takes one attribute: rule which serves as argument to the conversion step. The following conversion elements are available: casemap Converts case (and rule specifies how): l Lower case using ICU function u_strToLower. u Upper case using ICU function u_strToUpper. t To title using ICU function u_strToTitle. f Fold case using ICU function u_strFoldCase. display This is a meta step which specifies that a term/token is to be displayed. This term is retrieved in an application using function icu_chain_token_display (yaz/icu.h). transform Specifies an ICU transform rule using a transliterator Identifier. The rule attribute is the transliterator Identifier. See ICU Transforms for more information. transliterate Specifies a rule-based transliterator. The rule attribute is the custom transformation rule to be used. See ICU Transforms for more information. tokenize Breaks / tokenizes a string into components using ICU functions ubrk_open, ubrk_setText, .. . The rule is one of: l Line. ICU: UBRK_LINE. s Sentence. ICU: UBRK_SENTENCE. w Word. ICU: UBRK_WORD. c Character. ICU: UBRK_CHARACTER. t Title. ICU: UBRK_TITLE. join Joins tokens into one string. The rule attribute is the joining string, which may be empty. The join conversion element was added in YAZ 4.2.49. EXAMPLES The following command analyzes text in file text using ICU chain configuration chain.xml: cat text | yaz-icu -c chain.xml The chain.xml might look as follows: <icu_chain locale="en"> <transform rule="[:Control:] Any-Remove"/> <tokenize rule="w"/> <transform rule="[[:WhiteSpace:][:Punctuation:]] Remove"/> <transliterate rule="xy > z;"/> <display/> <casemap rule="l"/> </icu_chain> SEE ALSO yaz 7 ICU Home ICU Transforms YAZ 5.37.0 Index Data yaz-url 1 Commands yaz-url YAZ URL fetch utility yaz-url -H name:value -m method -O fname -p fname -R num -u user/password -v -x proxy url DESCRIPTION yaz-url is utility to get web content. It is very limited in functionality compared to programs such as curl, wget. The options must precede the URL given on the command line, to take effect. Fetched HTTP content is written to stdout, unless option -O is given. OPTIONS -H name:value Specifies HTTP header content with name and value. This option can be given multiple times (for different names, of course). -m method Specifies the HTTP method to be used for the next URL. Default is method "GET". However, option -p sets it to "POST". -O fname Sets output filename for HTTP content. -p fname Sets a file to be POSTed in the following URL. -R num Sets maximum number of HTTP redirects to be followed. A value of zero disables follow of HTTP redirects. -u user/password Specifies a user and a password to be used in HTTP basic authentication in the following URL fetch. The user and password must be separated by a slash (thus it is not possible to specify a user with a slash in it). -v Makes yaz-url dump each HTTP request/response to stdout. -x proxy Specifies a proxy to be used for URL fetch. SEE ALSO yaz 7 YAZ 5.37.0 Index Data Bib-1 Attribute Set 7 Conventions and miscellaneous bib1-attr Bib-1 Attribute Set DESCRIPTION This reference entry lists the Bib-1 attribute set types and values. TYPES The Bib-1 attribute set defines six attribute types: Use (1), Relation (2), Position (3), Structure (4), Truncation (5) and Completeness (6). USE (1) 1 Personal-name 2 Corporate-name 3 Conference-name 4 Title 5 Title-series 6 Title-uniform 7 ISBN 8 ISSN 9 LC-card-number 10 BNB-card-number 11 BGF-number 12 Local-number 13 Dewey-classification 14 UDC-classification 15 Bliss-classification 16 LC-call-number 17 NLM-call-number 18 NAL-call-number 19 MOS-call-number 20 Local-classification 21 Subject-heading 22 Subject-Rameau 23 BDI-index-subject 24 INSPEC-subject 25 MESH-subject 26 PA-subject 27 LC-subject-heading 28 RVM-subject-heading 29 Local-subject-index 30 Date 31 Date-of-publication 32 Date-of-acquisition 33 Title-key 34 Title-collective 35 Title-parallel 36 Title-cover 37 Title-added-title-page 38 Title-caption 39 Title-running 40 Title-spine 41 Title-other-variant 42 Title-former 43 Title-abbreviated 44 Title-expanded 45 Subject-precis 46 Subject-rswk 47 Subject-subdivision 48 Number-natl-biblio 49 Number-legal-deposit 50 Number-govt-pub 51 Number-music-publisher 52 Number-db 53 Number-local-call 54 Code-language 55 Code-geographic 56 Code-institution 57 Name-and-title 58 Name-geographic 59 Place-publication 60 CODEN 61 Microform-generation 62 Abstract 63 Note 1000 Author-title 1001 Record-type 1002 Name 1003 Author 1004 Author-name-personal 1005 Author-name-corporate 1006 Author-name-conference 1007 Identifier-standard 1008 Subject-LC-childrens 1009 Subject-name-personal 1010 Body-of-text 1011 Date/time-added-to-db 1012 Date/time-last-modified 1013 Authority/format-id 1014 Concept-text 1015 Concept-reference 1016 Any 1017 Server-choice 1018 Publisher 1019 Record-source 1020 Editor 1021 Bib-level 1022 Geographic-class 1023 Indexed-by 1024 Map-scale 1025 Music-key 1026 Related-periodical 1027 Report-number 1028 Stock-number 1030 Thematic-number 1031 Material-type 1032 Doc-id 1033 Host-item 1034 Content-type 1035 Anywhere 1036 Author-Title-Subject RELATION (2) 1 Less than 2 Less than or equal 3 Equal 4 Greater or equal 5 Greater than 6 Not equal 100 Phonetic 101 Stem 102 Relevance 103 AlwaysMatches POSITION (3) 1 First in field 2 First in subfield 3 Any position in field STRUCTURE (4) 1 Phrase 2 Word 3 Key 4 Year 5 Date (normalized) 6 Word list 100 Date (un-normalized) 101 Name (normalized) 102 Name (un-normalized) 103 Structure 104 Urx 105 Free-form-text 106 Document-text 107 Local-number 108 String 109 Numeric-string TRUNCATION (5) 1 Right truncation 2 Left truncation 3 Left and right truncation 100 Do not truncate 101 Process # in search term . regular #=.* 102 RegExpr-1 103 RegExpr-2 104 Process # ?n . regular: #=., ?n=.{0,n} or ?=.* Z39.58 The 105-106 truncation attributes below are only supported by Index Data's Zebra server. 105 Process * ! regular: *=.*, !=. and right truncate 106 Process * ! regular: *=.*, !=. COMPLETENESS (6) 1 Incomplete subfield 2 Complete subfield 3 Complete field SORTING (7) 1 ascending 2 descending Type 7 is an Index Data extension to RPN queries that allows embedding a sort critieria into a query. SEE ALSO Bib-1 Attribute Set Attribute Set Bib-1 Semantics. YAZ 5.37.0 Index Data yaz-json-parse 1 Commands yaz-json-parse YAZ JSON parser yaz-json-parse -p DESCRIPTION yaz-json-parse is a utility which demonstrates the JSON API of YAZ. (yaz/json.h). The program attempts to parse a JSON from standard input (stdin). It will return exit code 1 if parsing fails and the parsing error message will be printed to standard error (stderr). The program returns exit code 0 if parsing succeeds, and returns no output unless -p is given (see below). OPTIONS -p Makes the JSON parser echo the JSON result string to standard output, if parsing from stdin was successful. If -p is given twice, then the output is a multi-line output with indentation (pretty print). SEE ALSO yaz 7 YAZ 5.37.0 Index Data yaz-record-iconv 1 Commands yaz-record-conv YAZ Record Conversion Utility yaz-record-conv config fname DESCRIPTION yaz-record-conv is a program that exercises the record conversion sub system. Refer to record_conv.h header. OPTIONS -v level Sets the LOG level to level. Level is a sequence of tokens separated by comma. Each token is a integer or a named LOG item - one of fatal, debug, warn, log, malloc, all, none. EXAMPLES The following backend configuration converts MARC records (ISO2709) to Dublin-Core XML. <backend name="F" syntax="usmarc"> <marc inputcharset="marc-8" inputformat="marc" outputformat="marcxml"/> <xslt stylesheet="../etc/MARC21slim2DC.xsl"/> </backend> We can convert one of the sample records from YAZ' test directory with: $ ../util/yaz-record-conv record-conv-conf.xml marc6.marc <?xml version="1.0"?> <dc:dc xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:title>How to program a computer</dc:title> <dc:creator> Jack Collins </dc:creator> <dc:type>text</dc:type> <dc:publisher>Penguin</dc:publisher> <dc:language>eng</dc:language> </dc:dc> FILES record_conv.h SEE ALSO yaz(7) yaz-5.37.0/doc/zoom.records.html0000644000175000017500000002737215130444232015127 0ustar00adamadam4. Records
4. Records
Prev Chapter 3. ZOOM Next

4. Records

A record object is a retrieval record on the client side - created from result sets. 

     void ZOOM_resultset_records(ZOOM_resultset r,
                                 ZOOM_record *recs,
                                 size_t start, size_t count);
     ZOOM_record ZOOM_resultset_record(ZOOM_resultset s, size_t pos);

     const char *ZOOM_record_get(ZOOM_record rec, const char *type,
                                 size_t *len);

     int ZOOM_record_error(ZOOM_record rec, const char **msg,
                           const char **addinfo, const char **diagset);

     ZOOM_record ZOOM_record_clone(ZOOM_record rec);

     void ZOOM_record_destroy(ZOOM_record rec);

References to temporary records are returned by functions ZOOM_resultset_records or ZOOM_resultset_record.

If a persistent reference to a record is desired ZOOM_record_clone should be used. It returns a record reference that should be destroyed by a call to ZOOM_record_destroy.

A single record is returned by function ZOOM_resultset_record that takes a position as argument. First record has position zero. If no record could be obtained NULL is returned.

Error information for a record can be checked with ZOOM_record_error which returns non-zero (error code) if record is in error, called Surrogate Diagnostics in Z39.50.

Function ZOOM_resultset_records retrieves a number of records from a result set. Parameter start and count specifies the range of records to be returned. Upon completion, the array recs[0], ..recs[count-1] holds record objects for the records. The array of records recs should be allocated prior the call ZOOM_resultset_records. Note that for those records that couldn't be retrieved from the target, recs[ ..] is set to NULL.

In order to extract information about a single record, ZOOM_record_get is provided. The function returns a pointer to certain record information. The nature (type) of the pointer depends on the parameter, type.

The type is a string of the format:

format[;charset=from[/opacfrom][,to]][;format=v][;base64=xpath]

If charset is given, then from specifies the character set of the record in its original form (as returned by the server), to specifies the output (returned) character set encoding. If to is omitted, then UTF-8 is assumed. If charset is not given, then no character set conversion takes place. OPAC records may be returned in a different set from the bibliographic MARC record. If this is this the case, opacfrom should be set to the character set of the OPAC record part.

The format is generic but can only be used to specify XML indentation when the value v is 1 (format=1).

The base64 allows a full record to be extracted from base64-encoded string in an XML document.

Note

Specifying the OPAC record character set requires YAZ 4.1.5 or later.

Specifying the base64 parameter requires YAZ 4.2.35 or later.

The format argument controls whether record data should be XML pretty-printed (post process operation). It is enabled only if format value v is 1 and the record content is XML well-formed.

In addition, for certain types, the length len passed will be set to the size in bytes of the returned information.

The following are the supported values for form.

database

The Database of the record is returned as a C null-terminated string. Return type const char *.

syntax

The transfer syntax of the record is returned as a C null-terminated string containing the symbolic name of the record syntax, e.g. Usmarc. Return type is const char *.

schema

The schema of the record is returned as a C null-terminated string. Return type is const char *.

render

The record is returned in a display friendly format. Upon completion, buffer is returned (type const char *) and length is stored in *len.

raw

The record is returned in the internal YAZ specific format. For GRS-1, Explain, and others, the raw data is returned as type Z_External * which is just the type for the member retrievalRecord in type NamePlusRecord. For SUTRS and octet aligned record (including all MARCs) the octet buffer is returned and the length of the buffer.

xml

The record is returned in XML if possible. SRU, Solr and Z39.50 records with transfer syntax XML are returned verbatim. MARC records are returned in MARCXML (converted from ISO2709 to MARCXML by YAZ). OPAC records are also converted to XML and the bibliographic record is converted to MARCXML (when possible). GRS-1 records are not supported for this form. Upon completion, the XML buffer is returned (type const char *) and length is stored in *len.

opac

OPAC information for record is returned in XML if an OPAC record is present at the position given. If no OPAC record is present, a NULL pointer is returned.

txml

The record is returned in TurboMARC if possible. SRU and Z39.50 records with transfer syntax XML are returned verbatim. MARC records are returned in TurboMARC (converted from ISO2709 to TurboMARC by YAZ). Upon completion, the XML buffer is returned (type const char *) and length is stored in *len.

json

Like xml, but MARC records are converted to MARC-in-JSON.

Most MARC21 records uses the MARC-8 character set encoding. An application that wishes to display in Latin-1 would use 

     render; charset=marc8,iso-8859-1

4.1. Z39.50 Protocol behavior

The functions ZOOM_resultset_record and ZOOM_resultset_records inspects the client-side record cache. Records not found in cache are fetched using Present. The functions may block (and perform network I/O) - even though option async is 1, because they return records objects. (And there's no way to return records objects without retrieving them!)

There is a trick, however, in the usage of function ZOOM_resultset_records that allows for delayed retrieval (and makes it non-blocking). By using a null pointer for recs you're indicating you're not interested in getting records objects now.

4.2. SRU/Solr Protocol behavior

The ZOOM driver for SRU/Solr treats records returned by a SRU/Solr server as if they where Z39.50 records with transfer syntax XML and no element set name or database name.

Prev Up Next
3. Result sets Home 5. ZOOM Facets
yaz-5.37.0/doc/future.html0000644000175000017500000000564315130444232014012 0ustar00adamadamChapter 10. Future Directions
Chapter 10. Future Directions
Prev   Next

Chapter 10. Future Directions

We have a new and better version of the front-end server on the drawing board. Resources and external commitments will govern when we'll be able to do something real with it. Features should include greater flexibility, greater support for access/resource control, and easy support for Explain (possibly with Zebra as an extra database engine).

YAZ is a BER toolkit and as such should support all protocols out there based on that. We'd like to see running ILL applications. It shouldn't be that hard. Another thing that would be interesting is LDAP. Maybe a generic framework for doing IR using both LDAP and Z39.50 transparently.

The SOAP implementation is incomplete. In the future we hope to add more features to it. Perhaps make a WSDL/XML Schema compiler. The authors of libxml2 are already working on XML Schema and RELAX NG compilers so this may not be too hard.

It would be neat to have a proper module mechanism for the Generic Frontend Server so that backend would be dynamically loaded (as shared objects / DLLs).

Other than that, YAZ generally moves in the directions which appear to make the most people happy (including ourselves, as prime users of the software). If there's something you'd like to see in here, then drop us a note and let's see what we can come up with.

Prev   Next
9. Summary and Synopsis Home Reference
yaz-5.37.0/doc/gfs-synopsis.xml0000644000175000017500000000310415123757344015003 0ustar00adamadam &gfs-synopsis-app; listener-spec yaz-5.37.0/doc/soap.http.html0000644000175000017500000000462515130444232014417 0ustar00adamadam2. HTTP
2. HTTP
Prev Chapter 6. SOAP and SRU Next

2. HTTP

YAZ only offers HTTP as transport carrier for SOAP, but it is relatively easy to change that.

The following definition of Z_GDU (Generic Data Unit) allows for both HTTP and Z39.50 in one packet. 

#include <yaz/zgdu.h>

#define Z_GDU_Z3950         1
#define Z_GDU_HTTP_Request  2
#define Z_GDU_HTTP_Response 3
typedef struct {
  int which;
  union {
    Z_APDU *z3950;
    Z_HTTP_Request *HTTP_Request;
    Z_HTTP_Response *HTTP_Response;
  } u;
} Z_GDU ;

The corresponding Z_GDU encoder/decoder is z_GDU. The z3950 is any of the known BER encoded Z39.50 APDUs. HTTP_Request and HTTP_Response is the HTTP Request and Response respectively.

Prev Up Next
Chapter 6. SOAP and SRU Home 3. SOAP Packages
yaz-5.37.0/doc/bib1-attr.70000644000175000017500000001431315130444227013465 0ustar00adamadam'\" t .\" Title: Bib-1 Attribute Set .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Conventions and miscellaneous .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "BIB\-1 ATTRIBUTE SET" "7" "01/10/2026" "YAZ 5.37.0" "Conventions and miscellaneous" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" bib1-attr \- Bib\-1 Attribute Set .SH "DESCRIPTION" .PP This reference entry lists the Bib\-1 attribute set types and values\&. .SH "TYPES" .PP The Bib\-1 attribute set defines six attribute types: Use (1), Relation (2), Position (3), Structure (4), Truncation (5) and Completeness (6)\&. .SH "USE (1)" .PP .if n \{\ .RS 4 .\} .nf 1 Personal\-name 2 Corporate\-name 3 Conference\-name 4 Title 5 Title\-series 6 Title\-uniform 7 ISBN 8 ISSN 9 LC\-card\-number 10 BNB\-card\-number 11 BGF\-number 12 Local\-number 13 Dewey\-classification 14 UDC\-classification 15 Bliss\-classification 16 LC\-call\-number 17 NLM\-call\-number 18 NAL\-call\-number 19 MOS\-call\-number 20 Local\-classification 21 Subject\-heading 22 Subject\-Rameau 23 BDI\-index\-subject 24 INSPEC\-subject 25 MESH\-subject 26 PA\-subject 27 LC\-subject\-heading 28 RVM\-subject\-heading 29 Local\-subject\-index 30 Date 31 Date\-of\-publication 32 Date\-of\-acquisition 33 Title\-key 34 Title\-collective 35 Title\-parallel 36 Title\-cover 37 Title\-added\-title\-page 38 Title\-caption 39 Title\-running 40 Title\-spine 41 Title\-other\-variant 42 Title\-former 43 Title\-abbreviated 44 Title\-expanded 45 Subject\-precis 46 Subject\-rswk 47 Subject\-subdivision 48 Number\-natl\-biblio 49 Number\-legal\-deposit 50 Number\-govt\-pub 51 Number\-music\-publisher 52 Number\-db 53 Number\-local\-call 54 Code\-language 55 Code\-geographic 56 Code\-institution 57 Name\-and\-title 58 Name\-geographic 59 Place\-publication 60 CODEN 61 Microform\-generation 62 Abstract 63 Note 1000 Author\-title 1001 Record\-type 1002 Name 1003 Author 1004 Author\-name\-personal 1005 Author\-name\-corporate 1006 Author\-name\-conference 1007 Identifier\-standard 1008 Subject\-LC\-childrens 1009 Subject\-name\-personal 1010 Body\-of\-text 1011 Date/time\-added\-to\-db 1012 Date/time\-last\-modified 1013 Authority/format\-id 1014 Concept\-text 1015 Concept\-reference 1016 Any 1017 Server\-choice 1018 Publisher 1019 Record\-source 1020 Editor 1021 Bib\-level 1022 Geographic\-class 1023 Indexed\-by 1024 Map\-scale 1025 Music\-key 1026 Related\-periodical 1027 Report\-number 1028 Stock\-number 1030 Thematic\-number 1031 Material\-type 1032 Doc\-id 1033 Host\-item 1034 Content\-type 1035 Anywhere 1036 Author\-Title\-Subject .fi .if n \{\ .RE .\} .sp .SH "RELATION (2)" .PP .if n \{\ .RS 4 .\} .nf 1 Less than 2 Less than or equal 3 Equal 4 Greater or equal 5 Greater than 6 Not equal 100 Phonetic 101 Stem 102 Relevance 103 AlwaysMatches .fi .if n \{\ .RE .\} .sp .SH "POSITION (3)" .PP .if n \{\ .RS 4 .\} .nf 1 First in field 2 First in subfield 3 Any position in field .fi .if n \{\ .RE .\} .sp .SH "STRUCTURE (4)" .PP .if n \{\ .RS 4 .\} .nf 1 Phrase 2 Word 3 Key 4 Year 5 Date (normalized) 6 Word list 100 Date (un\-normalized) 101 Name (normalized) 102 Name (un\-normalized) 103 Structure 104 Urx 105 Free\-form\-text 106 Document\-text 107 Local\-number 108 String 109 Numeric\-string .fi .if n \{\ .RE .\} .sp .SH "TRUNCATION (5)" .PP .if n \{\ .RS 4 .\} .nf 1 Right truncation 2 Left truncation 3 Left and right truncation 100 Do not truncate 101 Process # in search term \&. regular #=\&.* 102 RegExpr\-1 103 RegExpr\-2 104 Process # ?n \&. regular: #=\&., ?n=\&.{0,n} or ?=\&.* Z39\&.58 .fi .if n \{\ .RE .\} .PP The 105\-106 truncation attributes below are only supported by Index Data\*(Aqs Zebra server\&. .sp .if n \{\ .RS 4 .\} .nf 105 Process * ! regular: *=\&.*, !=\&. and right truncate 106 Process * ! regular: *=\&.*, !=\&. .fi .if n \{\ .RE .\} .sp .SH "COMPLETENESS (6)" .PP .if n \{\ .RS 4 .\} .nf 1 Incomplete subfield 2 Complete subfield 3 Complete field .fi .if n \{\ .RE .\} .sp .SH "SORTING (7)" .PP .if n \{\ .RS 4 .\} .nf 1 ascending 2 descending .fi .if n \{\ .RE .\} .PP Type 7 is an Index Data extension to RPN queries that allows embedding a sort critieria into a query\&. .SH "SEE ALSO" .PP \m[blue]\fBBib\-1 Attribute Set\fR\m[]\&\s-2\u[1]\d\s+2 .PP \m[blue]\fBAttribute Set Bib\-1 Semantics\fR\m[]\&\s-2\u[2]\d\s+2\&. .SH "AUTHORS" .PP \fBIndex Data\fR .SH "NOTES" .IP " 1." 4 Bib-1 Attribute Set .RS 4 \%https://www.loc.gov/z3950/agency/defns/bib1.html .RE .IP " 2." 4 Attribute Set Bib-1 Semantics .RS 4 \%http://www.loc.gov/z3950/agency/bib1.html .RE yaz-5.37.0/doc/zoom.facets.html0000644000175000017500000001056115130444232014723 0ustar00adamadam5. ZOOM Facets
5. ZOOM Facets
Prev Chapter 3. ZOOM Next

5. ZOOM Facets

Facets are only supported for a few Z39.50 targets. It is a relatively new non-standard Z39.50 extension (see facets.asn in the YAZ source). However, facets are usually supported for Solr and SRU 2.0 targets.

Facets may be specified by the facets option before a search is sent. See Section 8, “Facets” for the notation. For inspection of the returned facets, the following functions are available: 

    ZOOM_facet_field *ZOOM_resultset_facets(ZOOM_resultset r);

    size_t ZOOM_resultset_facets_size(ZOOM_resultset r);

    ZOOM_facet_field ZOOM_resultset_get_facet_field(ZOOM_resultset r,
                                                    const char *facet_name);

    ZOOM_facet_field ZOOM_resultset_get_facet_field_by_index(ZOOM_resultset r,
                                                             int pos);

    const char *ZOOM_facet_field_name(ZOOM_facet_field facet_field);

    size_t ZOOM_facet_field_term_count(ZOOM_facet_field facet_field);

    const char *ZOOM_facet_field_get_term(ZOOM_facet_field facet_field,
                                          size_t idx, int *freq);

References to temporary structures are returned by all functions. They are only valid as long the Result set is valid.

All facet fields may be returned by a call to ZOOM_resultset_facets. The length of the array is given by ZOOM_resultset_facets_size. The array is zero-based and the last entry will be at ZOOM_resultset_facets_size(result_set)-1.

Facet fields can also be fetched via its name using ZOOM_resultset_get_facet_field. Or by its index (starting from 0) by a call to ZOOM_resultset_get_facet_field_by_index. Both of these functions return NULL if name is not found or index is out of bounds.

Function ZOOM_facet_field_name gets the request facet name from a returned facet field.

Function ZOOM_facet_field_get_term returns the idx'th term and term count for a facet field. Idx must between 0 and ZOOM_facet_field_term_count-1, otherwise the returned reference will be NULL. On a valid idx, the value of the freq reference will be the term count. The freq parameter must be valid pointer to integer.

Prev Up Next
4. Records Home 6. Scan
yaz-5.37.0/doc/comstack.addresses.html0000644000175000017500000001041415130444232016250 0ustar00adamadam6. Addresses
6. Addresses
Prev Chapter 9. The COMSTACK Module Next

6. Addresses

The low-level format of the addresses are different depending on the mode of communication you have chosen. A function is provided by each of the lower layers to map a user-friendly string-form address to the binary form required by the lower layers. 

    void *cs_straddr(COMSTACK handle, const char *str);

The format for TCP/IP and SSL addresses is: 

    <host> [ ':' <portnum> ]

The hostname can be either a domain name or an IP address. The port number, if omitted, defaults to 210.

For TCP/IP and SSL, the special hostnames @, maps to IN6ADDR_ANY_INIT with IPV4 binding as well (bindv6only=0), The special hostname @4 binds to INADDR_ANY (IPV4 only listener). The special hostname @6 binds to IN6ADDR_ANY_INIT with bindv6only=1 (IPV6 only listener).

For UNIX sockets, the format of an address is the socket filename.

When a connection has been established, you can use 

    const char *cs_addrstr(COMSTACK h);

to retrieve the host name of the peer system. The function returns a pointer to a static area, which is overwritten on the next call to the function.

A fairly recent addition to the COMSTACK module is the utility function 

    COMSTACK cs_create_host (const char *str, int blocking, void **vp);

which is just a wrapper for cs_create and cs_straddr. The str is similar to that described for cs_straddr but with a prefix denoting the COMSTACK type. Prefixes supported are tcp: and unix: and ssl: for TCP/IP and UNIX and SSL respectively. If no prefix is given, then TCP/IP is used. The blocking is passed to function cs_create. The third parameter vp is a pointer to COMSTACK stack type specific values. Parameter vp is reserved for future use. Set it to NULL.

Prev Up Next
5. Server Side Home 7. SSL
yaz-5.37.0/doc/comstack.diagnostics.html0000644000175000017500000000540515130444232016606 0ustar00adamadam8. Diagnostics
8. Diagnostics
Prev Chapter 9. The COMSTACK Module Next

8. Diagnostics

All functions return -1 if an error occurs. Typically, the functions will return 0 on success, but the data exchange functions (cs_get, cs_put, cs_more) follow special rules. Consult their descriptions.

The error code for the COMSTACK can be retrieved using C macro cs_errno which will return one of the error codes CSYSERR, CSOUTSTATE, CSNODATA, ... 

    int cs_errno(COMSTACK handle);

You can the textual representation of the error code by using cs_errmsg, which works like strerror(3). 

    const char *cs_errmsg(int n);

It is also possible to get straight to the textual representation without the error code, by using cs_strerror. 

    const char *cs_strerror(COMSTACK h);
Prev Up Next
7. SSL Home 9. Summary and Synopsis
yaz-5.37.0/doc/yaz-man.xml0000644000175000017500000000766015123757344013726 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz 7 Conventions and miscellaneous yaz Z39.50 toolkit. DESCRIPTION YAZ is a C/C++ programmer's toolkit supporting the development of Z39.50v3 clients and servers. The YAZ toolkit offers several different levels of access to the ISO23950/Z39.50, SRU Solr (client only) and ILL protocols. The level that you need to use depends on your requirements, and the role (server or client) that you want to implement. COPYRIGHT Copyright © ©right-year; Index Data. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Index Data nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. SEE ALSO yaz-client 1 , yaz-ztest 8 , yaz-config 8 , zoomsh 1 bib1-attr 7 YAZ manual ( /usr/share/doc/yaz) YAZ home page. Z39.50 Maintenance Agency Page. yaz-5.37.0/doc/server.frontend.html0000644000175000017500000000663515130444232015626 0ustar00adamadam2. The Database Frontend
2. The Database Frontend
Prev Chapter 4. Generic server Next

2. The Database Frontend

We refer to this software as a generic database frontend. Your database system is the backend database, and the interface between the two is called the backend API. The backend API consists of a small number of function handlers and structure definitions. You are required to provide the main() routine for the server (which can be quite simple), as well as a set of handlers to match each of the prototypes. The interface functions that you write can use any mechanism you like to communicate with your database system: You might link the whole thing together with your database application and access it by function calls; you might use IPC to talk to a database server somewhere; or you might link with third-party software that handles the communication for you (like a commercial database client library). At any rate, the handlers will perform the tasks of:

  • Initialization.

  • Searching.

  • Fetching records.

  • Scanning the database index (optional - if you wish to implement SCAN).

  • Extended Services (optional).

  • Result-Set Delete (optional).

  • Result-Set Sort (optional).

  • Return Explain for SRU (optional).

(more functions will be added in time to support as much of Z39.50-1995 as possible).

Prev Up Next
Chapter 4. Generic server Home 3. The Backend API
yaz-5.37.0/doc/zoomsh.html0000644000175000017500000001412615130444232014013 0ustar00adamadamzoomsh
zoomsh
Prev Reference Next

Name

zoomsh — ZOOM shell

Synopsis

zoomsh [-a apdufile] [-e] [-v loglevel] [commands...]

DESCRIPTION

zoomsh is a ZOOM client with a simple command line interface. The client demonstrates the ZOOM API and is useful for testing targets.

You may pass one or more commands to zoomsh. These commands are invoked first.

OPTIONS

-a apdufile

Logs protocol packages into apdufile (APDU log).

-e

Makes zoomsh stop processing commands as soon as an error occur. The exit code of zoomsh is 1 if error occurs; 0 otherwise.

-v loglevel

Sets YAZ log level to loglevel.

EXAMPLES

If you start the yaz-ztest in one console you can use the ZOOM shell as follows: 

$ zoomsh
ZOOM>connect localhost:9999
ZOOM>search computer
localhost:9999: 7 hits
ZOOM>show 0 1
1 Default USmarc
001    11224466
003 DLC
005 00000000000000.0
008 910710c19910701nju           00010 eng
010    $a    11224466
040    $a DLC $c DLC
050 00 $a 123-xyz
100 10 $a Jack Collins
245 10 $a How to program a computer
260 1  $a Penguin
263    $a 8710
300    $a p. cm.
ZOOM>quit

You can also achieve the same result by passing the commands as arguments on a single command line:

$ zoomsh "connect localhost:9999" "search computer" "show 0 1" quit

COMMANDS

connect zurl

Connects to the target given by zurl.

close [zurl]

Closes connection to target given by zurl or all targets if zurl was omitted.

show [start [count]]

Displays count records starting at offset given by start. First records has offset 0 (unlike the Z39.50 protocol).

quit

Quits zoomsh.

set name [value]

Sets option name to value.

get name

Prints value of option name.

help

Prints list of available commands.

SEE ALSO

yaz(7), yaz-ztest(8),

Section "Building clients with ZOOM" in the YAZ manual.

ZOOM home page.

Prev Up Next
yaz Home yaz-asncomp
yaz-5.37.0/doc/asn.external.html0000644000175000017500000001546615130444232015106 0ustar00adamadam3. EXTERNAL Data
3. EXTERNAL Data
Prev Chapter 5. The Z39.50 ASN.1 Module Next

3. EXTERNAL Data

In order to achieve extensibility and adaptability to different application domains, the new version of the protocol defines many structures outside of the main ASN.1 specification, referencing them through ASN.1 EXTERNAL constructs. To simplify the construction and access to the externally referenced data, the Z39.50 ASN.1 module defines a specialized version of the EXTERNAL construct, called Z_External.It is defined thus: 

typedef struct Z_External
{
    Odr_oid *direct_reference;
    int *indirect_reference;
    char *descriptor;
    enum
    {
        /* Generic types */
        Z_External_single = 0,
        Z_External_octet,
        Z_External_arbitrary,

        /* Specific types */
        Z_External_SUTRS,
        Z_External_explainRecord,
        Z_External_resourceReport1,
        Z_External_resourceReport2

    ...

    } which;
    union
    {
        /* Generic types */
        Odr_any *single_ASN1_type;
        Odr_oct *octet_aligned;
        Odr_bitmask *arbitrary;

        /* Specific types */
        Z_SUTRS *sutrs;
        Z_ExplainRecord *explainRecord;
        Z_ResourceReport1 *resourceReport1;
        Z_ResourceReport2 *resourceReport2;

        ...

    } u;
} Z_External;

When decoding, the Z39.50 ASN.1 module will attempt to determine which syntax describes the data by looking at the reference fields (currently only the direct-reference). For ASN.1 structured data, you need only consult the which field to determine the type of data. You can the access the data directly through the union. When constructing data for encoding, you set the union pointer to point to the data, and set the which field accordingly. Remember also to set the direct (or indirect) reference to the correct OID for the data type. For non-ASN.1 data such as MARC records, use the octet_aligned arm of the union.

Some servers return ASN.1 structured data values (e.g. database records) as BER-encoded records placed in the octet-aligned branch of the EXTERNAL CHOICE. The ASN-module will not automatically decode these records. To help you decode the records in the application, the function 

   Z_ext_typeent *z_ext_gettypebyref(const oid *oid);

can be used to retrieve information about the known, external data types. The function returns a pointer to a static area, or NULL, if no match for the given direct reference is found. The Z_ext_typeent is defined as: 

typedef struct Z_ext_typeent
{
    int oid[OID_SIZE]; /* the direct-reference OID. */
    int what;          /* discriminator value for the external CHOICE */
    Odr_fun fun;       /* decoder function */
} Z_ext_typeent;

The what member contains the Z_External union discriminator value for the given type: For the SUTRS record syntax, the value would be Z_External_sutrs. The fun member contains a pointer to the function which encodes/decodes the given type. Again, for the SUTRS record syntax, the value of fun would be z_SUTRS (a function pointer).

If you receive an EXTERNAL which contains an octet-string value that you suspect of being an ASN.1-structured data value, you can use z_ext_gettypebyref to look for the provided direct-reference. If the return value is different from NULL, you can use the provided function to decode the BER string (see Section 2, “Using ODR” ).

If you want to send EXTERNALs containing ASN.1-structured values in the octet-aligned branch of the CHOICE, this is possible too. However, on the encoding phase, it requires a somewhat involved juggling around of the various buffers involved.

If you need to add new, externally defined data types, you must update the struct above, in the source file prt-ext.h, as well as the encoder/decoder in the file prt-ext.c. When changing the latter, remember to update both the arm array and the list type_table, which drives the CHOICE biasing that is necessary to tell the different, structured types apart on decoding.

Note

Eventually, the EXTERNAL processing will most likely automatically insert the correct OIDs or indirect-refs. First, however, we need to determine how application-context management (specifically the presentation-context-list) should fit into the various modules.

Prev Up Next
2. Preparing PDUs Home 4. PDU Contents Table
yaz-5.37.0/doc/yaz-url.html0000644000175000017500000001050215130444232014071 0ustar00adamadamyaz-url
yaz-url
Prev Reference Next

Name

yaz-url — YAZ URL fetch utility

Synopsis

yaz-url [-H name:value] [-m method] [-O fname] [-p fname] [-R num] [-u user/password] [-v] [-x proxy] [url...]

DESCRIPTION

yaz-url is utility to get web content. It is very limited in functionality compared to programs such as curl, wget.

The options must precede the URL given on the command line, to take effect.

Fetched HTTP content is written to stdout, unless option -O is given.

OPTIONS

-H name:value

Specifies HTTP header content with name and value. This option can be given multiple times (for different names, of course).

-m method

Specifies the HTTP method to be used for the next URL. Default is method "GET". However, option -p sets it to "POST".

-O fname

Sets output filename for HTTP content.

-p fname

Sets a file to be POSTed in the following URL.

-R num

Sets maximum number of HTTP redirects to be followed. A value of zero disables follow of HTTP redirects.

-u user/password

Specifies a user and a password to be used in HTTP basic authentication in the following URL fetch. The user and password must be separated by a slash (thus it is not possible to specify a user with a slash in it).

-v

Makes yaz-url dump each HTTP request/response to stdout.

-x proxy

Specifies a proxy to be used for URL fetch.

SEE ALSO

yaz(7)

Prev Up Next
yaz-icu Home Bib-1 Attribute Set
yaz-5.37.0/doc/tools.log.html0000644000175000017500000002052415130444232014413 0ustar00adamadam4. Log
4. Log
Prev Chapter 7. Supporting Tools Next

4. Log

YAZ has evolved a fairly complex log system which should be useful both for debugging YAZ itself, debugging applications that use YAZ, and for production use of those applications.

The log functions are declared in header yaz/log.h and implemented in src/log.c. Due to name clash with syslog and some math utilities the logging interface has been modified as of YAZ 2.0.29. The obsolete interface is still available in header file yaz/log.h. The key points of the interface are: 

    void yaz_log(int level, const char *fmt, ...)
    void yaz_log_init(int level, const char *prefix, const char *name);
    void yaz_log_init_file(const char *fname);
    void yaz_log_init_level(int level);
    void yaz_log_init_prefix(const char *prefix);
    void yaz_log_time_format(const char *fmt);
    void yaz_log_init_max_size(int mx);

    int yaz_log_mask_str(const char *str);
    int yaz_log_module_level(const char *name);

The reason for the whole log module is the yaz_log function. It takes a bitmask indicating the log levels, a printf-like format string, and a variable number of arguments to log.

The log level is a bit mask, that says on which level(s) the log entry should be made, and optionally set some behaviour of the logging. In the most simple cases, it can be one of YLOG_FATAL, YLOG_DEBUG, YLOG_WARN, YLOG_LOG. Those can be combined with bits that modify the way the log entry is written:YLOG_ERRNO, YLOG_NOTIME, YLOG_FLUSH. Most of the rest of the bits are deprecated, and should not be used. Use the dynamic log levels instead.

Applications that use YAZ, should not use the LOG_LOG for ordinary messages, but should make use of the dynamic loglevel system. This consists of two parts, defining the loglevel and checking it.

To define the log levels, the (main) program should pass a string to yaz_log_mask_str to define which log levels are to be logged. This string should be a comma-separated list of log level names, and can contain both hard-coded names and dynamic ones. The log level calculation starts with YLOG_DEFAULT_LEVEL and adds a bit for each word it meets, unless the word starts with a '-', in which case it clears the bit. If the string 'none' is found, all bits are cleared. Typically this string comes from the command-line, often identified by -v. The yaz_log_mask_str returns a log level that should be passed to yaz_log_init_level for it to take effect.

Each module should check what log bits should be used, by calling yaz_log_module_level with a suitable name for the module. The name is cleared of a preceding path and an extension, if any, so it is quite possible to use __FILE__ for it. If the name has been passed to yaz_log_mask_str, the routine returns a non-zero bitmask, which should then be used in consequent calls to yaz_log. (It can also be tested, so as to avoid unnecessary calls to yaz_log, in time-critical places, or when the log entry would take time to construct.)

Yaz uses the following dynamic log levels: server, session, request, requestdetail for the server functionality. zoom for the zoom client API. ztest for the simple test server. malloc, nmem, odr, eventl for internal debugging of yaz itself. Of course, any program using yaz is welcome to define as many new ones as it needs.

By default the log is written to stderr, but this can be changed by a call to yaz_log_init_file or yaz_log_init. If the log is directed to a file, the file size is checked at every write, and if it exceeds the limit given in yaz_log_init_max_size, the log is rotated. The rotation keeps one old version (with a .1 appended to the name). The size defaults to 1GB. Setting it to zero will disable the rotation feature. 

    A typical yaz-log looks like this
  13:23:14-23/11 yaz-ztest(1) [session] Starting session from tcp:127.0.0.1 (pid=30968)
  13:23:14-23/11 yaz-ztest(1) [request] Init from 'YAZ' (81) (ver 2.0.28) OK
  13:23:17-23/11 yaz-ztest(1) [request] Search Z: @attrset Bib-1 foo  OK:7 hits
  13:23:22-23/11 yaz-ztest(1) [request] Present: [1] 2+2  OK 2 records returned
  13:24:13-23/11 yaz-ztest(1) [request] Close OK

The log entries start with a time stamp. This can be omitted by setting the YLOG_NOTIME bit in the loglevel. This way automatic tests can be hoped to produce identical log files, that are easy to diff. The format of the time stamp can be set with yaz_log_time_format, which takes a format string just like strftime.

Next in a log line comes the prefix, often the name of the program. For yaz-based servers, it can also contain the session number. Then comes one or more logbits in square brackets, depending on the logging level set by yaz_log_init_level and the loglevel passed to yaz_log_init_level. Finally comes the format string and additional values passed to yaz_log

The log level YLOG_LOGLVL, enabled by the string loglevel, will log all the log-level affecting operations. This can come in handy if you need to know what other log levels would be useful. Grep the logfile for [loglevel].

The log system is almost independent of the rest of YAZ, the only important dependence is of nmem, and that only for using the semaphore definition there.

The dynamic log levels and log rotation were introduced in YAZ 2.0.28. At the same time, the log bit names were changed from LOG_something to YLOG_something, to avoid collision with syslog.h.

Prev Up Next
3. Nibble Memory Home 5. MARC
yaz-5.37.0/doc/installation.unix.html0000644000175000017500000005734515130444232016171 0ustar00adamadam2. UNIX/macOS
2. UNIX/macOS
Prev Chapter 2. Compilation and Installation Next

2. UNIX/macOS

We provide Debian GNU/Linux (i386 and amd64), Ubuntu (i386 and amd64) and CentOS (amd64 only) packages for YAZ. You should be able to create packages for other CPUs by building them from the source package.

YAZ is also part of several packages repositories. Some of them are

2.1. Compiling from source on Unix

You can choose to compile YAZ from official tar releases from https://ftp.indexdata.com/pub/yaz/ or clone it via GitHub https://github.com/indexdata/yaz.git.

If you wish to use character set conversion facilities in YAZ or if you are compiling YAZ for use with Zebra, it is a good idea to ensure that the iconv library is installed. Some Unixes today already have it - if not, we suggest GNU libiconv.

YAZ 3.0.16 and later includes a wrapper for the ICU (International Components for Unicode). In order to use this, the developer version of the ICU library must be available. ICU support is recommended for applications such as Pazpar2 and Zebra.

The libxslt, libxml2 libraries are required if YAZ is to support SRU/Solr. These libraries are very portable and should compile out-of-the box on virtually all Unix platforms. It is available in binary forms for Linux and others.

The GNU tools Autoconf, Automake and Libtool are used to generate Makefiles and configure YAZ for the system. You do not need these tools unless you're using the Git version of YAZ.

The CQL parser for YAZ is built using GNU Bison. This tool is only needed if you're using the Git version of YAZ.

YAZ includes a tiny ASN.1 compiler. This compiler is written in Tcl. But as for Bison you do not need it unless you're using Git version of YAZ or you're using the compiler to build your own codecs for private ASN.1.

If you are checking out from Git, run: 

      ./buildconf.sh

This will create the configure script and Makefiles.

The next step is always: 

     ./configure

The configure script attempts to use use the C compiler specified by the CC environment variable. If not set, GNU C will be used if it is available. The CFLAGS environment variable holds options to be passed to the C compiler. If you're using Bourne-compatible shell, you may pass something like this to use a particular C compiler with optimization enabled: 

     CC=/opt/ccs/bin/cc CFLAGS=-O ./configure

To customize YAZ, the configure script also accepts a set of options. The most important are:

--prefix=prefix

Specifies installation prefix for YAZ. This is only needed if you run make install later to perform a "system" installation. The prefix is /usr/local if not specified.

--enable-tcpd

The front end server will be built using Wietse's TCP wrapper library. It allows you to allow/deny clients depending on IP number. The TCP wrapper library is often used in GNU/Linux and BSD distributions. See hosts_access(5) and tcpd(8).

--enable-threads

YAZ will be built using POSIX threads. Specifically, _REENTRANT will be defined during compilation.

--disable-shared

The make process will not create shared libraries (also known as shared objects .so). By default, shared libraries are created - equivalent to --enable-shared.

--disable-shared

The make process will not create static libraries (.a). By default, static libraries are created - equivalent to --enable-static.

--with-iconv[=prefix]

Compile YAZ with iconv library in directory prefix. By default configure will search for iconv on the system. Use this option if it doesn't find iconv. Alternatively, --without-iconv, can be used to force YAZ not to use iconv.

--with-xslt[=prefix]

Compile YAZ with libxslt in directory prefix. Use this option if you want XSLT and XML support. By default, configure will search for libxslt on the system. Use this option if libxslt is not found automatically. Alternatively, --without-xslt, can be used to force YAZ not to use libxslt.

--with-xml2[=prefix]

Compile YAZ with libxml2 in directory prefix. Use this option if you want YAZ to use XML and support SRU/Solr. By default, configure will search for libxml2 on the system. Use this option if libxml2 is not found automatically. Alternatively, --without-xml2, can be used to force YAZ not to use libxml2.

Note that option --with-xslt also enables libxml2.

--with-gnutls[=prefix]

YAZ will be linked with the GNU TLS libraries and an SSL COMSTACK will be provided. By default configure enables SSL support for YAZ if the GNU TLS development libraries are found on the system.

--with-icu[=prefix]

YAZ will be linked the ICU library in the prefix if given. If prefix is not given, the libraries exposed by the script icu-config will be used if found.

--with-memcached

YAZ will be linked with libMemcached to allow for result-set caching for ZOOM. The prefix can not be given. Note that 0.40 of libmemcached is required.

--with-redis

YAZ will be linked with the hiredis C library to allow for result-set caching for ZOOM on a redis server. The prefix can not be given.

When configured, build the software by typing: 

      make

The following files are generated by the make process:

src/libyaz.la

Main YAZ library. This is no ordinary library. It's a Libtool archive. By default, YAZ creates a static library in lib/.libs/libyaz.a.

src/libyaz_server.la

Generic Frontend server. This is an add-on for libyaz.la. Code in this library uses POSIX threads functions - if POSIX threads are available on the platform.

src/libyaz_icu.la

Functions that wrap the ICU library.

ztest/yaz-ztest

Test Z39.50 server.

client/yaz-client

Z39.50 client for testing the protocol. See chapter YAZ client for more information.

util/yaz-config

A Bourne-shell script, generated by configure, that specifies how external applications should compile - and link with YAZ.

util/yaz-asncomp

The ASN.1 compiler for YAZ. Requires the Tcl Shell, tclsh, in PATH to operate.

util/yaz-iconv

This program converts data in one character set to another. This command exercises the YAZ character set conversion API.

util/yaz-marcdump

This program parses ISO2709 encoded MARC records and prints them in line-format or XML.

util/yaz-icu

This program exposes the ICU wrapper library if that is enabled for YAZ. Only if ICU is available this program is useful.

util/yaz-url

This program is a simple HTTP page fetcher ala wget or curl.

zoom/zoomsh

A simple shell implemented on top of the ZOOM functions. The shell is a command line application that allows you to enter simple commands to perform ZOOM operations.

zoom/zoomtst1, zoom/zoomtst2, ..

Several small applications that demonstrate the ZOOM API.

If you wish to install YAZ in system directories /usr/local/bin, /usr/local/lib .. etc, you can type: 

     make install

You probably need to have root access in order to perform this. You must specify the --prefix option for configure if you wish to install YAZ in other directories than the default /usr/local/.

If you wish to perform an un-installation of YAZ, use: 

     make uninstall

This will only work if you haven't reconfigured YAZ (and therefore changed installation prefix). Note that uninstall will not remove directories created by make install, e.g. /usr/local/include/yaz.

2.2. Compiling from source on macOS

Install Apple's Xcode Command Line Tools (XCLT) package from Apple Developer which provides necessary tools for building C/C++ programs on macOS. You can also try to install it from the command line with: 

         xcode-select --install

Out of the box, XCLT is sufficient for compiling basic YAZ from the source distribution tarball with XML support as it includes libxml2 and libxslt development headers.

For ICU support, you can fetch Apple's source distribution from GitHub: 

         git clone https://github.com/apple-oss-distributions/ICU.git

and compile YAZ with: 

         export ICU_CPPFLAGS="-DYAZ_HAVE_ICU=1 -I../../ICU/icu/icu4c/source/common -I../../ICU/icu/icu4c/source/i18n"
         export ICU_LIBS=" -licucore"
         ./configure
         make

For SSL support, YAZ requires GnuTLS and cannot be compiled with LibreSSL/OpenSSL shipped with macOS (see below).

If you are compiling YAZ from a Git checkout, at the time of writing XCLT includes GNU Bison v2.3 which is too old to generate YAZ sources. You can use e.g. Homebrew to install a more recent version: 

         brew install bison

After installation make sure to put it on the path: 

         export PATH="/opt/homebrew/opt/bison/bin:$PATH"

Note: XCLT 15.4 fails to make gm4 available as m4 which can cause a silent Bison failure, one way to fix it is: 

         sudo ln -s /Library/Developer/CommandLineTools/usr/bin/gm4 \
           /Library/Developer/CommandLineTools/usr/bin/m4

Additionally, you will need to install DocBook stylesheets to generate documentation: 

         brew install docbook docbook-xsl

per the caveats section (brew info docbook), for the compilation to find them, add: 

         export XML_CATALOG_FILES="/opt/homebrew/etc/xml/catalog"

To compile YAZ with SSL support, install GnuTLS with: 

         brew install gnutls

Homebrew makes GnuTLS discoverable by pkg-config, so no additional flags are needed when configuring YAZ. You may also want to compile YAZ with Homebrew's ICU: 

         brew install icu4c

but make sure to add compiler flags before the configure stage, per the caveats section (brew info icu4c): 

         export LDFLAGS="-L/opt/homebrew/opt/icu4c/lib"
         export CPPFLAGS="-I/opt/homebrew/opt/icu4c/include"
         export PKG_CONFIG_PATH="/opt/homebrew/opt/icu4c/lib/pkgconfig"

Additionally, if you want to compile YAZ with a more recent version of libxml2 and libxslt, you can install them with Homebrew: 

         brew install libxml2 libxslt

and, again, make sure to add compiler flags, per the caveats section (brew info libxml2): 

         export PATH="/opt/homebrew/opt/bison/bin:\
         /opt/homebrew/opt/libxml2/bin:\
         /opt/homebrew/opt/libxslt/bin:\
         $PATH"
         export LDFLAGS="-L/opt/homebrew/opt/libxml2/lib \
         -L/opt/homebrew/opt/libxslt/lib \
         -L/opt/homebrew/opt/icu4c/lib"
         export CPPFLAGS="-I/opt/homebrew/opt/libxml2/include \
         -I/opt/homebrew/opt/libxslt/include \
         -I/opt/homebrew/opt/icu4c/include"
         export PKG_CONFIG_PATH="/opt/homebrew/opt/libxml2/lib/pkgconfig:\
         /opt/homebrew/opt/libxslt/lib/pkgconfig:\
         /opt/homebrew/opt/icu4c/lib/pkgconfig"

Then configure and conpile with: 

         ./configure
         make

2.3. How to make apps using YAZ on UNIX

This section describes how to compile - and link your own applications using the YAZ toolkit. If you're used to Makefiles this shouldn't be hard. As for other libraries you have used before, you need to set a proper include path for your C/C++ compiler and specify the location of YAZ libraries. You can do it by hand, but generally we suggest you use the yaz-config that is generated by configure. This is especially important if you're using the threaded version of YAZ which require you to pass more options to your linker/compiler.

The yaz-config script accepts command line options that makes the yaz-config script print options that you should use in your make process. The most important ones are: --cflags, --libs which prints C compiler flags, and linker flags respectively.

A small and complete Makefile for a C application consisting of one source file, myprog.c, may look like this: 

      YAZCONFIG=/usr/local/bin/yaz-config
      CFLAGS=`$(YAZCONFIG) --cflags`
      LIBS=`$(YAZCONFIG) --libs`
      myprog: myprog.o
         $(CC) $(CFLAGS) -o myprog myprog.o $(LIBS)

The CFLAGS variable consists of a C compiler directive that will set the include path to the parent directory of yaz. That is, if YAZ header files were installed in /usr/local/include/yaz, then include path is set to /usr/local/include. Therefore, in your applications you should use 

      #include <yaz/proto.h>

and not 

      #include <proto.h>

For Libtool users, the yaz-config script provides a different variant of option --libs, called --lalibs that returns the name of the Libtool archive(s) for YAZ rather than the ordinary ones.

For applications using the threaded version of YAZ, specify threads after the other options. When threads is given, more flags and linker flags will be printed by yaz-config. If our previous example was using threads, you'd have to modify the lines that set CFLAGS and LIBS as follows: 

      CFLAGS=`$(YAZCONFIG) --cflags threads`
      LIBS=`$(YAZCONFIG) --libs threads`

There is no need specify POSIX thread libraries in your Makefile. The LIBS variable includes that as well.

Prev Up Next
Chapter 2. Compilation and Installation Home 3. Windows
yaz-5.37.0/doc/indexdata.html0000644000175000017500000000536115130444232014436 0ustar00adamadamAppendix E. About Index Data
Appendix E. About Index Data
Prev   Next

Appendix E. About Index Data

Index Data is a consulting and software-development enterprise that specializes in library and information management systems. Our interests and expertise span a broad range of related fields, and one of our primary, long-term objectives is the development of a powerful information management system with open network interfaces and hyper-media capabilities.

We make this software available free of charge, on a fairly unrestrictive license; as a service to the networking community, and to further the development of quality software for open network communication.

We'll be happy to answer questions about the software, and about ourselves in general.

The Hacker's Jargon File has the following to say about the use of the prefix "YA" in the name of a software product.

[ Yet Another. adj. 1. Of your own work: A humorous allusion often used in titles to acknowledge that the topic is not original, though the content is. As in "Yet Another AI Group" or "Yet Another Simulated Annealing Algorithm". 2. Of others' work: Describes something of which there are already far too many. ]

Prev   Next
Appendix D. License Home Appendix F. Credits
yaz-5.37.0/doc/yaz-illclient.10000644000175000017500000000426115130444227014453 0ustar00adamadam'\" t .\" Title: yaz-illclient .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-ILLCLIENT" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-illclient \- ILL client .SH "SYNOPSIS" .HP \w'\fByaz\-illclient\fR\ 'u \fByaz\-illclient\fR [\fB\-f\ \fR\fB\fIfilename\fR\fR] [\fB\-v\ \fR\fB\fIloglevel\fR\fR] [\fB\-D\fR\ \fIname=value\fR...] [\fB\-o\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-p\ \fR\fB\fIpassword\fR\fR] [\fB\-V\fR] [server\-addr] .SH "DESCRIPTION" .PP \fByaz\-illclient\fR is a client which sends an ISO ILL request to a remote server and decodes the response from it\&. Exactly one server address ( \fIserver\-addr\fR ) must be specified\&. .SH "OPTIONS" .PP \-f \fIfilename\fR] .RS 4 Specify filename\&. .RE .PP \-v \fIloglevel\fR] .RS 4 Specify the log level\&. .RE .PP \-D \fIname=value\fR] .RS 4 Defines name & value pair\&. .RE .PP \-o .RS 4 Enable OCLC authentication\&. .RE .PP \-u \fIuser\fR] .RS 4 Specify user\&. .RE .PP \-p \fIpassword\fR] .RS 4 Specify password\&. .RE .PP \-V .RS 4 Show yaz\-illclient version\&. .RE .SH "EXAMPLES" .PP None yet\&. .SH "FILES" .PP None yet\&. .SH "SEE ALSO" .PP yaz(7) .SH "AUTHORS" .PP \fBIndex Data\fR yaz-5.37.0/doc/server.main.html0000644000175000017500000002050515130444232014723 0ustar00adamadam4. Your main() Routine
4. Your main() Routine
Prev Chapter 4. Generic server Next

4. Your main() Routine

As mentioned, your main() routine can be quite brief. If you want to initialize global parameters, or read global configuration tables, this is the place to do it. At the end of the routine, you should call the function 

int statserv_main(int argc, char **argv,
                  bend_initresult *(*bend_init)(bend_initrequest *r),
                  void (*bend_close)(void *handle));

The third and fourth arguments are pointers to handlers. Handler bend_init is called whenever the server receives an Initialize Request, so it serves as a Z39.50 session initializer. The bend_close handler is called when the session is closed.

statserv_main will establish listening sockets according to the parameters given. When connection requests are received, the event handler will typically fork() and create a sub-process to handle a new connection. Alternatively the server may be setup to create threads for each connection. If you do use global variables and forking, you should be aware, then, that these cannot be shared between associations, unless you explicitly disable forking by command line parameters.

The server provides a mechanism for controlling some of its behavior without using command-line options. The function 

    statserv_options_block *statserv_getcontrol(void);

will return a pointer to a struct statserv_options_block describing the current default settings of the server. The structure contains these elements:

int dynamic

A boolean value, which determines whether the server will fork on each incoming request (TRUE), or not (FALSE). Default is TRUE. This flag is only read by UNIX-based servers (WIN32-based servers do not fork).

int threads

A boolean value, which determines whether the server will create a thread on each incoming request (TRUE), or not (FALSE). Default is FALSE. This flag is only read by UNIX-based servers that offer POSIX Threads support. WIN32-based servers always operate in threaded mode.

int inetd

A boolean value, which determines whether the server will operate under a UNIX INET daemon (inetd). Default is FALSE.

char logfile[ODR_MAXNAME+1]

File for diagnostic output ("": stderr).

char apdufile[ODR_MAXNAME+1]

Name of file for logging incoming and outgoing APDUs ("": don't log APDUs, "-": stderr).

char default_listen[1024]

Same form as the command-line specification of listener address. "": no default listener address. Default is to listen at "tcp:@:9999". You can only specify one default listener address in this fashion.

enum oid_proto default_proto;

Either PROTO_Z3950 or PROTO_SR. Default is PROTO_Z39_50.

int idle_timeout;

Maximum session idle-time, in minutes. Zero indicates no (infinite) timeout. Default is 15 minutes.

int maxrecordsize;

Maximum permissible record (message) size. Default is 64 MB. This amount of memory will only be allocated if a client requests a very large amount of records in one operation (or a big record). Set it to a lower number if you are worried about resource consumption on your host system.

char configname[ODR_MAXNAME+1]

Passed to the backend when a new connection is received.

char setuid[ODR_MAXNAME+1]

Set user id to the user specified, after binding the listener addresses.

void (*bend_start)(struct statserv_options_block *p)

Pointer to function which is called after the command line options have been parsed - but before the server starts listening. For forked UNIX servers, this handler is called in the mother process; for threaded servers, this handler is called in the main thread. The default value of this pointer is NULL in which case it isn't invoked by the frontend server. When the server operates as an NT service, this handler is called whenever the service is started.

void (*bend_stop)(struct statserv_options_block *p)

Pointer to function which is called whenever the server has stopped listening for incoming connections. This function pointer has a default value of NULL in which case it isn't called. When the server operates as an NT service, this handler is called whenever the service is stopped.

void *handle

User defined pointer (default value NULL). This is a per-server handle that can be used to specify "user-data". Do not confuse this with the session-handle as returned by bend_init.

The pointer returned by statserv_getcontrol points to a static area. You are allowed to change the contents of the structure, but the changes will not take effect until you call 

void statserv_setcontrol(statserv_options_block *block);

Note

You should generally update this structure before calling statserv_main().

Prev Up Next
3. The Backend API Home 5. The Backend Functions
yaz-5.37.0/doc/yaz-marcdump-man.xml0000644000175000017500000002136215123757344015527 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-marcdump 1 Commands yaz-marcdump MARC record dump utility yaz-marcdump file DESCRIPTION yaz-marcdump reads MARC records from one or more files. It parses each record and supports output in line-format, ISO2709, MARCXML, MARC-in-JSON, MarcXchange as well as Hex output. This utility parses records ISO2709(raw MARC), line format, MARC-in-JSON format as well as XML if that is structured as MARCXML/MarcXchange. MARC-in-JSON encoding/decoding is supported in YAZ 5.0.5 and later. As of YAZ 2.1.18, OAI-MARC is no longer supported. OAI-MARC is deprecated. Use MARCXML instead. By default, each record is written to standard output in a line format with newline for each field, $x for each sub-field x. The output format may be changed with option -o, yaz-marcdump can also be requested to perform character set conversion of each record. OPTIONS -i format Specifies input format. Must be one of marcxml, marc (ISO2709), marcxchange (ISO25577), line (line mode MARC), turbomarc (Turbo MARC), or json (MARC-in-JSON). -o format Specifies output format. Must be one of marcxml, marc (ISO2709), marcxchange (ISO25577), line (line mode MARC), turbomarc (Turbo MARC), or json (MARC-in-JSON). -f from Specify the character set of the input MARC record. Should be used in conjunction with option -t. Refer to the yaz-iconv man page for supported character sets. -t to Specify the character set of the output. Should be used in conjunction with option -f. Refer to the yaz-iconv man page for supported character sets. -l leaderspec Specify a simple modification string for MARC leader. The leaderspec is a list of pos=value pairs, where pos is an integer offset (0 - 23) for leader. Value is either a quoted string or an integer (character value in decimal). Pairs are comma separated. For example, to set leader at offset 9 to a, use 9='a'. -s prefix Writes a chunk of records to a separate file with prefix given, i.e. splits a record batch into files with only at most "chunk" ISO2709 records per file. By default chunk is 1 (one record per file). See option -C. -C chunksize Specifies chunk size; to be used conjunction with option -s. -O offset Integer offset for at what position records whould be written. 0=first record, 1=second, .. With -L option, this allows a specific range of records to be processed. -L limit Integer limit for how many records should at most be written. With -O option, this allows a specific range of records to be processed. -p Makes yaz-marcdump print record number and input file offset of each record read. -n MARC output is omitted so that MARC input is only checked. -r Writes to stderr a summary about number of records read by yaz-marcdump. -v Writes more information about the parsing process. Useful if you have ill-formatted ISO2709 records as input. -V Prints YAZ version. EXAMPLES The following command converts MARC21/USMARC in MARC-8 encoding to MARC21/USMARC in UTF-8 encoding. Leader offset 9 is set to 'a'. Both input and output records are ISO2709 encoded. yaz-marcdump -f MARC-8 -t UTF-8 -o marc -l 9=97 marc21.raw >marc21.utf8.raw The same records may be converted to MARCXML instead in UTF-8: yaz-marcdump -f MARC-8 -t UTF-8 -o marcxml marc21.raw >marcxml.xml Turbo MARC is a compact XML notation with same semantics as MARCXML, but which allows for faster processing via XSLT. In order to generate Turbo MARC records encoded in UTF-8 from MARC21 (ISO), one could use: yaz-marcdump -f MARC8 -t UTF8 -o turbomarc -i marc marc21.raw >out.xml FILES prefix/bin/yaz-marcdump prefix/include/yaz/marcdisp.h SEE ALSO yaz 7 yaz-iconv 1 yaz-5.37.0/doc/yaz.70000644000175000017500000000742615130444225012510 0ustar00adamadam'\" t .\" Title: yaz .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Conventions and miscellaneous .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ" "7" "01/10/2026" "YAZ 5.37.0" "Conventions and miscellaneous" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz \- Z39\&.50 toolkit\&. .SH "DESCRIPTION" .PP YAZ is a C/C++ programmer\*(Aqs toolkit supporting the development of Z39\&.50v3 clients and servers\&. The YAZ toolkit offers several different levels of access to the ISO23950/Z39\&.50, SRU Solr (client only) and ILL protocols\&. The level that you need to use depends on your requirements, and the role (server or client) that you want to implement\&. .SH "COPYRIGHT" .PP Copyright \(co 1995\-2026 Index Data\&. .PP All rights reserved\&. .PP Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Neither the name of Index Data nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission\&. .RE .PP THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS\*(Aq\*(Aq AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED\&. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE\&. .SH "SEE ALSO" .PP \fByaz-client\fR(1), \fByaz-ztest\fR(8), \fByaz-config\fR(8), \fBzoomsh\fR(1) \fBbib1-attr\fR(7) .PP YAZ manual ( /usr/share/doc/yaz) .PP \m[blue]\fBYAZ home page\fR\m[]\&\s-2\u[1]\d\s+2\&. .PP \m[blue]\fBZ39\&.50 Maintenance Agency Page\fR\m[]\&\s-2\u[2]\d\s+2\&. .SH "AUTHORS" .PP \fBIndex Data\fR .SH "NOTES" .IP " 1." 4 YAZ home page .RS 4 \%https://www.indexdata.com/yaz .RE .IP " 2." 4 Z39.50 Maintenance Agency Page .RS 4 \%https://www.loc.gov/z3950/agency/ .RE yaz-5.37.0/doc/zoom.html0000644000175000017500000006211115130444232013455 0ustar00adamadamChapter 3. ZOOM
Chapter 3. ZOOM
Prev   Next

Chapter 3. ZOOM

Table of Contents

1. Connections
1.1. Z39.50 Protocol behavior
1.2. SRU/Solr Protocol behavior
2. Queries
3. Result sets
3.1. Z39.50 Result-set Sort
3.2. Z39.50 Protocol behavior
3.3. SRU Protocol behavior
4. Records
4.1. Z39.50 Protocol behavior
4.2. SRU/Solr Protocol behavior
5. ZOOM Facets
6. Scan
7. Extended Services
7.1. Item Order
7.2. Record Update
7.3. Database Create
7.4. Database Drop
7.5. Commit Operation
7.6. Protocol behavior
8. Options
9. Query conversions
10. Events

ZOOM is an acronym for 'Z39.50 Object-Orientation Model' and is an initiative started by Mike Taylor (Mike is from the UK, which explains the peculiar name of the model). The goal of ZOOM is to provide a common Z39.50 client API not bound to a particular programming language or toolkit.

From YAZ version 2.1.12, SRU is supported. You can make SRU ZOOM connections by specifying scheme http:// for the hostname for a connection. The dialect of SRU used is specified by the value of the connection's sru option, which may be SRU over HTTP GET (get), SRU over HTTP POST (post), (SRU over SOAP) (soap) or solr (Solr Web Service). Using the facility for embedding options in target strings, a connection can be forced to use SRU rather the SRW (the default) by prefixing the target string with sru=get,, like this: sru=get,http://sru.miketaylor.org.uk:80/sru.pl

Solr protocol support was added to YAZ in version 4.1.0, as a dialect of a SRU protocol, since both are HTTP based protocols.

The lack of a simple Z39.50 client API for YAZ has become more and more apparent over time. So when the first ZOOM specification became available, an implementation for YAZ was quickly developed. For the first time, it is now as easy (or easier!) to develop clients as it is to develop servers with YAZ. This chapter describes the ZOOM C binding. Before going further, please reconsider whether C is the right programming language for the job. There are other language bindings available for YAZ, and still more are in active development. See the ZOOM web-site for more information.

In order to fully understand this chapter you should read and try the example programs zoomtst1.c, zoomtst2.c, .. in the zoom directory.

The C language misses features found in object oriented languages such as C++, Java, etc. For example, you'll have to manually, destroy all objects you create, even though you may think of them as temporary. Most objects have a _create - and a _destroy variant. All objects are in fact pointers to internal stuff, but you don't see that because of typedefs. All destroy methods should gracefully ignore a NULL pointer.

In each of the sections below you'll find a sub section called protocol behavior, that describes how the API maps to the Z39.50 protocol.

1. Connections

The Connection object is a session with a target. 

    #include <yaz/zoom.h>

    ZOOM_connection ZOOM_connection_new(const char *host, int portnum);

    ZOOM_connection ZOOM_connection_create(ZOOM_options options);

    void ZOOM_connection_connect(ZOOM_connection c, const char *host,
                                 int portnum);
    void ZOOM_connection_destroy(ZOOM_connection c);

Connection objects are created with either function ZOOM_connection_new or ZOOM_connection_create. The former creates and automatically attempts to establish a network connection with the target. The latter doesn't establish a connection immediately, thus allowing you to specify options before establishing network connection using the function ZOOM_connection_connect. If the port number, portnum, is zero, the host is consulted for a port specification. If no port is given, 210 is used. A colon denotes the beginning of a port number in the host string. If the host string includes a slash, the following part specifies a database for the connection.

You can prefix the host with a scheme followed by colon. The default scheme is tcp (Z39.50 protocol). The scheme http selects SRU/SOAP over HTTP by default, but can be changed with option sru.

You can prefix the scheme-qualified host-string with one or more comma-separated key=value sequences, each of which represents an option to be set into the connection structure before the protocol-level connection is forged and the initialization handshake takes place. This facility can be used to provide authentication credentials, as in host-strings such as: user=admin,password=halfAm4n,tcp:localhost:8017/db

Connection objects should be destroyed using the function ZOOM_connection_destroy. 

    void ZOOM_connection_option_set(ZOOM_connection c,
                                    const char *key, const char *val);

    void ZOOM_connection_option_setl(ZOOM_connection c,
                                     const char *key,
                                     const char *val, int len);

    const char *ZOOM_connection_option_get(ZOOM_connection c,
                                           const char *key);
    const char *ZOOM_connection_option_getl(ZOOM_connection c,
                                            const char *key,
                                            int *lenp);

The functions ZOOM_connection_option_set and ZOOM_connection_option_setl allows you to set an option given by key to the value value for the connection. For ZOOM_connection_option_set, the value is assumed to be a 0-terminated string. Function ZOOM_connection_option_setl specifies a value of a certain size (len).

Functions ZOOM_connection_option_get and ZOOM_connection_option_getl returns the value for an option given by key.

Table 3.1. ZOOM Connection Options

OptionDescriptionDefault
implementationNameName of your client none
userAuthentication user name none
groupAuthentication group name none
passwordAuthentication password. none
authenticationModeHow authentication is encoded. basic
hostTarget host. This setting is "read-only". It's automatically set internally when connecting to a target. none
proxyProxy host. If set, the logical host is encoded in the otherInfo area of the Z39.50 Init PDU with OID 1.2.840.10003.10.1000.81.1. none
clientIPClient IP. If set, is encoded in the otherInfo area of a Z39.50 PDU with OID 1.2.840.10003.10.1000.81.3. Holds the original IP addresses of a client. Is used if ZOOM is used in a gateway of some sort. none
timeoutIdle timeout which specifies how long ZOOM will wait for network I/O before giving up. Thus, the actual waiting time might be longer than this value if the target makes a chunked response and the time between each chunk arrive is less this value. For the connect+init, this is the time ZOOM will wait until receiving first byte from Init response. 30
asyncIf true (1) the connection operates in asynchronous operation which means that all calls are non-blocking except ZOOM_event. 0
maximumRecordSize Maximum size of single record. 1 MB
preferredMessageSize Maximum size of multiple records. 1 MB
lang Language for negotiation. none
charset Character set for negotiation. none
rpnCharset Client-side character conversion for RPN queries and scan terms. The input terms are converted from UTF-8 to the character set of rpnCharset. none (no conversion)
serverImplementationId Implementation ID of server. (The old targetImplementationId option is also supported for the benefit of old applications.) none
targetImplementationName Implementation Name of server. (The old targetImplementationName option is also supported for the benefit of old applications.) none
serverImplementationVersion Implementation Version of server. (The old targetImplementationVersion option is also supported for the benefit of old applications.) none
databaseNameOne or more database names separated by character plus (+), which is to be used by subsequent search requests on this Connection. Default
piggybackTrue (1) if piggyback should be used in searches; false (0) if not. 1
smallSetUpperBoundIf hits is less than or equal to this value, then target will return all records using small element set name 0
largeSetLowerBoundIf hits is greater than this value, the target will return no records. 1
mediumSetPresentNumberThis value represents the number of records to be returned as part of a search when hits is less than or equal to large set lower bound and if hits is greater than small set upper bound. 0
smallSetElementSetName The element set name to be used for small result sets. none
mediumSetElementSetName The element set name to be used for medium-sized result sets. none
init_opt_search, init_opt_present, init_opt_delSet, etc. After a successful Init, these options may be interrogated to discover whether the server claims to support the specified operations. none
sru SRU/Solr transport type. Must be either soap, get, post, or solr. soap if scheme is already http; ignored otherwise
sru_version SRU/SRW version. Should be 1.1, or 1.2. This is, prior to connect, the version to offer (highest version). And following connect (in fact first operation), holds the negotiated version with the server (same or lower version). 1.2
extraArgs Extra arguments for SRU/Solr URLs. The value must be URL encoded already.  
facets Requested or recommended facets may be given before a search is sent. The value of this setting is described in Section 8, “Facets” For inspection of the facets returned, refer to the functions described in Section 5, “ZOOM Facets”. none
apdulog If set to a true value such as "1", a log of low-level protocol packets is emitted on standard error stream. This can be very useful for debugging. 0
saveAPDU If set to a true value such as "1", a log of low-level protocol packets is saved. The log can be retrieved by reading option APDU. Setting saveAPDU always has the side effect of resetting the currently saved log. This setting is write-only. If read, NULL will be returned. It is only recognized in ZOOM_connection_option_set. 0
APDU Returns the log of protocol packets. Will be empty if logging is not enabled (see saveAPDU above). This setting is read-only. It is only recognized if used in call to ZOOM_connection_option_get or ZOOM_connection_option_getl.  
memcached If given and non-empty, libMemcached will be configured for the connection. This option is inspected by ZOOM when a connection is established. If the memcached option is given and YAZ is compiled without libMemcached support, an internal diagnostic (10018) will be thrown. libMemcached support is available for YAZ 5.0.13 or later. If this option is supplied for an earlier version of YAZ, it is ignored. The value of this option is a list options - each is of the form --name=value. Option --server=host[:port] specifies a memcached server. It may be repeated for multiple memcached servers. Option --expire=seconds sets expiry time in seconds for how long result sets are to be cached. none
redis If given and non-empty, a redis context will be created for the connection. This option is inspected by ZOOM when a connection is established. If the redis option is given and YAZ is compiled without redis support, an internal diagnostic (10018) will be thrown. redis support is available for YAZ 5.2.0 or later. If this option is supplied for an earlier version of YAZ, it is ignored. The value of this option is a set of options, similar to that of the memcached setting. At this stage only --server=host[:port] and --expire=seconds are supported. none

If either option lang or charset is set, then Character Set and Language Negotiation is in effect. 

     int ZOOM_connection_error(ZOOM_connection c, const char **cp,
                               const char **addinfo);
     int ZOOM_connection_error_x(ZOOM_connection c, const char **cp,
                                 const char **addinfo, const char **dset);

Function ZOOM_connection_error checks for errors for the last operation(s) performed. The function returns zero if no errors occurred; non-zero otherwise indicating the error. Pointers cp and addinfo holds messages for the error and additional-info if passed as non-NULL. Function ZOOM_connection_error_x is an extended version of ZOOM_connection_error that is capable of returning name of diagnostic set in dset.

1.1. Z39.50 Protocol behavior

The calls ZOOM_connection_new and ZOOM_connection_connect establishes a TCP/IP connection and sends an Initialize Request to the target if possible. In addition, the calls wait for an Initialize Response from the target and the result is inspected (OK or rejected).

If proxy is set then the client will establish a TCP/IP connection with the peer as specified by the proxy host and the hostname as part of the connect calls will be set as part of the Initialize Request. The proxy server will then "forward" the PDUs transparently to the target behind the proxy.

For the authentication parameters, if option user is set and both options group and pass are unset, then Open style authentication is used (Version 2/3) in which case the username is usually followed by a slash, then by a password. If either group or pass is set then idPass authentication (Version 3 only) is used. If none of the options are set, no authentication parameters are set as part of the Initialize Request (obviously).

When option async is 1, it really means that all network operations are postponed (and queued) until the function ZOOM_event is invoked. When doing so it doesn't make sense to check for errors after ZOOM_connection_new is called since that operation "connecting - and init" is still incomplete and the API cannot tell the outcome (yet).

1.2. SRU/Solr Protocol behavior

The HTTP based protocols (SRU, SRW, Solr) do not feature an Inititialize Request, so the connection phase merely establishes a TCP/IP connection with the HTTP server.

Most of the ZOOM connection options do not affect SRU/Solr and they are ignored. However, future versions of YAZ might honor implementationName and put that as part of User-Agent header for HTTP requests.

The charset is used in the Content-Type header of HTTP requests.

Setting authentcationMode specifies how authentication parameters are encoded for HTTP. The default is "basic" where user and password are encoded by using HTTP basic authentication.

If authentcationMode is "url", then user and password are encoded in the URL by parameters x-username and x-password as given by the SRU standard.

Prev   Next
3. Windows Home 2. Queries
yaz-5.37.0/doc/reference.html0000644000175000017500000000754715130444232014443 0ustar00adamadamReference
Reference
Prev   Next

Reference

The material in this chapter is drawn directly from the individual manual entries.

Table of Contents

yaz-client — Z39.50/SRU client for implementors
yaz-ztest — Z39.50/SRU Test Server
yaz-config — Script to get information about YAZ.
yaz — Z39.50 toolkit.
zoomsh — ZOOM shell
yaz-asncomp — YAZ ASN.1 compiler
yaz-marcdump — MARC record dump utility
yaz-iconv — YAZ Character set conversion utility
yaz-log — Log handling in all yaz-based programs
yaz-illclient — ILL client
yaz-icu — YAZ ICU utility
yaz-url — YAZ URL fetch utility
Bib-1 Attribute Set — Bib-1 Attribute Set
yaz-json-parse — YAZ JSON parser
yaz-record-iconv — YAZ Record Conversion Utility
Prev   Next
Chapter 10. Future Directions Home yaz-client
yaz-5.37.0/doc/apilayer.png0000644000175000017500000000161315123757344014134 0ustar00adamadam‰PNG  IHDRöà¾?öRIDAThíØAOA`= W¤ý †D¢zôâo úàPƒ`)ñÀ‘3)¦GOêM ¥ D¶ô€I%[ú $­FÚTv„Ýqw¶Eètv*bÙ—46ß¼yÓìL·«K ¦ój“0V‹8-‹11C f˜ñ%ï4¿s’ˆåtÔ°Ó‰§r 0*½Aéë— ¨êI^% ¾z‘…±”Mv½IâÞZĨ&%öŒ«â Ÿ´]—Ì^¥D×ÇŒØÕÍàp‰`iøä7HѶ'œÉâ“ËL³HAÌrTE,ÝPÊT„&"*ÂRy%©Ô•„¨‡«žQu±«ûTEá“‹&+§ïc?¤V6/öIEND®B`‚yaz-5.37.0/doc/comstack.ssl.html0000644000175000017500000000555415130444232015105 0ustar00adamadam7. SSL
7. SSL
Prev Chapter 9. The COMSTACK Module Next

7. SSL

     void *cs_get_ssl(COMSTACK cs);

Returns the SSL handle, SSL * for comstack. If comstack is not of type SSL, then NULL is returned. 

     int cs_set_ssl_ctx(COMSTACK cs, void *ctx);

Sets SSL context for comstack. The parameter is expected to be of type SSL_CTX *. This function should be called just after comstack has been created (before connect, bind, etc). This function returns 1 for success; 0 for failure. 

     int cs_set_ssl_certificate_file(COMSTACK cs, const char *fname);

Sets SSL certificate for comstack as a PEM file. This function returns 1 for success; 0 for failure. 

     int cs_get_ssl_peer_certificate_x509(COMSTACK cs, char **buf, int *len);

This function returns the peer certificate. If successful, *buf and *len holds X509 buffer and length respectively. Buffer should be freed with xfree. This function returns 1 for success; 0 for failure.

Prev Up Next
6. Addresses Home 8. Diagnostics
yaz-5.37.0/doc/yaz-record-iconv.html0000644000175000017500000001002715130444232015663 0ustar00adamadamyaz-record-iconv
yaz-record-iconv
Prev Reference Next

Name

yaz-record-conv — YAZ Record Conversion Utility

Synopsis

yaz-record-conv [ -v loglevel ] [config] [fname...]

DESCRIPTION

yaz-record-conv is a program that exercises the record conversion sub system. Refer to record_conv.h header.

OPTIONS

-v level
Sets the LOG level to level. Level is a sequence of tokens separated by comma. Each token is a integer or a named LOG item - one of fatal, debug, warn, log, malloc, all, none.

EXAMPLES

The following backend configuration converts MARC records (ISO2709) to Dublin-Core XML. 

    <backend name="F" syntax="usmarc">
      <marc inputcharset="marc-8" inputformat="marc" outputformat="marcxml"/>
      <xslt stylesheet="../etc/MARC21slim2DC.xsl"/>
    </backend>

We can convert one of the sample records from YAZ' test directory with: 

$ ../util/yaz-record-conv record-conv-conf.xml marc6.marc
<?xml version="1.0"?>
<dc:dc xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:title>How to program a computer</dc:title>
  <dc:creator>
    Jack Collins
  </dc:creator>
  <dc:type>text</dc:type>
  <dc:publisher>Penguin</dc:publisher>
  <dc:language>eng</dc:language>
</dc:dc>

FILES

record_conv.h

SEE ALSO

yaz(7)

Prev Up Next
yaz-json-parse Home Appendix A. List of Object Identifiers
yaz-5.37.0/doc/gfs-virtual.xml0000644000175000017500000002233415123757344014610 0ustar00adamadam The Virtual hosts mechanism allows a YAZ front-end server to support multiple back-ends. A back-end is selected on the basis of the TCP/IP binding (port+listening address) and/or the virtual host. A back-end can be configured to execute in a particular working directory. Or the YAZ front-end may perform CQL to RPN conversion, thus allowing traditional Z39.50 back-ends to be offered as a SRW/SRU service. SRW/SRU Explain information for a particular back-end may also be specified. For the HTTP protocol, the virtual host is specified in the Host header. For the Z39.50 protocol, the virtual host is specified as in the Initialize Request in the OtherInfo, OID 1.2.840.10003.10.1000.81.1. Not all Z39.50 clients allow the VHOST information to be set. For those, the selection of the back-end must rely on the TCP/IP information alone (port and address). The YAZ front-end server uses XML to describe the back-end configurations. Command-line option -f specifies filename of the XML configuration. The configuration uses the root element yazgfs. This element includes a list of listen elements, followed by one or more server elements. The listen describes listener (transport end point), such as TCP/IP, Unix file socket or SSL server. Content for a listener: CDATA (required) The CDATA for the listen element holds the listener string, such as tcp:@:210, tcp:server1:2100, etc. attribute id (optional) Identifier for this listener. This may be referred to from server sections. We expect more information to be added for the listen section in a future version, such as CERT file for SSL servers. The server describes a server and the parameters for this server type. Content for a server: attribute id (optional) Identifier for this server. Currently not used for anything, but it might be for logging purposes. attribute listenref (optional) Specifies one or more listeners for this server. Each server ID is separated by a comma. If this attribute is not given, the server is accessible from all listeners. In order for the server to be used for real, however, the virtual host must match if specified in the configuration. element config (optional) Specifies the server configuration. This is equivalent to the config specified using command line option -c. element directory (optional) Specifies a working directory for this backend server. If specified, the YAZ 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). element host (optional) Specifies the virtual host for this server. If this is specified a client must specify this host string in order to use this backend. element cql2rpn (optional) Specifies a filename that includes CQL to RPN conversion for this backend server. See &reference-tools-cql-map;. If given, the backend server will only "see" a Type-1/RPN query. element ccl2rpn (optional) Specifies a filename that includes CCL to RPN conversion for this backend server. See &reference-tools-ccl-qualifiers;. If given, the backend server will only "see" a Type-1/RPN query. element stylesheet (optional) Specifies the stylesheet reference to be part of SRU HTTP responses when the client does not specify one. If none is given, then if the client does not specify one, then no stylesheet reference is part of the SRU HTTP response. element client_query_charset (optional) If specified, a conversion from the character set given to UTF-8 is performed by the generic frontend server. It is only executed for Z39.50 search requests (SRU/Solr are assumed to be UTF-8 encoded already). element docpath (optional) Specifies a path for local file access using HTTP. All URLs with a leading prefix (/ excluded) that matches the value of docpath are used for file access. For example, if the server is to offer access in directory xsl, the docpath would be xsl and all URLs of the form http://host/xsl will result in a local file access. element explain (optional) Specifies SRW/SRU ZeeRex content for this server. Copied verbatim to the client. As things are now, some of the Explain content seem redundant because host information, etc. is also stored elsewhere. element maximumrecordsize (optional) Specifies maximum record size/message size, in bytes. This value also serves as the maximum size of incoming packages (for Record Updates etc). It's the same value as that given by the -k option. element retrievalinfo (optional) Enables the retrieval facility to support conversions and specifications of record formats/types. See for more information. The XML 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 public and the other server internal. tcp:@:9900 unix:/var/tmp/socket server1.mydomain /var/www/s1 config.cfg server2.mydomain /var/www/s2 config.cfg ../etc/pqf.properties server2.mydomain 9900 a /var/www/s3 config.cfg ]]> There are three configured backend servers. The first two servers, "server1" and "server2", can be reached by both listener addresses. "server1" is reached by all (two) since no listenref attribute is specified. "server2" is reached by the two listeners specified. In order to distinguish between the two, a virtual host has been specified for each server in the host elements. For "server2" elements for CQL to RPN conversion is supported and explain information has been added (a short one here to keep the example small). The third server, "server3" can only be reached via listener "internal". yaz-5.37.0/doc/soap.html0000644000175000017500000000511515130444232013434 0ustar00adamadamChapter 6. SOAP and SRU
Chapter 6. SOAP and SRU
Prev   Next

Chapter 6. SOAP and SRU

Table of Contents

1. Introduction
2. HTTP
3. SOAP Packages
4. SRU

1. Introduction

YAZ uses a very simple implementation of SOAP that only (currently) supports what is sufficient to offer SRU SOAP functionality. The implementation uses the tree API of libxml2 to encode and decode SOAP packages.

Like the Z39.50 ASN.1 module, the YAZ SRU implementation uses simple C structs to represent SOAP packages as well as HTTP packages.

Prev   Next
4. PDU Contents Table Home 2. HTTP
yaz-5.37.0/doc/tools.html0000644000175000017500000017721115130444232013641 0ustar00adamadamChapter 7. Supporting Tools
Chapter 7. Supporting Tools
Prev   Next

Chapter 7. Supporting Tools

Table of Contents

1. Query Syntax Parsers
1.1. Prefix Query Format
1.1.1. Using Proximity Operators with PQF
1.1.2. PQF queries
1.2. CCL
1.2.1. CCL Syntax
1.2.2. CCL Qualifiers
1.2.3. CCL API
1.3. CQL
1.3.1. CQL parsing
1.3.2. CQL tree
1.3.3. CQL to PQF conversion
1.3.4. Specification of CQL to RPN mappings
1.3.5. CQL to XCQL conversion
1.3.6. PQF to CQL conversion
2. Object Identifiers
2.1. OID database
2.2. Standard OIDs
3. Nibble Memory
4. Log
5. MARC
5.1. TurboMARC
6. Retrieval Facility
6.1. Retrieval XML format
6.2. Retrieval Facility Examples
6.3. API
7. Sorting
7.1. Using the Z39.50 sort service
7.2. Type-7 sort
8. Facets

In support of the service API - primarily the ASN module, which provides the programmatic interface to the Z39.50 APDUs, YAZ contains a collection of tools that support the development of applications.

1. Query Syntax Parsers

Since the type-1 (RPN) query structure has no direct, useful string representation, every origin application needs to provide some form of mapping from a local query notation or representation to a Z_RPNQuery structure. Some programmers will prefer to construct the query manually, perhaps using odr_malloc() to simplify memory management. The YAZ distribution includes three separate, query-generating tools that may be of use to you.

1.1. Prefix Query Format

Since RPN or reverse polish notation is really just a fancy way of describing a suffix notation format (operator follows operands), it would seem that the confusion is total when we now introduce a prefix notation for RPN. The reason is one of simple laziness - it's somewhat simpler to interpret a prefix format, and this utility was designed for maximum simplicity, to provide a baseline representation for use in simple test applications and scripting environments (like Tcl). The demonstration client included with YAZ uses the PQF.

Note

The PQF has been adopted by other parties developing Z39.50 software. It is often referred to as Prefix Query Notation - PQN.

The PQF is defined by the pquery module in the YAZ library. There are two sets of functions that have similar behavior. First set operates on a PQF parser handle, second set doesn't. First set of functions are more flexible than the second set. Second set is obsolete and is only provided to ensure backwards compatibility.

First set of functions all operate on a PQF parser handle: 

     #include <yaz/pquery.h>

     YAZ_PQF_Parser yaz_pqf_create(void);

     void yaz_pqf_destroy(YAZ_PQF_Parser p);

     Z_RPNQuery *yaz_pqf_parse(YAZ_PQF_Parser p, ODR o, const char *qbuf);

     Z_AttributesPlusTerm *yaz_pqf_scan(YAZ_PQF_Parser p, ODR o,
                          Odr_oid **attributeSetId, const char *qbuf);

     int yaz_pqf_error(YAZ_PQF_Parser p, const char **msg, size_t *off);

A PQF parser is created and destructed by functions yaz_pqf_create and yaz_pqf_destroy respectively. Function yaz_pqf_parse parses the query given by string qbuf. If parsing was successful, a Z39.50 RPN Query is returned which is created using ODR stream o. If parsing failed, a NULL pointer is returned. Function yaz_pqf_scan takes a scan query in qbuf. If parsing was successful, the function returns attributes plus term pointer and modifies attributeSetId to hold attribute set for the scan request - both allocated using ODR stream o. If parsing failed, yaz_pqf_scan returns a NULL pointer. Error information for bad queries can be obtained by a call to yaz_pqf_error which returns an error code and modifies *msg to point to an error description, and modifies *off to the offset within the last query where parsing failed.

The second set of functions are declared as follows: 

     #include <yaz/pquery.h>

     Z_RPNQuery *p_query_rpn(ODR o, oid_proto proto, const char *qbuf);

     Z_AttributesPlusTerm *p_query_scan(ODR o, oid_proto proto,
                             Odr_oid **attributeSetP, const char *qbuf);

     int p_query_attset(const char *arg);

The function p_query_rpn() takes as arguments an ODR stream (see section The ODR Module) to provide a memory source (the structure created is released on the next call to odr_reset() on the stream), a protocol identifier (one of the constants PROTO_Z3950 and PROTO_SR), an attribute set reference, and finally a null-terminated string holding the query string.

If the parse went well, p_query_rpn() returns a pointer to a Z_RPNQuery structure which can be placed directly into a Z_SearchRequest. If parsing failed, due to syntax error, a NULL pointer is returned.

The p_query_attset specifies which attribute set to use if the query doesn't specify one by the @attrset operator. The p_query_attset returns 0 if the argument is a valid attribute set specifier; otherwise the function returns -1.

The grammar of the PQF is as follows:


     query ::= top-set query-struct.

     top-set ::= [ '@attrset' string ]

     query-struct ::= attr-spec | simple | complex | '@term' term-type query

     attr-spec ::= '@attr' [ string ] string query-struct

     complex ::= operator query-struct query-struct.

     operator ::= '@and' | '@or' | '@not' | '@prox' proximity.

     simple ::= result-set | term.

     result-set ::= '@set' string.

     term ::= string.

     proximity ::= exclusion distance ordered relation which-code unit-code.

     exclusion ::= '1' | '0' | 'void'.

     distance ::= integer.

     ordered ::= '1' | '0'.

     relation ::= integer.

     which-code ::= 'known' | 'private' | integer.

     unit-code ::= integer.

     term-type ::= 'general' | 'numeric' | 'string' | 'oid' | 'datetime' | 'null'.
    

You will note that the syntax above is a fairly faithful representation of RPN, except for the Attribute, which has been moved a step away from the term, allowing you to associate one or more attributes with an entire query structure. The parser will automatically apply the given attributes to each term as required.

The @attr operator is followed by an attribute specification (attr-spec above). The specification consists of an optional attribute set, an attribute type-value pair and a sub-query. The attribute type-value pair is packed in one string: an attribute type, an equals sign, and an attribute value, like this: @attr 1=1003. The type is always an integer, but the value may be either an integer or a string (if it doesn't start with a digit character). A string attribute-value is encoded as a Type-1 "complex" attribute with the list of values containing the single string specified, and including no semantic indicators.

Version 3 of the Z39.50 specification defines various encoding of terms. Use @term type string, where type is one of: general, numeric or string (for InternationalString). If no term type has been given, the general form is used. This is the only encoding allowed in both versions 2 and 3 of the Z39.50 standard.

1.1.1. Using Proximity Operators with PQF

Note

This is an advanced topic, describing how to construct queries that make very specific requirements on the relative location of their operands. You may wish to skip this section and go straight to the example PQF queries.

Warning

Most Z39.50 servers do not support proximity searching, or support only a small subset of the full functionality that can be expressed using the PQF proximity operator. Be aware that the ability to express a query in PQF is no guarantee that any given server will be able to execute it.

The proximity operator @prox is a special and more restrictive version of the conjunction operator @and. Its semantics are described in section 3.7.2 (Proximity) of Z39.50 the standard itself, which can be read on-line at https://www.loc.gov/z3950/agency/markup/09.html#3.7.2

In PQF, the proximity operation is represented by a sequence of the form 

       @prox exclusion distance ordered relation which-code unit-code

in which the meanings of the parameters are as described in the standard, and they can take the following values:

  • exclusion.  0 = false (i.e. the proximity condition specified by the remaining parameters must be satisfied) or 1 = true (the proximity condition specified by the remaining parameters must not be satisfied).

  • distance.  An integer specifying the difference between the locations of the operands: e.g. two adjacent words would have distance=1 since their locations differ by one unit.

  • ordered.  1 = ordered (the operands must occur in the order the query specifies them) or 0 = unordered (they may appear in either order).

  • relation.  Recognised values are 1 (lessThan), 2 (lessThanOrEqual), 3 (equal), 4 (greaterThanOrEqual), 5 (greaterThan) and 6 (notEqual).

  • which-code.  known or k (the unit-code parameter is taken from the well-known list of alternatives described below) or private or p (the unit-code parameter has semantics specific to an out-of-band agreement such as a profile).

  • unit-code.  If the which-code parameter is known then the recognised values are 1 (character), 2 (word), 3 (sentence), 4 (paragraph), 5 (section), 6 (chapter), 7 (document), 8 (element), 9 (subelement), 10 (elementType) and 11 (byte). If which-code is private then the acceptable values are determined by the profile.

(The numeric values of the relation and well-known unit-code parameters are taken straight from the ASN.1 of the proximity structure in the standard.)

1.1.2. PQF queries

Example 7.1. PQF queries using simple terms

	dylan

	"bob dylan"


Example 7.2. PQF boolean operators

	@or "dylan" "zimmerman"

	@and @or dylan zimmerman when

	@and when @or dylan zimmerman


Example 7.3. PQF references to result sets

	@set Result-1

	@and @set seta @set setb


Example 7.4. Attributes for terms

	@attr 1=4 computer

	@attr 1=4 @attr 4=1 "self portrait"

	@attrset exp1 @attr 1=1 CategoryList

	@attr gils 1=2008 Copenhagen

	@attr 1=/book/title computer


Example 7.5. PQF Proximity queries

	@prox 0 3 1 2 k 2 dylan zimmerman

Here the parameters 0, 3, 1, 2, k and 2 represent exclusion, distance, ordered, relation, which-code and unit-code, in that order. So:

  • exclusion = 0: the proximity condition must hold

  • distance = 3: the terms must be three units apart

  • ordered = 1: they must occur in the order they are specified

  • relation = 2: lessThanOrEqual (to the distance of 3 units)

  • which-code is "known", so the standard unit-codes are used

  • unit-code = 2: word.

So the whole proximity query means that the words dylan and zimmerman must both occur in the record, in that order, differing in position by three or fewer words (i.e. with two or fewer words between them.) The query would find "Bob Dylan, aka. Robert Zimmerman", but not "Bob Dylan, born as Robert Zimmerman" since the distance in this case is four.


Example 7.6. PQF specification of search term type

	@term string "a UTF-8 string, maybe?"


Example 7.7. PQF mixed queries

	@or @and bob dylan @set Result-1

	@attr 4=1 @and @attr 1=1 "bob dylan" @attr 1=4 "slow train coming"

	@and @attr 2=4 @attr gils 1=2038 -114 @attr 2=2 @attr gils 1=2039 -109

The last of these examples is a spatial search: in the GILS attribute set, access point 2038 indicates West Bounding Coordinate and 2030 indicates East Bounding Coordinate, so the query is for areas extending from -114 degrees longitude to no more than -109 degrees longitude.


1.2. CCL

Not all users enjoy typing in prefix query structures and numerical attribute values, even in a minimalistic test client. In the library world, the more intuitive Common Command Language - CCL (ISO 8777) has enjoyed some popularity - especially before the widespread availability of graphical interfaces. It is still useful in applications where you for some reason or other need to provide a symbolic language for expressing boolean query structures.

1.2.1. CCL Syntax

The CCL parser obeys the following grammar for the FIND argument. The syntax is annotated using lines prefixed by --. 

      CCL-Find ::= CCL-Find Op Elements
                | Elements.

      Op ::= "and" | "or" | "not"
      -- The above means that Elements are separated by boolean operators.

      Elements ::= '(' CCL-Find ')'
                | Set
                | Terms
                | Qualifiers Relation Terms
                | Qualifiers Relation '(' CCL-Find ')'
                | Qualifiers '=' string '-' string
      -- Elements is either a recursive definition, a result set reference, a
      -- list of terms, qualifiers followed by terms, qualifiers followed
      -- by a recursive definition or qualifiers in a range (lower - upper).

      Set ::= 'set' = string
      -- Reference to a result set

      Terms ::= Terms Prox Term
             | Term
      -- Proximity of terms.

      Term ::= Term string
            | string
      -- This basically means that a term may include a blank

      Qualifiers ::= Qualifiers ',' string
                  | string
      -- Qualifiers is a list of strings separated by comma

      Relation ::= '=' | '>=' | '<=' | '<>' | '>' | '<'
      -- Relational operators. This really doesn't follow the ISO8777
      -- standard.

      Prox ::= '%' | '!'
      -- Proximity operator

Example 7.8. CCL queries

The following queries are all valid: 

       dylan

       "bob dylan"

       dylan or zimmerman

       set=1

       (dylan and bob) or set=1

       righttrunc?

       "notrunc?"

       singlechar#mask

Assuming that the qualifiers ti and au and date are defined, we may use: 

       ti=self portrait

       au=(bob dylan and slow train coming)

       date>1980 and (ti=((self portrait)))

1.2.2. CCL Qualifiers

Qualifiers are used to direct the search to a particular searchable index, such as title (ti) and author indexes (au). The CCL standard itself doesn't specify a particular set of qualifiers, but it does suggest a few short-hand notations. You can customize the CCL parser to support a particular set of qualifiers to reflect the current target profile. Traditionally, a qualifier would map to a particular use-attribute within the BIB-1 attribute set. It is also possible to set other attributes, such as the structure attribute.

A CCL profile is a set of predefined CCL qualifiers that may be read from a file or set in the CCL API. The YAZ client reads its CCL qualifiers from a file named default.bib. There are four types of lines in a CCL profile: qualifier specification, qualifier alias, comments and directives.

1.2.2.1. Qualifier specification

A qualifier specification is of the form:

qualifier-name [attributeset,]type=val [attributeset,]type=val ...

where qualifier-name is the name of the qualifier to be used (e.g. ti), type is attribute type in the attribute set (Bib-1 is used if no attribute set is given) and val is attribute value. The type can be specified as an integer, or as a single-letter: u for use, r for relation, p for position, s for structure,t for truncation, or c for completeness. The attributes for the special qualifier name term are used when no CCL qualifier is given in a query.

Table 7.1. Common Bib-1 attributes

TypeDescription
u=value Use attribute (1). Common use attributes are 1 Personal-name, 4 Title, 7 ISBN, 8 ISSN, 30 Date, 62 Subject, 1003 Author, 1016 Any. Specify value as an integer.
r=value Relation attribute (2). Common values are 1 <, 2 <=, 3 =, 4 >=, 5 >, 6 <>, 100 phonetic, 101 stem, 102 relevance, 103 always matches.
p=value Position attribute (3). Values: 1 first in field, 2 first in any subfield, 3 any position in field.
s=value Structure attribute (4). Values: 1 phrase, 2 word, 3 key, 4 year, 5 date, 6 word list, 100 date (un), 101 name (norm), 102 name (un), 103 structure, 104 urx, 105 free-form-text, 106 document-text, 107 local-number, 108 string, 109 numeric string.
t=value Truncation attribute (5). Values: 1 right, 2 left, 3 left and right, 100 none, 101 process #, 102 regular-1, 103 regular-2, 104 CCL.
c=value Completeness attribute (6). Values: 1 incomplete subfield, 2 complete subfield, 3 complete field.


Refer to Bib-1 Attribute Set(7) or the complete list of Bib-1 attributes

It is also possible to specify non-numeric attribute values, which are used in combination with certain types. The special combinations are:

Table 7.2. Special attribute combos

NameDescription
s=pw The structure is set to either word or phrase depending on the number of tokens in a term (phrase-word).
s=al Each token in the term is ANDed (and-list). This does not set the structure at all.
s=ol Each token in the term is ORed (or-list). This does not set the structure at all.
s=ag Tokens that appears as phrases (with blank in them) gets structure phrase attached (4=1). Tokens that appear to be words gets structure word attached (4=2). Phrases and words are ANDed. This is a variant of s=al and s=pw, with the main difference that words are not split (with operator AND) but instead kept in one RPN token. This facility appeared in YAZ 4.2.38.
s=sl Tokens are split into sub-phrases of all combinations - in order. This facility appeared in YAZ 5.14.0.
r=o Allows ranges and the operators greater-than, less-than, ... equals. This sets Bib-1 relation attribute accordingly (relation ordered). A query construct is only treated as a range if dash is used and that is surrounded by white-space. So -1980 is treated as term "-1980" not <= 1980. If - 1980 is used, however, that is treated as a range.
r=r Similar to r=o but assumes that terms are non-negative (not prefixed with -). Thus, a dash will always be treated as a range. The construct 1980-1990 is treated as a range with r=r but as a single term "1980-1990" with r=o. The special attribute r=r is available in YAZ 2.0.24 or later.
r=omiteq This will omit relation=equals (@attr 2=3) when r=o / r=r is used. This is useful for servers that somehow break when an explicit relation=equals is used. Omitting the relation is usually safe because "equals" is the default behavior. This tweak was added in YAZ version 5.1.2.
t=l Allows term to be left-truncated. If term is of the form ?x, the resulting Type-1 term is x and truncation is left.
t=r Allows term to be right-truncated. If term is of the form x?, the resulting Type-1 term is x and truncation is right.
t=n If term is does not include ?, the truncation attribute is set to none (100).
t=b Allows term to be both left-and-right truncated. If term is of the form ?x?, the resulting term is x and truncation is set to both left and right.
t=x Allows masking anywhere in a term, thus fully supporting # (mask one character) and ? (zero or more of any). If masking is used, truncation is set to 102 (regexp-1 in term) and the term is converted accordingly to a regular expression.
t=z Allows masking anywhere in a term, thus fully supporting # (mask one character) and ? (zero or more of any). If masking is used, truncation is set to 104 (Z39.58 in term) and the term is converted accordingly to Z39.58 masking term - actually the same truncation as CCL itself.


Example 7.9. CCL profile

Consider the following definition: 

	ti       u=4 s=1
	au       u=1 s=1
	term     s=105
	ranked   r=102
	date     u=30 r=o

ti and au both set structure attribute to phrase (s=1). ti sets the use-attribute to 4. au sets the use-attribute to 1. When no qualifiers are used in the query, the structure-attribute is set to free-form-text (105) (rule for term). The date sets the relation attribute to the relation used in the CCL query and sets the use attribute to 30 (Bib-1 Date).

You can combine attributes. To Search for "ranked title" you can do 

	 ti,ranked=knuth computer

which will set relation=ranked, use=title, structure=phrase.

Query 

	 date > 1980

is a valid query. But 

	 ti > 1980

is invalid.


1.2.2.2. Qualifier alias

A qualifier alias is of the form:

q q1 q2 ..

which declares q to be an alias for q1, q2... such that the CCL query q=x is equivalent to q1=x or q2=x or ....

1.2.2.3. Comments

Lines with white space or lines that begin with character # are treated as comments.

1.2.2.4. Directives

Directive specifications takes the form

@directive value

Table 7.3. CCL directives

NameDescriptionDefault
truncationTruncation character?
maskMasking character. Requires YAZ 4.2.58 or later#
fieldSpecifies how multiple fields are to be combined. There are two modes: or: multiple qualifier fields are ORed, merge: attributes for the qualifier fields are merged and assigned to one term. merge
caseSpecifies if CCL operators and qualifiers should be compared with case sensitivity or not. Specify 1 for case sensitive; 0 for case insensitive.1
andSpecifies token for CCL operator AND.and
orSpecifies token for CCL operator OR.or
notSpecifies token for CCL operator NOT.not
setSpecifies token for CCL operator SET.set

1.2.3. CCL API

All public definitions can be found in the header file ccl.h. A profile identifier is of type CCL_bibset. A profile must be created with the call to the function ccl_qual_mk which returns a profile handle of type CCL_bibset.

To read a file containing qualifier definitions the function ccl_qual_file may be convenient. This function takes an already opened FILE handle pointer as argument along with a CCL_bibset handle.

To parse a simple string with a FIND query use the function 

struct ccl_rpn_node *ccl_find_str(CCL_bibset bibset, const char *str,
                                  int *error, int *pos);

which takes the CCL profile (bibset) and query (str) as input. Upon successful completion the RPN tree is returned. If an error occurs, such as a syntax error, the integer pointed to by error holds the error code and pos holds the offset inside query string in which the parsing failed.

An English representation of the error may be obtained by calling the ccl_err_msg function. The error codes are listed in ccl.h.

To convert the CCL RPN tree (type struct ccl_rpn_node *) to the Z_RPNQuery of YAZ the function ccl_rpn_query must be used. This function which is part of YAZ is implemented in yaz-ccl.c. After calling this function the CCL RPN tree is probably no longer needed. The ccl_rpn_delete destroys the CCL RPN tree.

A CCL profile may be destroyed by calling the ccl_qual_rm function.

The token names for the CCL operators may be changed by setting the globals (all type char *) ccl_token_and, ccl_token_or, ccl_token_not and ccl_token_set. An operator may have aliases, i.e. there may be more than one name for the operator. To do this, separate each alias with a space character.

1.3. CQL

CQL - Common Query Language - was defined for the SRU protocol. In many ways CQL has a similar syntax to CCL. The objective of CQL is different. Where CCL aims to be an end-user language, CQL is the protocol query language for SRU.

Tip

If you are new to CQL, read the Gentle Introduction.

The CQL parser in YAZ provides the following:

  • It parses and validates a CQL query.

  • It generates a C structure that allows you to convert a CQL query to some other query language, such as SQL.

  • The parser converts a valid CQL query to PQF, thus providing a way to use CQL for both SRU servers and Z39.50 targets at the same time.

  • The parser converts CQL to XCQL. XCQL is an XML representation of CQL. XCQL is part of the SRU specification. However, since SRU supports CQL only, we don't expect XCQL to be widely used. Furthermore, CQL has the advantage over XCQL that it is easy to read.

1.3.1. CQL parsing

A CQL parser is represented by the CQL_parser handle. Its contents should be considered YAZ internal (private). 

#include <yaz/cql.h>

typedef struct cql_parser *CQL_parser;

CQL_parser cql_parser_create(void);
void cql_parser_destroy(CQL_parser cp);

A parser is created by cql_parser_create and is destroyed by cql_parser_destroy.

To parse a CQL query string, the following function is provided: 

int cql_parser_string(CQL_parser cp, const char *str);

A CQL query is parsed by the cql_parser_string which takes a query str. If the query was valid (no syntax errors), then zero is returned; otherwise -1 is returned to indicate a syntax error. 

int cql_parser_stream(CQL_parser cp,
                      int (*getbyte)(void *client_data),
                      void (*ungetbyte)(int b, void *client_data),
                      void *client_data);

int cql_parser_stdio(CQL_parser cp, FILE *f);

The functions cql_parser_stream and cql_parser_stdio parse a CQL query - just like cql_parser_string. The only difference is that the CQL query can be fed to the parser in different ways. The cql_parser_stream uses a generic byte stream as input. The cql_parser_stdio uses a FILE handle which is opened for reading.

1.3.2. CQL tree

If the query string is valid, the CQL parser generates a tree representing the structure of the CQL query. 

struct cql_node *cql_parser_result(CQL_parser cp);

cql_parser_result returns a pointer to the root node of the resulting tree.

Each node in a CQL tree is represented by a struct cql_node. It is defined as follows: 

#define CQL_NODE_ST 1
#define CQL_NODE_BOOL 2
#define CQL_NODE_SORT 3
struct cql_node {
    int which;
    union {
        struct {
            char *index;
	    char *index_uri;
            char *term;
            char *relation;
	    char *relation_uri;
            struct cql_node *modifiers;
        } st;
        struct {
            char *value;
            struct cql_node *left;
            struct cql_node *right;
            struct cql_node *modifiers;
        } boolean;
        struct {
            char *index;
            struct cql_node *next;
            struct cql_node *modifiers;
            struct cql_node *search;
        } sort;
    } u;
};

There are three node types: search term (ST), boolean (BOOL) and sortby (SORT). A modifier is treated as a search term too.

The search term node has five members:

  • index: index for search term. If an index is unspecified for a search term, index will be NULL.

  • index_uri: index URI for search term or NULL if none could be resolved for the index.

  • term: the search term itself.

  • relation: relation for search term.

  • relation_uri: relation URI for search term.

  • modifiers: relation modifiers for search term. The modifiers list itself of cql_nodes each of type ST.

The boolean node represents and, or, not + proximity.

  • left and right: left - and right operand respectively.

  • modifiers: proximity arguments.

The sort node represents both the SORTBY clause.

1.3.3. CQL to PQF conversion

Conversion to PQF (and Z39.50 RPN) is tricky by the fact that the resulting RPN depends on the Z39.50 target capabilities (combinations of supported attributes). In addition, the CQL and SRU operates on index prefixes (URI or strings), whereas the RPN uses Object Identifiers for attribute sets.

The CQL library of YAZ defines a cql_transform_t handle. It represents a particular mapping between CQL and RPN. This handle is created and destroyed by the functions: 

cql_transform_t cql_transform_create(void);
int cql_transform_define_fname(cql_transform_t *ct, const char *fname);
int cql_transform_define_FILE(cql_trasnform_t *ct, FILE *f);
void cql_transform_close(cql_transform_t ct);

The first method constructs a handle. The second and third functon extends the configuration by reading from a file or an open FILE handle. The transform handle is destroyed by cql_transform_close in which case no further reference of the handle is allowed.

There are also two methods which creates and reads configuration from a file combined: 

cql_transform_t cql_transform_open_FILE (FILE *f);
cql_transform_t cql_transform_open_fname(const char *fname);

When a cql_transform_t handle has been created you can convert to RPN. 

int cql_transform_buf(cql_transform_t ct,
                      struct cql_node *cn, char *out, int max);

This function converts the CQL tree cn using handle ct. For the resulting PQF, you supply a buffer out which must be able to hold at at least max characters.

If conversion failed, cql_transform_buf returns a non-zero SRU error code; otherwise zero is returned (conversion successful). The meanings of the numeric error codes are listed in the SRU specification somewhere (no direct link anymore).

If conversion fails, more information can be obtained by calling 

int cql_transform_error(cql_transform_t ct, char **addinfop);

This function returns the most recently returned numeric error-code and sets the string-pointer at *addinfop to point to a string containing additional information about the error that occurred: for example, if the error code is 15 ("Illegal or unsupported context set"), the additional information is the name of the requested context set that was not recognised.

The SRU error-codes may be translated into brief human-readable error messages using 

const char *cql_strerror(int code);

If you wish to be able to produce a PQF result in a different way, there are two alternatives. 

void cql_transform_pr(cql_transform_t ct,
                      struct cql_node *cn,
                      void (*pr)(const char *buf, void *client_data),
                      void *client_data);

int cql_transform_FILE(cql_transform_t ct,
                       struct cql_node *cn, FILE *f);

The former function produces output to a user-defined output stream. The latter writes the result to an already open FILE.

1.3.4. Specification of CQL to RPN mappings

The file supplied to functions cql_transform_open_FILE, cql_transform_open_fname follows a structure found in many Unix utilities. It consists of mapping specifications - one per line. Lines starting with # are ignored (comments).

Each line is of the form


       CQL pattern =   RPN equivalent
      

An RPN pattern is a simple attribute list. Each attribute pair takes the form:


       [set] type=value
      

The attribute set is optional. The type is the attribute type, value the attribute value.

The character * (asterisk) has special meaning when used in the RPN pattern. Each occurrence of * is substituted with the CQL matching name (index, relation, qualifier etc). This facility can be used to copy a CQL name verbatim to the RPN result.

The following CQL patterns are recognized:

index.set.name

This pattern is invoked when a CQL index, such as dc.title is converted. set and name are the context set and index name respectively. Typically, the RPN specifies an equivalent use attribute.

For terms not bound by an index, the pattern index.cql.serverChoice is used. Here, the prefix cql is defined as http://www.loc.gov/zing/cql/cql-indexes/v1.0/. If this pattern is not defined, the mapping will fail.

The pattern, index.set.* is used when no other index pattern is matched.

qualifier.set.name (DEPRECATED)

For backwards compatibility, this is recognised as a synonym of index.set.name

relation.relation

This pattern specifies how a CQL relation is mapped to RPN. The pattern is name of relation operator. Since = is used as separator between CQL pattern and RPN, CQL relations including = cannot be used directly. To avoid a conflict, the names ge, eq, le, must be used for CQL operators, greater-than-or-equal, equal, less-than-or-equal respectively. The RPN pattern is supposed to include a relation attribute.

For terms not bound by a relation, the pattern relation.scr is used. If the pattern is not defined, the mapping will fail.

The special pattern, relation.* is used when no other relation pattern is matched.

relationModifier.mod

This pattern specifies how a CQL relation modifier is mapped to RPN. The RPN pattern is usually a relation attribute.

structure.type

This pattern specifies how a CQL structure is mapped to RPN. Note that this CQL pattern is somewhat similar to CQL pattern relation. The type is a CQL relation.

The pattern, structure.* is used when no other structure pattern is matched. Usually, the RPN equivalent specifies a structure attribute.

position.type

This pattern specifies how the anchor (position) of CQL is mapped to RPN. The type is one of first, any, last, firstAndLast.

The pattern, position.* is used when no other position pattern is matched.

set.prefix

This specification defines a CQL context set for a given prefix. The value on the right hand side is the URI for the set - not RPN. All prefixes used in index patterns must be defined this way.

set

This specification defines a default CQL context set for index names. The value on the right hand side is the URI for the set.

Example 7.10. CQL to RPN mapping file

This simple file defines two context sets, three indexes and three relations, a position pattern and a default structure. 

       set.cql  = http://www.loc.gov/zing/cql/context-sets/cql/v1.1/
       set.dc   = http://www.loc.gov/zing/cql/dc-indexes/v1.0/

       index.cql.serverChoice = 1=1016
       index.dc.title         = 1=4
       index.dc.subject       = 1=21

       relation.<             = 2=1
       relation.eq            = 2=3
       relation.scr           = 2=3

       position.any           = 3=3 6=1

       structure.*            = 4=1

With the mappings above, the CQL query 

        computer

is converted to the PQF: 

        @attr 1=1016 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "computer"

by rules index.cql.serverChoice, relation.scr, structure.*, position.any.

CQL query 

        computer^

is rejected, since position.right is undefined.

CQL query 

        >my = "http://www.loc.gov/zing/cql/dc-indexes/v1.0/" my.title = x

is converted to 

        @attr 1=4 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "x"


Example 7.11. CQL to RPN string attributes

In this example we allow any index to be passed to RPN as a use attribute. 

       # Identifiers for prefixes used in this file. (index.*)
       set.cql  = info:srw/cql-context-set/1/cql-v1.1
       set.rpn  = http://bogus/rpn
       set      = http://bogus/rpn

       # The default index when none is specified by the query
       index.cql.serverChoice     = 1=any

       index.rpn.*                = 1=*
       relation.eq                = 2=3
       structure.*                = 4=1
       position.any               = 3=3

The http://bogus/rpn context set is also the default so we can make queries such as 

        title = a

which is converted to 

        @attr 2=3 @attr 4=1 @attr 3=3 @attr 1=title "a"


Example 7.12. CQL to RPN using Bath Profile

The file etc/pqf.properties has mappings from the Bath Profile and Dublin Core to RPN. If YAZ is installed as a package it's usually located in /usr/share/yaz/etc and part of the development package, such as libyaz-dev.


1.3.5. CQL to XCQL conversion

Conversion from CQL to XCQL is trivial and does not require a mapping to be defined. There are three functions to choose from depending on the way you wish to store the resulting output (XML buffer containing XCQL). 

int cql_to_xml_buf(struct cql_node *cn, char *out, int max);
void cql_to_xml(struct cql_node *cn,
                void (*pr)(const char *buf, void *client_data),
                void *client_data);
void cql_to_xml_stdio(struct cql_node *cn, FILE *f);

Function cql_to_xml_buf converts to XCQL and stores the result in a user-supplied buffer of a given max size.

cql_to_xml writes the result in a user-defined output stream. cql_to_xml_stdio writes to a a file.

1.3.6. PQF to CQL conversion

Conversion from PQF to CQL is offered by the two functions shown below. The former uses a generic stream for result. The latter puts result in a WRBUF (string container). 

#include <yaz/rpn2cql.h>

int cql_transform_rpn2cql_stream(cql_transform_t ct,
                                 void (*pr)(const char *buf, void *client_data),
                                 void *client_data,
                                 Z_RPNQuery *q);

int cql_transform_rpn2cql_wrbuf(cql_transform_t ct,
                                WRBUF w,
                                Z_RPNQuery *q);

The configuration is the same as used in CQL to PQF conversions.

Prev   Next
4. SRU Home 2. Object Identifiers
yaz-5.37.0/doc/facets.html0000644000175000017500000000710315130444232013736 0ustar00adamadam8. Facets
8. Facets
Prev Chapter 7. Supporting Tools Next

8. Facets

YAZ supports facets in the Solr, SRU 2.0 and Z39.50 protocols.

Like Type-1/RPN, YAZ supports a string notation for specifying facets. This notataion maps straight to facets.asn. The notation is parsed by function yaz_pqf_parse_facet_list defined in header yaz/pquery.h.

For ZOOM C the facets are specified by option "facets". For yaz-client, the 'facets' command is used.

The grammar of this specification is as follows:


   facet-spec ::= facet-list

   facet-list ::= facet-list ',' attr-spec | attr-spec

   attr-spec ::= attr-spec '@attr' string | '@attr' string

    

The notation is inspired by PQF. The string following '@attr' must not include blanks and is of the form type=value, where type is an integer and value is a string or an integer.

There is no formal facets attribute set (it is not given in the protocol by the facets, although it could). The following types apply:

Table 7.4. Facet attributes

TypeDescription
1 Field-name. This is often a string, e.g. "Author", "Year", etc.
2 Sort order. Value should be an integer. Value 0: count descending (frequency). Value 1: alpha ascending.
3 Number of terms requested.
4 Start offset (starting from 1)

Prev Up Next
7. Sorting Home Chapter 8. The ODR Module
yaz-5.37.0/doc/entities.ent0000644000175000017500000000137015127270670014150 0ustar00adamadam ODR"> COMSTACK"> ZOOM"> "> "> yaz-5.37.0/doc/yaz-icu-man.xml0000644000175000017500000001720315123757344014476 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-icu 1 Commands yaz-icu YAZ ICU utility yaz-icu -c config -p opt -s -x infile DESCRIPTION yaz-icu is a utility which demonstrates the ICU chain module of yaz. (yaz/icu.h). The utility can be used in two ways. It may read some text using an XML configuration for configuring ICU and show text analysis. This mode is triggered by option -c which specifies the configuration to be used. The input file is read from standard input or from a file if infile is specified. The utility may also show ICU information. This is triggered by option -p. OPTIONS -c config Specifies the file containing ICU chain configuration which is XML based. -p type Specifies extra information to be printed about the ICU system. If type is c then ICU converters are printed. If type is l, then available locales are printed. If type is t, then available transliterators are printed. -s Specifies that output should include sort key as well. Note that sort key differs between ICU versions. -x Specifies that output should be XML based rather than "text" based. ICU chain configuration The ICU chain configuration specifies one or more rules to convert text data into tokens. The configuration format is XML based. The toplevel element must be named icu_chain. The icu_chain element has one required attribute locale which specifies the ICU locale to be used in the conversion steps. The icu_chain element must include elements where each element specifies a conversion step. The conversion is performed in the order in which the conversion steps are specified. Each conversion element takes one attribute: rule which serves as argument to the conversion step. The following conversion elements are available: casemap Converts case (and rule specifies how): l Lower case using ICU function u_strToLower. u Upper case using ICU function u_strToUpper. t To title using ICU function u_strToTitle. f Fold case using ICU function u_strFoldCase. display This is a meta step which specifies that a term/token is to be displayed. This term is retrieved in an application using function icu_chain_token_display (yaz/icu.h). transform Specifies an ICU transform rule using a transliterator Identifier. The rule attribute is the transliterator Identifier. See ICU Transforms for more information. transliterate Specifies a rule-based transliterator. The rule attribute is the custom transformation rule to be used. See ICU Transforms for more information. tokenize Breaks / tokenizes a string into components using ICU functions ubrk_open, ubrk_setText, .. . The rule is one of: l Line. ICU: UBRK_LINE. s Sentence. ICU: UBRK_SENTENCE. w Word. ICU: UBRK_WORD. c Character. ICU: UBRK_CHARACTER. t Title. ICU: UBRK_TITLE. join Joins tokens into one string. The rule attribute is the joining string, which may be empty. The join conversion element was added in YAZ 4.2.49. EXAMPLES The following command analyzes text in file text using ICU chain configuration chain.xml: cat text | yaz-icu -c chain.xml The chain.xml might look as follows: ]]> SEE ALSO yaz 7 ICU Home ICU Transforms yaz-5.37.0/doc/yaz-record-conv-man.xml0000644000175000017500000000602115123757344016133 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-record-iconv 1 Commands yaz-record-conv YAZ Record Conversion Utility yaz-record-conv config fname DESCRIPTION yaz-record-conv is a program that exercises the record conversion sub system. Refer to record_conv.h header. OPTIONS -v level Sets the LOG level to level. Level is a sequence of tokens separated by comma. Each token is a integer or a named LOG item - one of fatal, debug, warn, log, malloc, all, none. EXAMPLES The following backend configuration converts MARC records (ISO2709) to Dublin-Core XML. ]]> We can convert one of the sample records from YAZ' test directory with: How to program a computer Jack Collins text Penguin eng ]]> FILES record_conv.h SEE ALSO yaz(7) yaz-5.37.0/doc/odr.programming.html0000644000175000017500000006500215130444232015600 0ustar00adamadam3. Programming with ODR
3. Programming with ODR
Prev Chapter 8. The ODR Module Next

3. Programming with ODR

The API of ODR is designed to reflect the structure of ASN.1, rather than BER itself. Future releases may be able to represent data in other external forms.

Tip

There is an ASN.1 tutorial available at this site. This site also has standards for ASN.1 (X.680) and BER (X.690) online.

The ODR interface is based loosely on that of the Sun Microsystems XDR routines. Specifically, each function which corresponds to an ASN.1 primitive type has a dual function. Depending on the settings of the ODR stream which is supplied as a parameter, the function may be used either to encode or decode data. The functions that can be built using these primitive functions, to represent more complex data types, share this quality. The result is that you only have to enter the definition for a type once - and you have the functionality of encoding, decoding (and pretty-printing) all in one unit. The resulting C source code is quite compact, and is a pretty straightforward representation of the source ASN.1 specification.

In many cases, the model of the XDR functions works quite well in this role. In others, it is less elegant. Most of the hassle comes from the optional SEQUENCE members which don't exist in XDR.

3.1. The Primitive ASN.1 Types

ASN.1 defines a number of primitive types (many of which correspond roughly to primitive types in structured programming languages, such as C).

3.1.1. INTEGER

The ODR function for encoding or decoding (or printing) the ASN.1 INTEGER type looks like this: 

      int odr_integer(ODR o, Odr_int **p, int optional, const char *name);

The Odr_int is just a simple integer.

This form is typical of the primitive ODR functions. They are named after the type of data that they encode or decode. They take an ODR stream, an indirect reference to the type in question, and an optional flag (corresponding to the OPTIONAL keyword of ASN.1) as parameters. They all return an integer value of either one or zero. When you use the primitive functions to construct encoders for complex types of your own, you should follow this model as well. This ensures that your new types can be reused as elements in yet more complex types.

The o parameter should obviously refer to a properly initialized ODR stream of the right type (encoding/decoding/printing) for the operation that you wish to perform.

When encoding or printing, the function first looks at * p. If * p (the pointer pointed to by p) is a null pointer, this is taken to mean that the data element is absent. If the optional parameter is nonzero, the function will return one (signifying success) without any further processing. If the optional is zero, an internal error flag is set in the ODR stream, and the function will return 0. No further operations can be carried out on the stream without a call to the function odr_reset().

If *p is not a null pointer, it is expected to point to an instance of the data type. The data will be subjected to the encoding rules, and the result will be placed in the buffer held by the ODR stream.

The other ASN.1 primitives have similar functions that operate in similar manners:

3.1.2. BOOLEAN

int odr_bool(ODR o, Odr_bool **p, int optional, const char *name);

3.1.3. REAL

Not defined.

3.1.4. NULL

int odr_null(ODR o, Odr_null **p, int optional, const char *name);

In this case, the value of **p is not important. If *p is different from the null pointer, the null value is present, otherwise it's absent.

3.1.5. OCTET STRING

typedef struct odr_oct
{
    unsigned char *buf;
    int len;
} Odr_oct;

int odr_octetstring(ODR o, Odr_oct **p, int optional,
                    const char *name);

The buf field should point to the character array that holds the octetstring. The len field holds the actual length. The character array need not be null-terminated.

To make things a little easier, an alternative is given for string types that are not expected to contain embedded NULL characters (e.g. VisibleString): 

      int odr_cstring(ODR o, char **p, int optional, const char *name);

which encodes or decodes between OCTETSTRING representations and null-terminated C strings.

Functions are provided for the derived string types, e.g.: 

int odr_visiblestring(ODR o, char **p, int optional,
                      const char *name);

3.1.6. BIT STRING

int odr_bitstring(ODR o, Odr_bitmask **p, int optional,
                  const char *name);

The opaque type Odr_bitmask is only suitable for holding relatively brief bit strings, e.g. for options fields, etc. The constant ODR_BITMASK_SIZE multiplied by 8 gives the maximum possible number of bits.

A set of macros are provided for manipulating the Odr_bitmask type: 

void ODR_MASK_ZERO(Odr_bitmask *b);

void ODR_MASK_SET(Odr_bitmask *b, int bitno);

void ODR_MASK_CLEAR(Odr_bitmask *b, int bitno);

int ODR_MASK_GET(Odr_bitmask *b, int bitno);

The functions are modeled after the manipulation functions that accompany the fd_set type used by the select(2) call. ODR_MASK_ZERO should always be called first on a new bitmask, to initialize the bits to zero.

3.1.7. OBJECT IDENTIFIER

int odr_oid(ODR o, Odr_oid **p, int optional, const char *name);

The C OID representation is simply an array of integers, terminated by the value -1 (the Odr_oid type is synonymous with the short type). We suggest that you use the OID database module (see Section 2.1, “OID database”) to handle object identifiers in your application.

3.2. Tagging Primitive Types

The simplest way of tagging a type is to use the odr_implicit_tag() or odr_explicit_tag() macros: 

int odr_implicit_tag(ODR o, Odr_fun fun, int class, int tag,
                     int optional, const char *name);

int odr_explicit_tag(ODR o, Odr_fun fun, int class, int tag,
                     int optional, const char *name);

To create a type derived from the integer type by implicit tagging, you might write: 

     MyInt ::= [210] IMPLICIT INTEGER

In the ODR system, this would be written like: 

int myInt(ODR o, Odr_int **p, int optional, const char *name)
{
    return odr_implicit_tag(o, odr_integer, p,
			    ODR_CONTEXT, 210, optional, name);
}

The function myInt() can then be used like any of the primitive functions provided by ODR. Note that the behavior of odr_explicit_tag() and odr_implicit_tag() macros act exactly the same as the functions they are applied to - they respond to error conditions, etc, in the same manner - they simply have three extra parameters. The class parameter may take one of the values: ODR_CONTEXT, ODR_PRIVATE, ODR_UNIVERSAL, or /ODR_APPLICATION.

3.3. Constructed Types

Constructed types are created by combining primitive types. The ODR system only implements the SEQUENCE and SEQUENCE OF constructions (although adding the rest of the container types should be simple enough, if the need arises).

For implementing SEQUENCEs, the functions 

int odr_sequence_begin(ODR o, void *p, int size, const char *name);
int odr_sequence_end(ODR o);

are provided.

The odr_sequence_begin() function should be called in the beginning of a function that implements a SEQUENCE type. Its parameters are the ODR stream, a pointer (to a pointer to the type you're implementing), and the size of the type (typically a C structure). On encoding, it returns 1 if * p is a null pointer. The size parameter is ignored. On decoding, it returns 1 if the type is found in the data stream. size bytes of memory are allocated, and *p is set to point to this space. The odr_sequence_end() is called at the end of the complex function. Assume that a type is defined like this: 

MySequence ::= SEQUENCE {
     intval INTEGER,
     boolval BOOLEAN OPTIONAL
}

The corresponding ODR encoder/decoder function and the associated data structures could be written like this: 

typedef struct MySequence
{
    Odr_int *intval;
    Odr_bool *boolval;
} MySequence;

int mySequence(ODR o, MySequence **p, int optional, const char *name)
{
    if (odr_sequence_begin(o, p, sizeof(**p), name) == 0)
        return optional && odr_ok(o);
    return
        odr_integer(o, &(*p)->intval, 0, "intval") &&
        odr_bool(o, &(*p)->boolval, 1, "boolval") &&
        odr_sequence_end(o);
}

Note the 1 in the call to odr_bool(), to mark that the sequence member is optional. If either of the member types had been tagged, the macros odr_implicit_tag() or odr_explicit_tag() could have been used. The new function can be used exactly like the standard functions provided with ODR. It will encode, decode or pretty-print a data value of the MySequence type. We like to name types with an initial capital, as done in ASN.1 definitions, and to name the corresponding function with the first character of the name in lower case. You could, of course, name your structures, types, and functions any way you please - as long as you're consistent, and your code is easily readable. odr_ok is just that - a predicate that returns the state of the stream. It is used to ensure that the behavior of the new type is compatible with the interface of the primitive types.

3.4. Tagging Constructed Types

Note

See Section 3.2, “Tagging Primitive Types” for information on how to tag the primitive types, as well as types that are already defined.

3.4.1. Implicit Tagging

Assume the type above had been defined as 

MySequence ::= [10] IMPLICIT SEQUENCE {
      intval INTEGER,
      boolval BOOLEAN OPTIONAL
}

You would implement this in ODR by calling the function 

int odr_implicit_settag(ODR o, int class, int tag);

which overrides the tag of the type immediately following it. The macro odr_implicit_tag() works by calling odr_implicit_settag() immediately before calling the function pointer argument. Your type function could look like this: 

int mySequence(ODR o, MySequence **p, int optional, const char *name)
{
    if (odr_implicit_settag(o, ODR_CONTEXT, 10) == 0 ||
        odr_sequence_begin(o, p, sizeof(**p), name) == 0)
        return optional && odr_ok(o);
    return
        odr_integer(o, &(*p)->intval, 0, "intval") &&
        odr_bool(o, &(*p)->boolval, 1, "boolval") &&
        odr_sequence_end(o);
}

The definition of the structure MySequence would be the same.

3.4.2. Explicit Tagging

Explicit tagging of constructed types is a little more complicated, since you are in effect adding a level of construction to the data.

Assume the definition: 

MySequence ::= [10] IMPLICIT SEQUENCE {
   intval INTEGER,
   boolval BOOLEAN OPTIONAL
}

Since the new type has an extra level of construction, two new functions are needed to encapsulate the base type: 

int odr_constructed_begin(ODR o, void *p, int class, int tag,
                          const char *name);

int odr_constructed_end(ODR o);

Assume that the IMPLICIT in the type definition above were replaced with EXPLICIT (or that the IMPLICIT keyword was simply deleted, which would be equivalent). The structure definition would look the same, but the function would look like this: 

int mySequence(ODR o, MySequence **p, int optional, const char *name)
{
    if (odr_constructed_begin(o, p, ODR_CONTEXT, 10, name) == 0)
        return optional && odr_ok(o);
    if (o->direction == ODR_DECODE)
        *p = odr_malloc(o, sizeof(**p));
    if (odr_sequence_begin(o, p, sizeof(**p), 0) == 0)
    {
        *p = 0; /* this is almost certainly a protocol error */
        return 0;
    }
    return
        odr_integer(o, &(*p)->intval, 0, "intval") &&
        odr_bool(o, &(*p)->boolval, 1, "boolval") &&
        odr_sequence_end(o) &&
        odr_constructed_end(o);
}

Notice that the interface here gets kind of nasty. The reason is simple: Explicitly tagged, constructed types are fairly rare in the protocols that we care about, so the aesthetic annoyance (not to mention the dangers of a cluttered interface) is less than the time that would be required to develop a better interface. Nevertheless, it is far from satisfying, and it's a point that will be worked on in the future. One option for you would be to simply apply the odr_explicit_tag() macro to the first function, and not have to worry about odr_constructed_* yourself. Incidentally, as you might have guessed, the odr_sequence_ functions are themselves implemented using the /odr_constructed_ functions.

3.5. SEQUENCE OF

To handle sequences (arrays) of a specific type, the function 

int odr_sequence_of(ODR o, int (*fun)(ODR o, void *p, int optional),
                    void *p, int *num, const char *name);

The fun parameter is a pointer to the decoder/encoder function of the type. p is a pointer to an array of pointers to your type. num is the number of elements in the array.

Assume a type 

MyArray ::= SEQUENCE OF INTEGER

The C representation might be 

typedef struct MyArray
{
    int num_elements;
    Odr_int **elements;
} MyArray;

And the function might look like 

int myArray(ODR o, MyArray **p, int optional, const char *name)
{
    if (o->direction == ODR_DECODE)
        *p = odr_malloc(o, sizeof(**p));
    if (odr_sequence_of(o, odr_integer, &(*p)->elements,
        &(*p)->num_elements, name))
        return 1;
    *p = 0;
        return optional && odr_ok(o);
}

3.6. CHOICE Types

The choice type is used fairly often in some ASN.1 definitions, so some work has gone into streamlining its interface.

CHOICE types are handled by the function: 

int odr_choice(ODR o, Odr_arm arm[], void *p, void *whichp,
               const char *name);

The arm array is used to describe each of the possible types that the CHOICE type may assume. Internally in your application, the CHOICE type is represented as a discriminated union. That is, a C union accompanied by an integer (or enum) identifying the active 'arm' of the union. whichp is a pointer to the union discriminator. When encoding, it is examined to determine the current type. When decoding, it is set to reference the type that was found in the input stream.

The Odr_arm type is defined thus: 

typedef struct odr_arm
{
    int tagmode;
    int class;
    int tag;
    int which;
    Odr_fun fun;
    char *name;
} Odr_arm;

The interpretation of the fields are:

tagmode

Either ODR_IMPLICIT, ODR_EXPLICIT, or ODR_NONE (-1) to mark no tagging.

which

The value of the discriminator that corresponds to this CHOICE element. Typically, it will be a #defined constant, or an enum member.

fun

A pointer to a function that implements the type of the CHOICE member. It may be either a standard ODR type or a type defined by yourself.

name

Name of tag.

A handy way to prepare the array for use by the odr_choice() function is to define it as a static, initialized array in the beginning of your decoding/encoding function. Assume the type definition: 

MyChoice ::= CHOICE {
    untagged INTEGER,
    tagged   [99] IMPLICIT INTEGER,
    other    BOOLEAN
}

Your C type might look like 

typedef struct MyChoice
{
    enum
    {
        MyChoice_untagged,
        MyChoice_tagged,
        MyChoice_other
    } which;
    union
    {
        Odr_int *untagged;
        Odr_int *tagged;
        Odr_bool *other;
    } u;
};

And your function could look like this: 

int myChoice(ODR o, MyChoice **p, int optional, const char *name)
{
    static Odr_arm arm[] =
    {
      {-1, -1, -1, MyChoice_untagged, odr_integer, "untagged"},
      {ODR_IMPLICIT, ODR_CONTEXT, 99, MyChoice_tagged, odr_integer,
      "tagged"},
      {-1, -1, -1, MyChoice_other, odr_boolean, "other"},
      {-1, -1, -1, -1, 0}
    };

    if (o->direction == ODR_DECODE)
        *p = odr_malloc(o, sizeof(**p);
    else if (!*p)
        return optional && odr_ok(o);

    if (odr_choice(o, arm, &(*p)->u, &(*p)->which), name)
        return 1;
    *p = 0;
        return optional && odr_ok(o);
}

In some cases (say, a non-optional choice which is a member of a sequence), you can "embed" the union and its discriminator in the structure belonging to the enclosing type, and you won't need to fiddle with memory allocation to create a separate structure to wrap the discriminator and union.

The corresponding function is somewhat nicer in the Sun XDR interface. Most of the complexity of this interface comes from the possibility of declaring sequence elements (including CHOICEs) optional.

The ASN.1 specifications naturally require that each member of a CHOICE have a distinct tag, so they can be told apart on decoding. Sometimes it can be useful to define a CHOICE that has multiple types that share the same tag. You'll need some other mechanism, perhaps keyed to the context of the CHOICE type. In effect, we would like to introduce a level of context-sensitiveness to our ASN.1 specification. When encoding an internal representation, we have no problem, as long as each CHOICE member has a distinct discriminator value. For decoding, we need a way to tell the choice function to look for a specific arm of the table. The function 

void odr_choice_bias(ODR o, int what);

provides this functionality. When called, it leaves a notice for the next call to odr_choice() to be called on the decoding stream o, that only the arm entry with a which field equal to what should be tried.

The most important application (perhaps the only one, really) is in the definition of application-specific EXTERNAL encoders/decoders which will automatically decode an ANY member given the direct or indirect reference.

Prev Up Next
2. Using ODR Home 4. Debugging
yaz-5.37.0/doc/index.html0000644000175000017500000006232115130444232013603 0ustar00adamadamYAZ User's Guide and Reference
YAZ User's Guide and Reference
   Next

YAZ User's Guide and Reference

Sebastian Hammer

Adam Dickmeiss

Mike Taylor

Heikki Levanto

Dennis Schafroth

Jakub Skoczen

5.37.0

Copyright © 1995-2026 Index Data

Abstract

This document is the programmer's guide and reference to the YAZ package version 5.37.0. YAZ is a compact toolkit that provides access to the Z39.50 and SRU/Solr protocols, as well as a set of higher-level tools for implementing the server and client roles, respectively. The documentation can be used on its own, or as a reference when looking at the example applications provided with the package.

Table of Contents

1. Introduction
1. Reading this Manual
2. The API
2. Compilation and Installation
1. Introduction
2. UNIX/macOS
2.1. Compiling from source on Unix
2.2. Compiling from source on macOS
2.3. How to make apps using YAZ on UNIX
3. Windows
3.1. Compiling from Source on Windows
3.2. How to make apps using YAZ on Windows
3.3. Compiling Libxml2 and Libxslt on windows
3. ZOOM
1. Connections
1.1. Z39.50 Protocol behavior
1.2. SRU/Solr Protocol behavior
2. Queries
3. Result sets
3.1. Z39.50 Result-set Sort
3.2. Z39.50 Protocol behavior
3.3. SRU Protocol behavior
4. Records
4.1. Z39.50 Protocol behavior
4.2. SRU/Solr Protocol behavior
5. ZOOM Facets
6. Scan
7. Extended Services
7.1. Item Order
7.2. Record Update
7.3. Database Create
7.4. Database Drop
7.5. Commit Operation
7.6. Protocol behavior
8. Options
9. Query conversions
10. Events
4. Generic server
1. Introduction
2. The Database Frontend
3. The Backend API
4. Your main() Routine
5. The Backend Functions
5.1. Init
5.2. Search and Retrieve
5.3. Delete
5.4. Scan
6. Application Invocation
7. GFS Configuration and Virtual Hosts
5. The Z39.50 ASN.1 Module
1. Introduction
2. Preparing PDUs
3. EXTERNAL Data
4. PDU Contents Table
6. SOAP and SRU
1. Introduction
2. HTTP
3. SOAP Packages
4. SRU
7. Supporting Tools
1. Query Syntax Parsers
1.1. Prefix Query Format
1.1.1. Using Proximity Operators with PQF
1.1.2. PQF queries
1.2. CCL
1.2.1. CCL Syntax
1.2.2. CCL Qualifiers
1.2.3. CCL API
1.3. CQL
1.3.1. CQL parsing
1.3.2. CQL tree
1.3.3. CQL to PQF conversion
1.3.4. Specification of CQL to RPN mappings
1.3.5. CQL to XCQL conversion
1.3.6. PQF to CQL conversion
2. Object Identifiers
2.1. OID database
2.2. Standard OIDs
3. Nibble Memory
4. Log
5. MARC
5.1. TurboMARC
6. Retrieval Facility
6.1. Retrieval XML format
6.2. Retrieval Facility Examples
6.3. API
7. Sorting
7.1. Using the Z39.50 sort service
7.2. Type-7 sort
8. Facets
8. The ODR Module
1. Introduction
2. Using ODR
2.1. ODR Streams
2.2. Memory Management
2.3. Encoding and Decoding Data
2.4. Printing
2.5. Diagnostics
2.6. Summary and Synopsis
3. Programming with ODR
3.1. The Primitive ASN.1 Types
3.1.1. INTEGER
3.1.2. BOOLEAN
3.1.3. REAL
3.1.4. NULL
3.1.5. OCTET STRING
3.1.6. BIT STRING
3.1.7. OBJECT IDENTIFIER
3.2. Tagging Primitive Types
3.3. Constructed Types
3.4. Tagging Constructed Types
3.4.1. Implicit Tagging
3.4.2. Explicit Tagging
3.5. SEQUENCE OF
3.6. CHOICE Types
4. Debugging
9. The COMSTACK Module
1. Synopsis (blocking mode)
2. Introduction
3. Common Functions
3.1. Managing Endpoints
3.2. Data Exchange
4. Client Side
5. Server Side
6. Addresses
7. SSL
8. Diagnostics
9. Summary and Synopsis
10. Future Directions
I. Reference
yaz-client — Z39.50/SRU client for implementors
yaz-ztest — Z39.50/SRU Test Server
yaz-config — Script to get information about YAZ.
yaz — Z39.50 toolkit.
zoomsh — ZOOM shell
yaz-asncomp — YAZ ASN.1 compiler
yaz-marcdump — MARC record dump utility
yaz-iconv — YAZ Character set conversion utility
yaz-log — Log handling in all yaz-based programs
yaz-illclient — ILL client
yaz-icu — YAZ ICU utility
yaz-url — YAZ URL fetch utility
Bib-1 Attribute Set — Bib-1 Attribute Set
yaz-json-parse — YAZ JSON parser
yaz-record-iconv — YAZ Record Conversion Utility
A. List of Object Identifiers
B. Bib-1 diagnostics
C. SRU diagnostics
D. License
1. Index Data Copyright
E. About Index Data
F. Credits

List of Figures

1.1. YAZ layers

List of Tables

3.1. ZOOM Connection Options
3.2. ZOOM sort strategy
3.3. ZOOM Result set Options
3.4. Search Info Report Options
3.5. ZOOM Scan Set Options
3.6. Extended Service Type
3.7. Extended Service Common Options
3.8. Item Order Options
3.9. ILL Request Options
3.10. Record Update Options
3.11. Database Create Options
3.12. Database Drop Options
3.13. ZOOM Event IDs
5.1. Default settings for PDU Initialize Request
5.2. Default settings for PDU Initialize Response
5.3. Default settings for PDU Search Request
5.4. Default settings for PDU Search Response
5.5. Default settings for PDU Present Request
5.6. Default settings for PDU Present Response
5.7. Default settings for Delete Result Set Request
5.8. Default settings for Delete Result Set Response
5.9. Default settings for Scan Request
5.10. Default settings for Scan Response
5.11. Default settings for Trigger Resource Control Request
5.12. Default settings for Resource Control Request
5.13. Default settings for Resource Control Response
5.14. Default settings for Access Control Request
5.15. Default settings for Access Control Response
5.16. Default settings for Segment
5.17. Default settings for Close
7.1. Common Bib-1 attributes
7.2. Special attribute combos
7.3. CCL directives
7.4. Facet attributes
8.1. ODR Error codes

List of Examples

4.1. Running the GFS on Unix
4.2. Setting up Apache as SRU Frontend
4.3. Running a server with local access only
7.1. PQF queries using simple terms
7.2. PQF boolean operators
7.3. PQF references to result sets
7.4. Attributes for terms
7.5. PQF Proximity queries
7.6. PQF specification of search term type
7.7. PQF mixed queries
7.8. CCL queries
7.9. CCL profile
7.10. CQL to RPN mapping file
7.11. CQL to RPN string attributes
7.12. CQL to RPN using Bath Profile
7.13. Create OID on stack
7.14. Using oid_oiddotstring_to_oid
7.15. Using odr_getoidbystr
7.16. Create OID with YAZ DB
7.17. Use a built-in OID
7.18. Display of MARC record
7.19. MARC21 backend
7.20. MARCXML backend
7.21. RDF-lookup backend
8.1. Encoding and decoding functions
8.2. Encoding and decoding of an integer
8.3. Element Path for record
   Next
   Chapter 1. Introduction
yaz-5.37.0/doc/server.vhosts.html0000644000175000017500000002623115130444232015327 0ustar00adamadam7. GFS Configuration and Virtual Hosts
7. GFS Configuration and Virtual Hosts
Prev Chapter 4. Generic server Next

7. GFS Configuration and Virtual Hosts

The Virtual hosts mechanism allows a YAZ front-end server to support multiple back-ends. A back-end is selected on the basis of the TCP/IP binding (port+listening address) and/or the virtual host.

A back-end can be configured to execute in a particular working directory. Or the YAZ front-end may perform CQL to RPN conversion, thus allowing traditional Z39.50 back-ends to be offered as a SRW/SRU service. SRW/SRU Explain information for a particular back-end may also be specified.

For the HTTP protocol, the virtual host is specified in the Host header. For the Z39.50 protocol, the virtual host is specified as in the Initialize Request in the OtherInfo, OID 1.2.840.10003.10.1000.81.1.

Note

Not all Z39.50 clients allow the VHOST information to be set. For those, the selection of the back-end must rely on the TCP/IP information alone (port and address).

The YAZ front-end server uses XML to describe the back-end configurations. Command-line option -f specifies filename of the XML configuration.

The configuration uses the root element yazgfs. This element includes a list of listen elements, followed by one or more server elements.

The listen describes listener (transport end point), such as TCP/IP, Unix file socket or SSL server. Content for a listener:

CDATA (required)

The CDATA for the listen element holds the listener string, such as tcp:@:210, tcp:server1:2100, etc.

attribute id (optional)

Identifier for this listener. This may be referred to from server sections.

Note

We expect more information to be added for the listen section in a future version, such as CERT file for SSL servers.

The server describes a server and the parameters for this server type. Content for a server:

attribute id (optional)

Identifier for this server. Currently not used for anything, but it might be for logging purposes.

attribute listenref (optional)

Specifies one or more listeners for this server. Each server ID is separated by a comma. If this attribute is not given, the server is accessible from all listeners. In order for the server to be used for real, however, the virtual host must match if specified in the configuration.

element config (optional)

Specifies the server configuration. This is equivalent to the config specified using command line option -c.

element directory (optional)

Specifies a working directory for this backend server. If specified, the YAZ 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).

element host (optional)

Specifies the virtual host for this server. If this is specified a client must specify this host string in order to use this backend.

element cql2rpn (optional)

Specifies a filename that includes CQL to RPN conversion for this backend server. See Section 1.3.4, “Specification of CQL to RPN mappings”. If given, the backend server will only "see" a Type-1/RPN query.

element ccl2rpn (optional)

Specifies a filename that includes CCL to RPN conversion for this backend server. See Section 1.2.2, “CCL Qualifiers”. If given, the backend server will only "see" a Type-1/RPN query.

element stylesheet (optional)

Specifies the stylesheet reference to be part of SRU HTTP responses when the client does not specify one. If none is given, then if the client does not specify one, then no stylesheet reference is part of the SRU HTTP response.

element client_query_charset (optional)

If specified, a conversion from the character set given to UTF-8 is performed by the generic frontend server. It is only executed for Z39.50 search requests (SRU/Solr are assumed to be UTF-8 encoded already).

element docpath (optional)

Specifies a path for local file access using HTTP. All URLs with a leading prefix (/ excluded) that matches the value of docpath are used for file access. For example, if the server is to offer access in directory xsl, the docpath would be xsl and all URLs of the form http://host/xsl will result in a local file access.

element explain (optional)

Specifies SRW/SRU ZeeRex content for this server. Copied verbatim to the client. As things are now, some of the Explain content seem redundant because host information, etc. is also stored elsewhere.

element maximumrecordsize (optional)

Specifies maximum record size/message size, in bytes. This value also serves as the maximum size of incoming packages (for Record Updates etc). It's the same value as that given by the -k option.

element retrievalinfo (optional)

Enables the retrieval facility to support conversions and specifications of record formats/types. See Section 6, “Retrieval Facility” for more information.

The XML 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 public and the other server internal. 

  
 <yazgfs>
  <listen id="public">tcp:@:9900</listen>
  <listen id="internal">unix:/var/tmp/socket</listen>
  <server id="server1">
    <host>server1.mydomain</host>
    <directory>/var/www/s1</directory>
    <config>config.cfg</config>
  </server>
  <server id="server2" listenref="public,internal">
    <host>server2.mydomain</host>
    <directory>/var/www/s2</directory>
    <config>config.cfg</config>
    <cql2rpn>../etc/pqf.properties</cql2rpn>
    <explain xmlns="http://explain.z3950.org/dtd/2.0/">
      <serverInfo>
        <host>server2.mydomain</host>
        <port>9900</port>
        <database>a</database>
      </serverInfo>
    </explain>
  </server>
  <server id="server3" listenref="internal">
    <directory>/var/www/s3</directory>
    <config>config.cfg</config>
  </server>
 </yazgfs>

There are three configured backend servers. The first two servers, "server1" and "server2", can be reached by both listener addresses. "server1" is reached by all (two) since no listenref attribute is specified. "server2" is reached by the two listeners specified. In order to distinguish between the two, a virtual host has been specified for each server in the host elements.

For "server2" elements for CQL to RPN conversion is supported and explain information has been added (a short one here to keep the example small).

The third server, "server3" can only be reached via listener "internal".

Prev Up Next
6. Application Invocation Home Chapter 5. The Z39.50 ASN.1 Module
yaz-5.37.0/doc/std-oid-table.xml0000644000175000017500000007361315130444224014767 0ustar00adamadam Name Class Constant / OID BER TRANSYN yaz_oid_transyn_ber 2.1.1 ISO2709 TRANSYN yaz_oid_transyn_iso2709 1.0.2709.1.1 ISOILL-1 GENERAL yaz_oid_general_isoill_1 1.0.10161.2.1 Z-APDU ABSYN yaz_oid_absyn_z_apdu 2.1 Z-BASIC APPCTX yaz_oid_appctx_z_basic 1.1 Bib-1 ATTSET yaz_oid_attset_bib_1 Z3950_PREFIX.3.1 Exp-1 ATTSET yaz_oid_attset_exp_1 Z3950_PREFIX.3.2 Ext-1 ATTSET yaz_oid_attset_ext_1 Z3950_PREFIX.3.3 CCL-1 ATTSET yaz_oid_attset_ccl_1 Z3950_PREFIX.3.4 GILS ATTSET yaz_oid_attset_gils Z3950_PREFIX.3.5 GILS-attset ATTSET yaz_oid_attset_gils_attset Z3950_PREFIX.3.5 STAS-attset ATTSET yaz_oid_attset_stas_attset Z3950_PREFIX.3.6 Collections-attset ATTSET yaz_oid_attset_collections_attset Z3950_PREFIX.3.7 CIMI-attset ATTSET yaz_oid_attset_cimi_attset Z3950_PREFIX.3.8 Geo-attset ATTSET yaz_oid_attset_geo_attset Z3950_PREFIX.3.9 ZBIG ATTSET yaz_oid_attset_zbig Z3950_PREFIX.3.10 Util ATTSET yaz_oid_attset_util Z3950_PREFIX.3.11 XD-1 ATTSET yaz_oid_attset_xd_1 Z3950_PREFIX.3.12 Zthes ATTSET yaz_oid_attset_zthes Z3950_PREFIX.3.13 Fin-1 ATTSET yaz_oid_attset_fin_1 Z3950_PREFIX.3.14 Dan-1 ATTSET yaz_oid_attset_dan_1 Z3950_PREFIX.3.15 Holdings ATTSET yaz_oid_attset_holdings Z3950_PREFIX.3.16 MARC ATTSET yaz_oid_attset_marc Z3950_PREFIX.3.17 Bib-2 ATTSET yaz_oid_attset_bib_2 Z3950_PREFIX.3.18 ZeeRex ATTSET yaz_oid_attset_zeerex Z3950_PREFIX.3.19 Thesaurus-attset ATTSET yaz_oid_attset_thesaurus_attset Z3950_PREFIX.3.1000.81.1 IDXPATH ATTSET yaz_oid_attset_idxpath Z3950_PREFIX.3.1000.81.2 EXTLITE ATTSET yaz_oid_attset_extlite Z3950_PREFIX.3.1000.81.3 Bib-1 DIAGSET yaz_oid_diagset_bib_1 Z3950_PREFIX.4.1 Diag-1 DIAGSET yaz_oid_diagset_diag_1 Z3950_PREFIX.4.2 Diag-ES DIAGSET yaz_oid_diagset_diag_es Z3950_PREFIX.4.3 Diag-General DIAGSET yaz_oid_diagset_diag_general Z3950_PREFIX.4.3 Unimarc RECSYN yaz_oid_recsyn_unimarc Z3950_PREFIX.5.1 Intermarc RECSYN yaz_oid_recsyn_intermarc Z3950_PREFIX.5.2 CCF RECSYN yaz_oid_recsyn_ccf Z3950_PREFIX.5.3 USmarc RECSYN yaz_oid_recsyn_usmarc Z3950_PREFIX.5.10 MARC21 RECSYN yaz_oid_recsyn_marc21 Z3950_PREFIX.5.10 UKmarc RECSYN yaz_oid_recsyn_ukmarc Z3950_PREFIX.5.11 Normarc RECSYN yaz_oid_recsyn_normarc Z3950_PREFIX.5.12 Librismarc RECSYN yaz_oid_recsyn_librismarc Z3950_PREFIX.5.13 Danmarc RECSYN yaz_oid_recsyn_danmarc Z3950_PREFIX.5.14 Finmarc RECSYN yaz_oid_recsyn_finmarc Z3950_PREFIX.5.15 MAB RECSYN yaz_oid_recsyn_mab Z3950_PREFIX.5.16 Canmarc RECSYN yaz_oid_recsyn_canmarc Z3950_PREFIX.5.17 SBN RECSYN yaz_oid_recsyn_sbn Z3950_PREFIX.5.18 Picamarc RECSYN yaz_oid_recsyn_picamarc Z3950_PREFIX.5.19 Ausmarc RECSYN yaz_oid_recsyn_ausmarc Z3950_PREFIX.5.20 Ibermarc RECSYN yaz_oid_recsyn_ibermarc Z3950_PREFIX.5.21 Carmarc RECSYN yaz_oid_recsyn_carmarc Z3950_PREFIX.5.22 Malmarc RECSYN yaz_oid_recsyn_malmarc Z3950_PREFIX.5.23 JPmarc RECSYN yaz_oid_recsyn_jpmarc Z3950_PREFIX.5.24 SWEmarc RECSYN yaz_oid_recsyn_swemarc Z3950_PREFIX.5.25 SIGLEmarc RECSYN yaz_oid_recsyn_siglemarc Z3950_PREFIX.5.26 ISDSmarc RECSYN yaz_oid_recsyn_isdsmarc Z3950_PREFIX.5.27 RUSmarc RECSYN yaz_oid_recsyn_rusmarc Z3950_PREFIX.5.28 Hunmarc RECSYN yaz_oid_recsyn_hunmarc Z3950_PREFIX.5.29 NACSIS-CATP RECSYN yaz_oid_recsyn_nacsis_catp Z3950_PREFIX.5.30 FINMARC2000 RECSYN yaz_oid_recsyn_finmarc2000 Z3950_PREFIX.5.31 MARC21-fin RECSYN yaz_oid_recsyn_marc21_fin Z3950_PREFIX.5.32 Explain RECSYN yaz_oid_recsyn_explain Z3950_PREFIX.5.100 SUTRS RECSYN yaz_oid_recsyn_sutrs Z3950_PREFIX.5.101 OPAC RECSYN yaz_oid_recsyn_opac Z3950_PREFIX.5.102 Summary RECSYN yaz_oid_recsyn_summary Z3950_PREFIX.5.103 GRS-0 RECSYN yaz_oid_recsyn_grs_0 Z3950_PREFIX.5.104 GRS-1 RECSYN yaz_oid_recsyn_grs_1 Z3950_PREFIX.5.105 Extended RECSYN yaz_oid_recsyn_extended Z3950_PREFIX.5.106 Fragment RECSYN yaz_oid_recsyn_fragment Z3950_PREFIX.5.107 pdf RECSYN yaz_oid_recsyn_pdf Z3950_PREFIX.5.109.1 postscript RECSYN yaz_oid_recsyn_postscript Z3950_PREFIX.5.109.2 html RECSYN yaz_oid_recsyn_html Z3950_PREFIX.5.109.3 tiff RECSYN yaz_oid_recsyn_tiff Z3950_PREFIX.5.109.4 gif RECSYN yaz_oid_recsyn_gif Z3950_PREFIX.5.109.5 jpeg RECSYN yaz_oid_recsyn_jpeg Z3950_PREFIX.5.109.6 png RECSYN yaz_oid_recsyn_png Z3950_PREFIX.5.109.7 mpeg RECSYN yaz_oid_recsyn_mpeg Z3950_PREFIX.5.109.8 sgml RECSYN yaz_oid_recsyn_sgml Z3950_PREFIX.5.109.9 tiff-b RECSYN yaz_oid_recsyn_tiff_b Z3950_PREFIX.5.110.1 wav RECSYN yaz_oid_recsyn_wav Z3950_PREFIX.5.110.2 SQL-RS RECSYN yaz_oid_recsyn_sql_rs Z3950_PREFIX.5.111 SOIF RECSYN yaz_oid_recsyn_soif Z3950_PREFIX.5.1000.81.2 JSON RECSYN yaz_oid_recsyn_json Z3950_PREFIX.5.1000.81.3 XML RECSYN yaz_oid_recsyn_xml Z3950_PREFIX.5.109.10 text-XML RECSYN yaz_oid_recsyn_text_xml Z3950_PREFIX.5.109.10 application-XML RECSYN yaz_oid_recsyn_application_xml Z3950_PREFIX.5.109.11 Resource-1 RESFORM yaz_oid_resform_resource_1 Z3950_PREFIX.7.1 Resource-2 RESFORM yaz_oid_resform_resource_2 Z3950_PREFIX.7.2 UNIverse-Resource-Report RESFORM yaz_oid_resform_universe_resource_report Z3950_PREFIX.7.1000.81.1 Prompt-1 ACCFORM yaz_oid_accform_prompt_1 Z3950_PREFIX.8.1 Des-1 ACCFORM yaz_oid_accform_des_1 Z3950_PREFIX.8.2 Krb-1 ACCFORM yaz_oid_accform_krb_1 Z3950_PREFIX.8.3 Persistent set EXTSERV yaz_oid_extserv_persistent_set Z3950_PREFIX.9.1 Persistent query EXTSERV yaz_oid_extserv_persistent_query Z3950_PREFIX.9.2 Periodic query EXTSERV yaz_oid_extserv_periodic_query Z3950_PREFIX.9.3 Item order EXTSERV yaz_oid_extserv_item_order Z3950_PREFIX.9.4 Database Update (first version) EXTSERV yaz_oid_extserv_database_update_first_version Z3950_PREFIX.9.5 Database Update (second version) EXTSERV yaz_oid_extserv_database_update_second_version Z3950_PREFIX.9.5.1 Database Update EXTSERV yaz_oid_extserv_database_update Z3950_PREFIX.9.5.1.1 exp. spec. EXTSERV yaz_oid_extserv_exp__spec_ Z3950_PREFIX.9.6 exp. inv. EXTSERV yaz_oid_extserv_exp__inv_ Z3950_PREFIX.9.7 Admin EXTSERV yaz_oid_extserv_admin Z3950_PREFIX.9.1000.81.1 searchResult-1 USERINFO yaz_oid_userinfo_searchresult_1 Z3950_PREFIX.10.1 CharSetandLanguageNegotiation USERINFO yaz_oid_userinfo_charsetandlanguagenegotiation Z3950_PREFIX.10.2 UserInfo-1 USERINFO yaz_oid_userinfo_userinfo_1 Z3950_PREFIX.10.3 MultipleSearchTerms-1 USERINFO yaz_oid_userinfo_multiplesearchterms_1 Z3950_PREFIX.10.4 MultipleSearchTerms-2 USERINFO yaz_oid_userinfo_multiplesearchterms_2 Z3950_PREFIX.10.5 DateTime USERINFO yaz_oid_userinfo_datetime Z3950_PREFIX.10.6 Proxy USERINFO yaz_oid_userinfo_proxy Z3950_PREFIX.10.1000.81.1 Cookie USERINFO yaz_oid_userinfo_cookie Z3950_PREFIX.10.1000.81.2 Client-IP USERINFO yaz_oid_userinfo_client_ip Z3950_PREFIX.10.1000.81.3 Scan-Set USERINFO yaz_oid_userinfo_scan_set Z3950_PREFIX.10.1000.81.4 Facet-1 USERINFO yaz_oid_userinfo_facet_1 Z3950_PREFIX.10.1000.81.5 Espec-1 ELEMSPEC yaz_oid_elemspec_espec_1 Z3950_PREFIX.11.1 Variant-1 VARSET yaz_oid_varset_variant_1 Z3950_PREFIX.12.1 WAIS-schema SCHEMA yaz_oid_schema_wais_schema Z3950_PREFIX.13.1 GILS-schema SCHEMA yaz_oid_schema_gils_schema Z3950_PREFIX.13.2 Collections-schema SCHEMA yaz_oid_schema_collections_schema Z3950_PREFIX.13.3 Geo-schema SCHEMA yaz_oid_schema_geo_schema Z3950_PREFIX.13.4 CIMI-schema SCHEMA yaz_oid_schema_cimi_schema Z3950_PREFIX.13.5 Update ES SCHEMA yaz_oid_schema_update_es Z3950_PREFIX.13.6 Holdings SCHEMA yaz_oid_schema_holdings Z3950_PREFIX.13.7 Zthes SCHEMA yaz_oid_schema_zthes Z3950_PREFIX.13.8 thesaurus-schema SCHEMA yaz_oid_schema_thesaurus_schema Z3950_PREFIX.13.1000.81.1 Explain-schema SCHEMA yaz_oid_schema_explain_schema Z3950_PREFIX.13.1000.81.2 TagsetM TAGSET yaz_oid_tagset_tagsetm Z3950_PREFIX.14.1 TagsetG TAGSET yaz_oid_tagset_tagsetg Z3950_PREFIX.14.2 STAS-tagset TAGSET yaz_oid_tagset_stas_tagset Z3950_PREFIX.14.3 GILS-tagset TAGSET yaz_oid_tagset_gils_tagset Z3950_PREFIX.14.4 Collections-tagset TAGSET yaz_oid_tagset_collections_tagset Z3950_PREFIX.14.5 CIMI-tagset TAGSET yaz_oid_tagset_cimi_tagset Z3950_PREFIX.14.6 thesaurus-tagset TAGSET yaz_oid_tagset_thesaurus_tagset Z3950_PREFIX.14.1000.81.1 Explain-tagset TAGSET yaz_oid_tagset_explain_tagset Z3950_PREFIX.14.1000.81.2 Zthes-tagset TAGSET yaz_oid_tagset_zthes_tagset Z3950_PREFIX.14.8 Charset-3 NEGOT yaz_oid_negot_charset_3 Z3950_PREFIX.15.3 Charset-4 NEGOT yaz_oid_negot_charset_4 Z3950_PREFIX.15.4 Charset-ID NEGOT yaz_oid_negot_charset_id Z3950_PREFIX.15.1000.81.1 CQL USERINFO yaz_oid_userinfo_cql Z3950_PREFIX.16.2 UCS-2 GENERAL yaz_oid_general_ucs_2 1.0.10646.1.0.2 UCS-4 GENERAL yaz_oid_general_ucs_4 1.0.10646.1.0.4 UTF-16 GENERAL yaz_oid_general_utf_16 1.0.10646.1.0.5 UTF-8 GENERAL yaz_oid_general_utf_8 1.0.10646.1.0.8 OCLC-userInfo USERINFO yaz_oid_userinfo_oclc_userinfo Z3950_PREFIX.10.1000.17.1 XML-ES EXTSERV yaz_oid_extserv_xml_es Z3950_PREFIX.9.1000.105.4 yaz-5.37.0/doc/local0.ent.in0000644000175000017500000000003615123757344014105 0ustar00adamadam yaz-5.37.0/doc/yaz-icu.html0000644000175000017500000002013115130444232014046 0ustar00adamadamyaz-icu
yaz-icu
Prev Reference Next

Name

yaz-icu — YAZ ICU utility

Synopsis

yaz-icu [-c config] [-p opt] [-s] [-x] [infile]

DESCRIPTION

yaz-icu is a utility which demonstrates the ICU chain module of yaz. (yaz/icu.h).

The utility can be used in two ways. It may read some text using an XML configuration for configuring ICU and show text analysis. This mode is triggered by option -c which specifies the configuration to be used. The input file is read from standard input or from a file if infile is specified.

The utility may also show ICU information. This is triggered by option -p.

OPTIONS

-c config

Specifies the file containing ICU chain configuration which is XML based.

-p type

Specifies extra information to be printed about the ICU system. If type is c then ICU converters are printed. If type is l, then available locales are printed. If type is t, then available transliterators are printed.

-s

Specifies that output should include sort key as well. Note that sort key differs between ICU versions.

-x

Specifies that output should be XML based rather than "text" based.

ICU chain configuration

The ICU chain configuration specifies one or more rules to convert text data into tokens. The configuration format is XML based.

The toplevel element must be named icu_chain. The icu_chain element has one required attribute locale which specifies the ICU locale to be used in the conversion steps.

The icu_chain element must include elements where each element specifies a conversion step. The conversion is performed in the order in which the conversion steps are specified. Each conversion element takes one attribute: rule which serves as argument to the conversion step.

The following conversion elements are available:

casemap

Converts case (and rule specifies how):

l

Lower case using ICU function u_strToLower.

u

Upper case using ICU function u_strToUpper.

t

To title using ICU function u_strToTitle.

f

Fold case using ICU function u_strFoldCase.

display

This is a meta step which specifies that a term/token is to be displayed. This term is retrieved in an application using function icu_chain_token_display (yaz/icu.h).

transform

Specifies an ICU transform rule using a transliterator Identifier. The rule attribute is the transliterator Identifier. See ICU Transforms for more information.

transliterate

Specifies a rule-based transliterator. The rule attribute is the custom transformation rule to be used. See ICU Transforms for more information.

tokenize

Breaks / tokenizes a string into components using ICU functions ubrk_open, ubrk_setText, .. . The rule is one of:

l

Line. ICU: UBRK_LINE.

s

Sentence. ICU: UBRK_SENTENCE.

w

Word. ICU: UBRK_WORD.

c

Character. ICU: UBRK_CHARACTER.

t

Title. ICU: UBRK_TITLE.

join

Joins tokens into one string. The rule attribute is the joining string, which may be empty. The join conversion element was added in YAZ 4.2.49.

EXAMPLES

The following command analyzes text in file text using ICU chain configuration chain.xml: 

    cat text | yaz-icu -c chain.xml

The chain.xml might look as follows: 

<icu_chain locale="en">
  <transform rule="[:Control:] Any-Remove"/>
  <tokenize rule="w"/>
  <transform rule="[[:WhiteSpace:][:Punctuation:]] Remove"/>
  <transliterate rule="xy > z;"/>
  <display/>
  <casemap rule="l"/>
</icu_chain>

SEE ALSO

yaz(7)

ICU Home

ICU Transforms

Prev Up Next
yaz-illclient Home yaz-url
yaz-5.37.0/doc/local.ent0000644000175000017500000000003315130444212013376 0ustar00adamadam yaz-5.37.0/doc/introduction.html0000644000175000017500000002021115130444232015205 0ustar00adamadamChapter 1. Introduction
Chapter 1. Introduction
Prev   Next

Chapter 1. Introduction

Table of Contents

1. Reading this Manual
2. The API

YAZ is a C/C++ library for information retrieval applications using the Z39.50/SRU/Solr protocols for information retrieval.

Properties of YAZ:

  • Complete Z39.50 version 3 support. Amendments and Z39.50-2002 revision is supported.

  • Supports SRU GET/POST/SOAP version 1.1, 1.2 and 2.0 (over HTTP and HTTPS).

  • Includes BER encoders/decoders for the ISO ILL protocol.

  • Supports Apache Solr Web Service version 1.4.x (client side only)

  • Supports the following transports: BER over TCP/IP (RFC1729), BER over Unix local socket, and HTTP 1.1.

  • Secure Socket Layer support using GnuTLS. If enabled, YAZ uses HTTPS transport (for SOAP) or "Secure BER" (for Z39.50).

  • Offers ZOOM C API implementing Z39.50, SRU and Solr Web Service.

  • The YAZ library offers a set of useful utilities related to the protocols, such as MARC (ISO2709) parser, CCL (ISO8777) parser, CQL parser, memory management routines, character set conversion.

  • Portable code. YAZ compiles out-of-the box on most Unixes and on Windows using Microsoft Visual C++.

  • Fast operation. The C based BER encoders/decoders as well as the server component of YAZ is very fast.

  • Liberal license that allows for commercial use of YAZ.

1. Reading this Manual

Most implementors only need to read a fraction of the material in this manual, so a quick walk-through of the chapters is in order.

  • Chapter 2, Compilation and Installation contains installation instructions for YAZ. You don't need to read this if you expect to download YAZ binaries. However, the chapter contains information about how to make your application link with YAZ.

  • Chapter 3, ZOOM describes the ZOOM API of YAZ. This is definitely worth reading if you wish to develop a Z39.50/SRU client.

  • Chapter 4, Generic server describes the generic front-end server and explains how to develop server Z39.50/SRU applications for YAZ. Obviously worth reading if you're to develop a server.

  • yaz-client(1) describes how to use the YAZ Z39.50 client. If you're a developer and wish to test your server or a server from another party, you might find this chapter useful.

  • Chapter 5, The Z39.50 ASN.1 Module documents the most commonly used Z39.50 C data structures offered by the YAZ API. Client developers using ZOOM and non-Z39.50 implementors may skip this.

  • Chapter 6, SOAP and SRU describes how SRU and SOAP is used in YAZ. Only if you're developing SRU applications this section is a must.

  • Chapter 7, Supporting Tools contains sections for the various tools offered by YAZ. Scan through the material quickly and see what's relevant to you! SRU implementors might find the CQL section particularly useful.

  • Chapter 8, The ODR Module goes through the details of the ODR module which is the work horse that encodes and decodes BER packages. Implementors using ZOOM only, do not need to read this. Most other Z39.50 implementors only need to read the first two sections (Section 1, “Introduction” and Section 2, “Using ODR”).

  • Chapter 9, The COMSTACK Module describes the network layer module COMSTACK. Implementors using ZOOM or the generic front-end server may skip this. Others, presumably, handling client/server communication on their own should read this.

Prev   Next
YAZ User's Guide and Reference Home 2. The API
yaz-5.37.0/doc/yaz-marcdump.html0000644000175000017500000002264215130444232015107 0ustar00adamadamyaz-marcdump
yaz-marcdump
Prev Reference Next

Name

yaz-marcdump — MARC record dump utility

Synopsis

yaz-marcdump [-i format] [-o format] [-f from] [-t to] [-l spec] [-c cfile] [-s prefix] [-C size] [-O offset] [-L limit] [-n] [-p] [-r] [-v] [-V] [file...]

DESCRIPTION

yaz-marcdump reads MARC records from one or more files. It parses each record and supports output in line-format, ISO2709, MARCXML, MARC-in-JSON, MarcXchange as well as Hex output.

This utility parses records ISO2709(raw MARC), line format, MARC-in-JSON format as well as XML if that is structured as MARCXML/MarcXchange.

MARC-in-JSON encoding/decoding is supported in YAZ 5.0.5 and later.

Note

As of YAZ 2.1.18, OAI-MARC is no longer supported. OAI-MARC is deprecated. Use MARCXML instead.

By default, each record is written to standard output in a line format with newline for each field, $x for each sub-field x. The output format may be changed with option -o,

yaz-marcdump can also be requested to perform character set conversion of each record.

OPTIONS

-i format

Specifies input format. Must be one of marcxml, marc (ISO2709), marcxchange (ISO25577), line (line mode MARC), turbomarc (Turbo MARC), or json (MARC-in-JSON).

-o format

Specifies output format. Must be one of marcxml, marc (ISO2709), marcxchange (ISO25577), line (line mode MARC), turbomarc (Turbo MARC), or json (MARC-in-JSON).

-f from

Specify the character set of the input MARC record. Should be used in conjunction with option -t. Refer to the yaz-iconv man page for supported character sets.

-t to

Specify the character set of the output. Should be used in conjunction with option -f. Refer to the yaz-iconv man page for supported character sets.

-l leaderspec

Specify a simple modification string for MARC leader. The leaderspec is a list of pos=value pairs, where pos is an integer offset (0 - 23) for leader. Value is either a quoted string or an integer (character value in decimal). Pairs are comma separated. For example, to set leader at offset 9 to a, use 9='a'.

-s prefix

Writes a chunk of records to a separate file with prefix given, i.e. splits a record batch into files with only at most "chunk" ISO2709 records per file. By default chunk is 1 (one record per file). See option -C.

-C chunksize

Specifies chunk size; to be used conjunction with option -s.

-O offset

Integer offset for at what position records whould be written. 0=first record, 1=second, .. With -L option, this allows a specific range of records to be processed.

-L limit

Integer limit for how many records should at most be written. With -O option, this allows a specific range of records to be processed.

-p

Makes yaz-marcdump print record number and input file offset of each record read.

-n

MARC output is omitted so that MARC input is only checked.

-r

Writes to stderr a summary about number of records read by yaz-marcdump.

-v

Writes more information about the parsing process. Useful if you have ill-formatted ISO2709 records as input.

-V

Prints YAZ version.

EXAMPLES

The following command converts MARC21/USMARC in MARC-8 encoding to MARC21/USMARC in UTF-8 encoding. Leader offset 9 is set to 'a'. Both input and output records are ISO2709 encoded. 

    yaz-marcdump -f MARC-8 -t UTF-8 -o marc -l 9=97 marc21.raw >marc21.utf8.raw

The same records may be converted to MARCXML instead in UTF-8: 

    yaz-marcdump -f MARC-8 -t UTF-8 -o marcxml marc21.raw >marcxml.xml

Turbo MARC is a compact XML notation with same semantics as MARCXML, but which allows for faster processing via XSLT. In order to generate Turbo MARC records encoded in UTF-8 from MARC21 (ISO), one could use: 

    yaz-marcdump -f MARC8 -t UTF8 -o turbomarc -i marc marc21.raw >out.xml

FILES

prefix/bin/yaz-marcdump

prefix/include/yaz/marcdisp.h

SEE ALSO

yaz(7)

yaz-iconv(1)

Prev Up Next
yaz-asncomp Home yaz-iconv
yaz-5.37.0/doc/zoom.scan.html0000644000175000017500000001432215130444232014401 0ustar00adamadam6. Scan
6. Scan
Prev Chapter 3. ZOOM Next

6. Scan

This section describes an interface for Scan. Scan is not an official part of the ZOOM model yet. The result of a scan operation is the ZOOM_scanset which is a set of terms returned by a target.

The Scan interface is supported for both Z39.50, SRU and Solr. 

    ZOOM_scanset ZOOM_connection_scan(ZOOM_connection c,
                                      const char *startpqf);

    ZOOM_scanset ZOOM_connection_scan1(ZOOM_connection c,
                                       ZOOM_query q);

    size_t ZOOM_scanset_size(ZOOM_scanset scan);

    const char *ZOOM_scanset_term(ZOOM_scanset scan, size_t pos,
                                  size_t *occ, size_t *len);

    const char *ZOOM_scanset_display_term(ZOOM_scanset scan, size_t pos,
                                          size_t *occ, size_t *len);

    void ZOOM_scanset_destroy(ZOOM_scanset scan);

    const char *ZOOM_scanset_option_get(ZOOM_scanset scan,
                                        const char *key);

    void ZOOM_scanset_option_set(ZOOM_scanset scan, const char *key,
                                 const char *val);

The scan set is created by function ZOOM_connection_scan which performs a scan operation on the connection using the specified startpqf. If the operation was successful, the size of the scan set can be retrieved by a call to ZOOM_scanset_size. Like result sets, the items are numbered 0..size-1. To obtain information about a particular scan term, call function ZOOM_scanset_term. This function takes a scan set offset pos and returns a pointer to a raw term or NULL if non-present. If present, the occ and len are set to the number of occurrences and the length of the actual term respectively. ZOOM_scanset_display_term is similar to ZOOM_scanset_term except that it returns the display term rather than the raw term. In a few cases, the term is different from display term. Always use the display term for display and the raw term for subsequent scan operations (to get more terms, next scan result, etc).

A scan set may be freed by a call to function ZOOM_scanset_destroy. Functions ZOOM_scanset_option_get and ZOOM_scanset_option_set retrieves and sets an option respectively.

The startpqf is a subset of PQF, namely the Attributes+Term part. Multiple @attr can be used. For example to scan in title (complete) phrases:


     @attr 1=4 @attr 6=2 "science o"
    

The ZOOM_connecton_scan1 is a newer and more generic alternative to ZOOM_connection_scan which allows to use both CQL and PQF for Scan.

Table 3.5. ZOOM Scan Set Options

OptionDescriptionDefault
numberNumber of Scan Terms requested in next scan. After scan it holds the actual number of terms returned. 20
positionPreferred Position of term in response in next scan; actual position after completion of scan. 1
stepSizeStep Size 0
scanStatusAn integer indicating the Scan Status of last scan. 0
rpnCharsetCharacter set for RPN terms. If this is set, ZOOM C will assume that the ZOOM application is running UTF-8. Terms in RPN queries are then converted to the rpnCharset. If this is unset, ZOOM C will not assume any encoding of RPN terms and no conversion is performed. none

Prev Up Next
5. ZOOM Facets Home 7. Extended Services
yaz-5.37.0/doc/tools.retrieval.html0000644000175000017500000005042415130444232015631 0ustar00adamadam6. Retrieval Facility
6. Retrieval Facility
Prev Chapter 7. Supporting Tools Next

6. Retrieval Facility

YAZ version 2.1.20 or later includes a Retrieval facility tool which allows a SRU/Z39.50 to describe itself and perform record conversions. The idea is the following:

  • An SRU/Z39.50 client sends a retrieval request which includes a combination of the following parameters: syntax (format), schema (or element set name).

  • The retrieval facility is invoked with parameters in a server/proxy. The retrieval facility matches the parameters a set of "supported" retrieval types. If there is no match, the retrieval signals an error (syntax and / or schema not supported).

  • For a successful match, the backend is invoked with the same or altered retrieval parameters (syntax, schema). If a record is received from the backend, it is converted to the frontend name / syntax.

  • The resulting record is sent back the client and tagged with the frontend syntax / schema.

The Retrieval facility is driven by an XML configuration. The configuration is neither Z39.50 ZeeRex or SRU ZeeRex. But it should be easy to generate both of them from the XML configuration. (Unfortunately the two versions of ZeeRex differ substantially in this regard.)

6.1. Retrieval XML format

All elements should be covered by namespace http://indexdata.com/yaz . The root element node must be retrievalinfo.

The retrievalinfo must include one or more retrieval elements. Each retrieval defines specific combination of syntax, name and identifier supported by this retrieval service.

The retrieval element may include any of the following attributes:

syntax (REQUIRED)

Defines the record syntax. Possible values is any of the names defined in YAZ' OID database or a raw OID in (n.n ... n).

name (OPTIONAL)

Defines the name of the retrieval format. This can be any string. For SRU, the value is equivalent to schema (short-hand); for Z39.50 it's equivalent to simple element set name. For YAZ 3.0.24 and later this name may be specified as a glob expression with operators * and ?.

identifier (OPTIONAL)

Defines the URI schema name of the retrieval format. This can be any string. For SRU, the value is equivalent to URI schema. For Z39.50, there is no equivalent.

The retrieval may include one backend element. If a backend element is given, it specifies how the records are retrieved by some backend and how the records are converted from the backend to the "frontend".

The attributes, name and syntax may be specified for the backend element. The semantics of these attributes is equivalent to those for the retrieval. However, these values are passed to the "backend".

The backend element may include one or more conversion instructions (as children elements). The supported conversions are:

marc

The marc element specifies a conversion to - and from ISO2709 encoded MARC and MARCXML/MarcXchange. The following attributes may be specified:

inputformat (REQUIRED)

Format of input. Supported values are marc (for ISO2709), xml (MARCXML/MarcXchange) and json (MARC-in-JSON).

outputformat (REQUIRED)

Format of output. Supported values are line (MARC line format); marcxml (for MARCXML), marc (ISO2709), turbomarc, marcxchange (for MarcXchange), or json (MARC-in-JSON ).

inputcharset (OPTIONAL)

Encoding of input. For XML input formats, this need not be given, but for ISO2709 based input formats, this should be set to the encoding used. For MARC21 records, a common inputcharset value would be marc-8.

Note

If inputformat is marc and inputcharset is marc-8, then effective inputcharset is UTF-8 if leader position has value 'a' (MARC21 rule).

outputcharset (OPTIONAL)

Encoding of output. If outputformat is XML based, it is strongly recommended to use utf-8.

leaderspec (OPTIONAL)

Specifies a modification to the leader for the resulting output record. The leaderspec is a comma separated list of pos=value pairs, where pos is an integer offset (0 - 23) for leader. Value is either a quoted string or an integer (character value in decimal). For example, to set leader at offset 9 to a, use 9='a'. This has same effect as -l for yaz-marcdump(1).

select

The select selects one or more text nodes and decodes them as XML. The following attributes may be specified:

path (REQUIRED)

X-Path expression for selecting text nodes.

This conversion is available in YAZ 5.8.0 and later.

solrmarc

The solrmarc decodes solrmarc records. It assumes that the input is pure solrmarc text (no escaping) and will convert all sequences of the form #XX; to a single character of the hexadecimal value as given by XX. The output, presumably, is a valid ISO2709 buffer.

This conversion is available in YAZ 5.0.21 and later.

xslt

The xslt element specifies a conversion via XSLT. The following attributes may be specified:

stylesheet (REQUIRED)

Stylesheet file.

In addition, the element can be configured as follows:

param (OPTIONAL)

A param tag configures a parameter to be passed to the XSLT stylesheet. Multiple param tags may be defined.

rdf-lookup

The rdf-lookup element looks up BIBFRAME elements in some suitable service, for example http://id.loc.gov/authorities/names and replaces the URIs for specified elements with URIs it finds at that service. Its configuration consists of

debug (OPTIONAL)

Attribute to the rdf-lookup tag to enable debug output. A value of "1" makes the filter to add a XML comment next to each key it tried to look up, showing the URL, the result, and timing. This is useful for debugging the configuration. The default is not to add any comments.

timeout (OPTIONAL)

Attribute of the rdf-lookup tag which defines timeout in seconds for the HTTP based rdf-lookup.

namespace (OPTIONAL)

A namespace tag declares a namespace to be used in the xpath below. The tag requires two attributes: prefix and href.

lookup (REQUIRED)

A section that defines one tag to be looked up, for example an author.The xpath attribute (REQUIRED) specifies the path to the element(s).

key (REQUIRED)

A tag withing the lookup tag specifies the value to be used in the lookup, for example a name or an ID. It is a relative Xpath starting from the tag specified in the lookup.

server (OPTIONAL)

Specifies the URL for server to use for the lookup. A %s is replaced by the key value to be looked up. If not specified, defaults to the same as the previous lookup section, or lacking one, to http://id.loc.gov/authorities/names/label/%s . The method attribute can be used to specify the HTTP method to be used in this lookup. The default is GET, and the useful alternative is HEAD.

See the example below.

This conversion is available in YAZ 5.19.0 and later.

6.2. Retrieval Facility Examples

Example 7.19. MARC21 backend

A typical way to use the retrieval facility is to enable XML for servers that only supports ISO2709 encoded MARC21 records. 

     <retrievalinfo>
       <retrieval syntax="usmarc" name="F"/>
       <retrieval syntax="usmarc" name="B"/>
       <retrieval syntax="xml" name="marcxml"
		  identifier="info:srw/schema/1/marcxml-v1.1">
         <backend syntax="usmarc" name="F">
	   <marc inputformat="marc" outputformat="marcxml"
		 inputcharset="marc-8"/>
	 </backend>
       </retrieval>
       <retrieval syntax="xml" name="dc">
         <backend syntax="usmarc" name="F">
	   <marc inputformat="marc" outputformat="marcxml"
		 inputcharset="marc-8"/>
           <xslt stylesheet="MARC21slim2DC.xsl"/>
	 </backend>
       </retrieval>
     </retrievalinfo>

This means that our frontend supports:

  • MARC21 F(ull) records.

  • MARC21 B(rief) records.

  • MARCXML records.

  • Dublin core records.


Example 7.20. MARCXML backend

SRW/SRU and Solr backends return records in XML. If they return MARCXML or MarcXchange, the retrieval module can convert those into ISO2709 formats, most commonly USMARC (AKA MARC21). In this example, the backend returns MARCXML for schema="marcxml". 

     <retrievalinfo>
       <retrieval syntax="usmarc">
         <backend syntax="xml" name="marcxml">
	   <marc inputformat="xml" outputformat="marc"
		 outputcharset="marc-8"/>
	 </backend>
       </retrieval>
       <retrieval syntax="xml" name="marcxml"
		  identifier="info:srw/schema/1/marcxml-v1.1"/>
       <retrieval syntax="xml" name="dc">
         <backend syntax="xml" name="marcxml">
           <xslt stylesheet="MARC21slim2DC.xsl"/>
	 </backend>
       </retrieval>
     </retrievalinfo>

This means that our frontend supports:

  • MARC21 records (any element set name) in MARC-8 encoding.

  • MARCXML records for element-set=marcxml

  • Dublin core records for element-set=dc.


Example 7.21. RDF-lookup backend

This is a minimal example of the backend configuration for the rdf-lookup. It could well be used with some heavy xslt transforms that make BIBFRAME records out of MarxXml. 

        <backend syntax="xml" name="rdf-lookup">
          <rdf-lookup debug="1" timeout="10">
            <namespace prefix="bf" href="http://id.loc.gov/ontologies/bibframe/" />
            <namespace prefix="bflc" href="http://id.loc.gov/ontologies/bibframe/lc-extensions/"/>
            <lookup xpath="//bf:contribution/bf:Contribution/bf:agent/bf:Agent">
              <key field="bflc:name00MatchKey"/>
              <key field="bflc:name01MatchKey"/>
              <key field="bflc:name11MatchKey"/>
              <server url="http://id.loc.gov/authorities/names/label/%s" method="HEAD"/>
            </lookup>
          </rdf-lookup>
        </backend>

The debug=1 attribute tells the filter to add XML comments to the key nodes that indicate what lookup it tried to do, how it went, and how long it took.

The namespace prefix bf: is defined in the namespace tags. These namespaces are used in the xpath expressions in the lookup sections.

The lookup tag specifies one tag to be looked up. The xpath attribute defines which node to modify. It may make use of the namespace definitions above.

The server tag gives the URL to be used for the lookup. A %s in the string will get replaced by the key value. If there is no server tag, the one from the preceding lookup section is used, and if there is no previous section, the id.loc.gov address is used as a default. The default is to make a GET request, this example uses HEAD


6.3. API

It should be easy to use the retrieval systems from applications. Refer to the headers yaz/retrieval.h and yaz/record_conv.h.

Prev Up Next
5. MARC Home 7. Sorting
yaz-5.37.0/doc/installation.html0000644000175000017500000001171615130444232015177 0ustar00adamadamChapter 2. Compilation and Installation
Chapter 2. Compilation and Installation
Prev   Next

Chapter 2. Compilation and Installation

Table of Contents

1. Introduction
2. UNIX/macOS
2.1. Compiling from source on Unix
2.2. Compiling from source on macOS
2.3. How to make apps using YAZ on UNIX
3. Windows
3.1. Compiling from Source on Windows
3.2. How to make apps using YAZ on Windows
3.3. Compiling Libxml2 and Libxslt on windows

1. Introduction

The latest version of the software will generally be found at:

https://ftp.indexdata.com/pub/yaz/

We have tried our best to keep the software portable, and on many platforms, you should be able to compile everything with little or no changes.

The software is regularly tested on Debian GNU/Linux, CentOS, Ubuntu Linux, FreeBSD (i386), MAC OSX, Windows 10.

Some versions have be known to work on Windows XP, Solaris, HP/UX, DEC Unix, NetBSD, OpenBSD, IBM AIX, Data General DG/UX (with some CFLAGS tinkering), SGI/IRIX, DDE Supermax, Apple Macintosh (using the Codewarrior programming environment and the GUSI socket libraries), IBM AS/400 .

If you move the software to other platforms, we'd be grateful if you'd let us know about it. If you run into difficulties, we will try to help if we can, and if you solve the problems, we would be happy to include your fixes in the next release. So far, we have mostly avoided #ifdefs for individual platforms, and we'd like to keep it that way as far as it makes sense.

Use GitHub Discussions for questions and discussions about YAZ. General questions and problems can be directed to mailto:info@indexdata.com.

Prev   Next
2. The API Home 2. UNIX/macOS
yaz-5.37.0/doc/yaz-log-man.xml0000644000175000017500000002447015123757344014503 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-log 7 Conventions and miscellaneous yaz-log Log handling in all yaz-based programs yaz-XXXX DESCRIPTION All YAZ-based programs use a common log subsystem, and should support common command line options for controlling it. This man page documents those. OPTIONS -l logfile Specify the file where the log is to be written. If none is specified, stderr is used. The log is appended to this file. If the file grows overly large, it is silently rotated: It is renamed to logfile.1, logfile.2, .., 9 (old such file is deleted), and a new file is opened. The limit defaults to 1GB, but can be set by the program. The rotating limit can be specified with option -r for the YAZ frontend server (yaz-ztest). Rotation can also be implicitly enabled by using a filename which gets changed for a given date, due to substitutions as given by the strftime(3) function. -v loglevel Specify the logging level. The argument is a set of log level names, separated by commas (no whitespace!), optionally preceded by a '-' to negate that level. Most programs have their own default, often containing fatal,warn,log, and some application-specific values. The default list can be cleared with the word none, or individual bits can be removed by prefixing them with a dash '-'. LOG LEVELS TO CONTROL LOGGING Some of the log levels control the way the log is written. flush causes the log to be flushed after every write. This can have serious implications to performance, and should not be used in production. On the other hand, when debugging a program crash, this can be extremely useful. The option debug implies flush as well. notime prevents the writing of time stamps. This is intended for automatic test scripts, which should produce predictable log files that are easy to compare. GENERAL LOG LEVELS IN YAZ ITSELF YAZ itself uses the following log levels: fatal for fatal errors, that prevent further execution of the program. warn for warnings about things that should be corrected. debug for debugging. This flag may be used temporarily when developing or debugging yaz, or a program that uses yaz. It is practically deprecated, you should be defining and using your own log levels (see below). all turns on almost all hard-coded log levels. loglevel logs information about the log levels used by the program. Every time the log level is changed, lists all bits that are on. Every time a module asks for its log bits, this is logged. This can be used for getting an idea of what log levels are available in any program that uses yaz-log. Start the program with -v none,loglevel, and do some common operations with it. Another way is to grep for yaz_log_module_level in the source code, as in find . -name '*.[ch]' -print | xargs grep yaz_log_module_level | grep '"' | cut -d'"' -f2 | sort -u eventl, malloc, nmem, odr are used internally for debugging yaz. LOG LEVELS FOR CLIENTS zoom logs the calls to the zoom API, which may be useful in debugging client applications. LOG LEVELS FOR SERVERS server logs the server functions on a high level, starting up, listening on a port, etc. session logs individual sessions (connections). request logs a one-liner for each request (init, search, etc.). requestdetail logs the details of every request, before it is passed to the back-end, and the results received from it. Each server program (zebra, etc.) is supposed to define its own log levels in addition to these. As they depend on the server in question, they can not be described here. See above how to find out about them. LOGGING EXAMPLES See what log levels yaz-ztest is using: yaz-ztest -1 -v none,loglevel 14:43:29-23/11 [loglevel] Setting log level to 4096 = 0x00001000 14:43:29-23/11 [loglevel] Static log bit 00000001 'fatal' is off 14:43:29-23/11 [loglevel] Static log bit 00000002 'debug' is off 14:43:29-23/11 [loglevel] Static log bit 00000004 'warn' is off 14:43:29-23/11 [loglevel] Static log bit 00000008 'log' is off 14:43:29-23/11 [loglevel] Static log bit 00000080 'malloc' is off 14:43:29-23/11 [loglevel] Static log bit 00000800 'flush' is off 14:43:29-23/11 [loglevel] Static log bit 00001000 'loglevel' is ON 14:43:29-23/11 [loglevel] Static log bit 00002000 'server' is off 14:43:29-23/11 [loglevel] Dynamic log bit 00004000 'session' is off 14:43:29-23/11 [loglevel] Dynamic log bit 00008000 'request' is off 14:44:13-23/11 yaz-ztest [loglevel] returning log bit 0x4000 for 'session' 14:44:13-23/11 yaz-ztest [loglevel] returning log bit 0x2000 for 'server' 14:44:13-23/11 yaz-ztest [loglevel] returning NO log bit for 'eventl' 14:44:20-23/11 yaz-ztest [loglevel] returning log bit 0x4000 for 'session' 14:44:20-23/11 yaz-ztest [loglevel] returning log bit 0x8000 for 'request' 14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'requestdetail' 14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'odr' 14:44:20-23/11 yaz-ztest [loglevel] returning NO log bit for 'ztest' See the details of the requests for yaz-ztest ./yaz-ztest -1 -v requestdetail 14:45:35-23/11 yaz-ztest [server] Adding static Z3950 listener on tcp:@:9999 14:45:35-23/11 yaz-ztest [server] Starting server ./yaz-ztest pid=32200 14:45:38-23/11 yaz-ztest [session] Starting session from tcp:127.0.0.1 (pid=32200) 14:45:38-23/11 yaz-ztest [requestdetail] Got initRequest 14:45:38-23/11 yaz-ztest [requestdetail] Id: 81 14:45:38-23/11 yaz-ztest [requestdetail] Name: YAZ 14:45:38-23/11 yaz-ztest [requestdetail] Version: 2.0.28 14:45:38-23/11 yaz-ztest [requestdetail] Negotiated to v3: srch prst del extendedServices namedresults scan sort 14:45:38-23/11 yaz-ztest [request] Init from 'YAZ' (81) (ver 2.0.28) OK 14:45:39-23/11 yaz-ztest [requestdetail] Got SearchRequest. 14:45:39-23/11 yaz-ztest [requestdetail] ResultSet '1' 14:45:39-23/11 yaz-ztest [requestdetail] Database 'Default' 14:45:39-23/11 yaz-ztest [requestdetail] RPN query. Type: Bib-1 14:45:39-23/11 yaz-ztest [requestdetail] term 'foo' (general) 14:45:39-23/11 yaz-ztest [requestdetail] resultCount: 7 14:45:39-23/11 yaz-ztest [request] Search Z: @attrset Bib-1 foo OK:7 hits 14:45:41-23/11 yaz-ztest [requestdetail] Got PresentRequest. 14:45:41-23/11 yaz-ztest [requestdetail] Request to pack 1+1 1 14:45:41-23/11 yaz-ztest [requestdetail] pms=1048576, mrs=1048576 14:45:41-23/11 yaz-ztest [request] Present: [1] 1+1 OK 1 records returned LOG FILENAME EXAMPLES A file with format my_YYYYMMDD.log (where Y, M, D is year, month, and day digits) is given as follows: -l my_%Y%m%d.log . And since the filename is depending on day, rotation will occur on midnight. A weekly log could be specified as -l my_%Y%U.log. FILES prefix/include/yaz/log.h prefix/src/log.c SEE ALSO yaz 7 yaz-ztest 8 yaz-client 1 strftime 3 yaz-5.37.0/doc/tools.nmem.html0000644000175000017500000001036215130444232014565 0ustar00adamadam3. Nibble Memory
3. Nibble Memory
Prev Chapter 7. Supporting Tools Next

3. Nibble Memory

Sometimes when you need to allocate and construct a large, interconnected complex of structures, it can be a bit of a pain to release the associated memory again. For the structures describing the Z39.50 PDUs and related structures, it is convenient to use the memory-management system of the ODR subsystem (see Section 2, “Using ODR”). However, in some circumstances where you might otherwise benefit from using a simple nibble-memory management system, it may be impractical to use odr_malloc() and odr_reset(). For this purpose, the memory manager which also supports the ODR streams is made available in the NMEM module. The external interface to this module is given in the nmem.h file.

The following prototypes are given: 

    NMEM nmem_create(void);
    void nmem_destroy(NMEM n);
    void *nmem_malloc(NMEM n, size_t size);
    void nmem_reset(NMEM n);
    size_t nmem_total(NMEM n);
    void nmem_init(void);
    void nmem_exit(void);

The nmem_create() function returns a pointer to a memory control handle, which can be released again by nmem_destroy() when no longer needed. The function nmem_malloc() allocates a block of memory of the requested size. A call to nmem_reset() or nmem_destroy() will release all memory allocated on the handle since it was created (or since the last call to nmem_reset(). The function nmem_total() returns the number of bytes currently allocated on the handle.

The nibble-memory pool is shared amongst threads. POSIX mutexes and WIN32 Critical sections are introduced to keep the module thread safe. Function nmem_init() initializes the nibble-memory library and it is called automatically the first time the YAZ.DLL is loaded. YAZ uses function DllMain to achieve this. You should not call nmem_init or nmem_exit unless you're absolute sure what you're doing. Note that in previous YAZ versions you'd have to call nmem_init yourself.

Prev Up Next
2. Object Identifiers Home 4. Log
yaz-5.37.0/doc/license.html0000644000175000017500000000720715130444232014120 0ustar00adamadamAppendix D. License
Appendix D. License
Prev   Next

Appendix D. License

Table of Contents

1. Index Data Copyright

1. Index Data Copyright

Copyright © 1995-2026 Index Data.

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

  • Neither the name of Index Data nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY INDEX DATA ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL INDEX DATA BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Prev   Next
Appendix C. SRU diagnostics Home Appendix E. About Index Data
yaz-5.37.0/doc/yaz-icu.10000644000175000017500000001262715130444227013261 0ustar00adamadam'\" t .\" Title: yaz-icu .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-ICU" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-icu \- YAZ ICU utility .SH "SYNOPSIS" .HP \w'\fByaz\-icu\fR\ 'u \fByaz\-icu\fR [\-c\ \fIconfig\fR] [\-p\ \fIopt\fR] [\-s] [\-x] [infile] .SH "DESCRIPTION" .PP \fByaz\-icu\fR is a utility which demonstrates the ICU chain module of yaz\&. (yaz/icu\&.h)\&. .PP The utility can be used in two ways\&. It may read some text using an XML configuration for configuring ICU and show text analysis\&. This mode is triggered by option \-c which specifies the configuration to be used\&. The input file is read from standard input or from a file if infile is specified\&. .PP The utility may also show ICU information\&. This is triggered by option \-p\&. .SH "OPTIONS" .PP \-c \fIconfig\fR .RS 4 Specifies the file containing ICU chain configuration which is XML based\&. .RE .PP \-p \fItype\fR .RS 4 Specifies extra information to be printed about the ICU system\&. If \fItype\fR is c then ICU converters are printed\&. If \fItype\fR is l, then available locales are printed\&. If \fItype\fR is t, then available transliterators are printed\&. .RE .PP \-s .RS 4 Specifies that output should include sort key as well\&. Note that sort key differs between ICU versions\&. .RE .PP \-x .RS 4 Specifies that output should be XML based rather than "text" based\&. .RE .SH "ICU CHAIN CONFIGURATION" .PP The ICU chain configuration specifies one or more rules to convert text data into tokens\&. The configuration format is XML based\&. .PP The toplevel element must be named icu_chain\&. The icu_chain element has one required attribute locale which specifies the ICU locale to be used in the conversion steps\&. .PP The icu_chain element must include elements where each element specifies a conversion step\&. The conversion is performed in the order in which the conversion steps are specified\&. Each conversion element takes one attribute: rule which serves as argument to the conversion step\&. .PP The following conversion elements are available: .PP casemap .RS 4 Converts case (and rule specifies how): .PP l .RS 4 Lower case using ICU function u_strToLower\&. .RE .PP u .RS 4 Upper case using ICU function u_strToUpper\&. .RE .PP t .RS 4 To title using ICU function u_strToTitle\&. .RE .PP f .RS 4 Fold case using ICU function u_strFoldCase\&. .RE .sp .RE .PP display .RS 4 This is a meta step which specifies that a term/token is to be displayed\&. This term is retrieved in an application using function icu_chain_token_display (yaz/icu\&.h)\&. .RE .PP transform .RS 4 Specifies an ICU transform rule using a transliterator Identifier\&. The rule attribute is the transliterator Identifier\&. See \m[blue]\fBICU Transforms\fR\m[]\&\s-2\u[1]\d\s+2 for more information\&. .RE .PP transliterate .RS 4 Specifies a rule\-based transliterator\&. The rule attribute is the custom transformation rule to be used\&. See \m[blue]\fBICU Transforms\fR\m[]\&\s-2\u[1]\d\s+2 for more information\&. .RE .PP tokenize .RS 4 Breaks / tokenizes a string into components using ICU functions ubrk_open, ubrk_setText, \&.\&. \&. The rule is one of: .PP l .RS 4 Line\&. ICU: UBRK_LINE\&. .RE .PP s .RS 4 Sentence\&. ICU: UBRK_SENTENCE\&. .RE .PP w .RS 4 Word\&. ICU: UBRK_WORD\&. .RE .PP c .RS 4 Character\&. ICU: UBRK_CHARACTER\&. .RE .PP t .RS 4 Title\&. ICU: UBRK_TITLE\&. .RE .sp .RE .PP join .RS 4 Joins tokens into one string\&. The rule attribute is the joining string, which may be empty\&. The join conversion element was added in YAZ 4\&.2\&.49\&. .RE .SH "EXAMPLES" .PP The following command analyzes text in file text using ICU chain configuration chain\&.xml: .sp .if n \{\ .RS 4 .\} .nf cat text | yaz\-icu \-c chain\&.xml .fi .if n \{\ .RE .\} .sp The chain\&.xml might look as follows: .sp .if n \{\ .RS 4 .\} .nf .fi .if n \{\ .RE .\} .sp .SH "SEE ALSO" .PP \fByaz\fR(7) .PP \m[blue]\fBICU Home\fR\m[]\&\s-2\u[2]\d\s+2 .PP \m[blue]\fBICU Transforms\fR\m[]\&\s-2\u[1]\d\s+2 .SH "AUTHORS" .PP \fBIndex Data\fR .SH "NOTES" .IP " 1." 4 ICU Transforms .RS 4 \%https://unicode-org.github.io/icu/userguide/transforms/general/ .RE .IP " 2." 4 ICU Home .RS 4 \%https://github.com/unicode-org/icu .RE yaz-5.37.0/doc/marc.html0000644000175000017500000002233215130444232013414 0ustar00adamadam5. MARC
5. MARC
Prev Chapter 7. Supporting Tools Next

5. MARC

YAZ provides a fast utility for working with MARC records. Early versions of the MARC utility only allowed decoding of ISO2709. Today the utility may both encode - and decode to a variety of formats. 

    #include <yaz/marcdisp.h>

    /* create handler */
    yaz_marc_t yaz_marc_create(void);
    /* destroy */
    void yaz_marc_destroy(yaz_marc_t mt);

    /* set XML mode YAZ_MARC_LINE, YAZ_MARC_SIMPLEXML, ... */
    void yaz_marc_xml(yaz_marc_t mt, int xmlmode);
    #define YAZ_MARC_LINE      0
    #define YAZ_MARC_SIMPLEXML 1
    #define YAZ_MARC_OAIMARC   2
    #define YAZ_MARC_MARCXML   3
    #define YAZ_MARC_ISO2709   4
    #define YAZ_MARC_XCHANGE   5
    #define YAZ_MARC_CHECK     6
    #define YAZ_MARC_TURBOMARC 7
    #define YAZ_MARC_JSON      8

    /* supply iconv handle for character set conversion .. */
    void yaz_marc_iconv(yaz_marc_t mt, yaz_iconv_t cd);

    /* set debug level, 0=none, 1=more, 2=even more, .. */
    void yaz_marc_debug(yaz_marc_t mt, int level);

    /* decode MARC in buf of size bsize. Returns >0 on success; <=0 on failure.
    On success, result in *result with size *rsize. */
    int yaz_marc_decode_buf(yaz_marc_t mt, const char *buf, int bsize,
                            const char **result, size_t *rsize);

    /* decode MARC in buf of size bsize. Returns >0 on success; <=0 on failure.
       On success, result in WRBUF */
    int yaz_marc_decode_wrbuf(yaz_marc_t mt, const char *buf,
                              int bsize, WRBUF wrbuf);

Note

The synopsis is just a basic subset of all functionality. Refer to the actual header file marcdisp.h for details.

A MARC conversion handle must be created by using yaz_marc_create and destroyed by calling yaz_marc_destroy.

All other functions operate on a yaz_marc_t handle. The output is specified by a call to yaz_marc_xml. The xmlmode must be one of

YAZ_MARC_LINE

A simple line-by-line format suitable for display but not recommended for further (machine) processing.

YAZ_MARC_MARCXML

MARCXML.

YAZ_MARC_ISO2709

ISO2709 (sometimes just referred to as "MARC").

YAZ_MARC_XCHANGE

MarcXchange.

YAZ_MARC_CHECK

Pseudo format for validation only. Does not generate any real output except diagnostics.

YAZ_MARC_TURBOMARC

XML format with same semantics as MARCXML but more compact and geared towards fast processing with XSLT. Refer to Section 5.1, “TurboMARC” for more information.

YAZ_MARC_JSON

MARC-in-JSON format.

The actual conversion functions are yaz_marc_decode_buf and yaz_marc_decode_wrbuf which decodes and encodes a MARC record. The former function operates on simple buffers, and stores the resulting record in a WRBUF handle (WRBUF is a simple string type).

Example 7.18. Display of MARC record

The following program snippet illustrates how the MARC API may be used to convert a MARC record to the line-by-line format: 

      void print_marc(const char *marc_buf, int marc_buf_size)
      {
         char *result;      /* for result buf */
         size_t result_len;    /* for size of result */
         yaz_marc_t mt = yaz_marc_create();
         yaz_marc_xml(mt, YAZ_MARC_LINE);
         yaz_marc_decode_buf(mt, marc_buf, marc_buf_size,
                             &result, &result_len);
         fwrite(result, result_len, 1, stdout);
         yaz_marc_destroy(mt);  /* note that result is now freed... */
      }


5.1. TurboMARC

TurboMARC is yet another XML encoding of a MARC record. The format was designed for fast processing with XSLT.

Applications like Pazpar2 uses XSLT to convert an XML encoded MARC record to an internal representation. This conversion mostly checks the tag of a MARC field to determine the basic rules in the conversion. This check is costly when that tag is encoded as an attribute in MARCXML. By having the tag value as the element instead, makes processing many times faster (at least for Libxslt).

TurboMARC is encoded as follows:

  • Record elements is part of namespace "http://www.indexdata.com/turbomarc".

  • A record is enclosed in element r.

  • A collection of records is enclosed in element collection.

  • The leader is encoded as element l with the leader content as its (text) value.

  • A control field is encoded as element c concatenated with the tag value of the control field if the tag value matches the regular expression [a-zA-Z0-9]*. If the tag value does not match the regular expression [a-zA-Z0-9]* the control field is encoded as element c and attribute code will hold the tag value. This rule ensures that in the rare cases where a tag value might result in a non-well-formed XML, then YAZ will encode it as a coded attribute (as in MARCXML).

    The control field content is the text value of this element. Indicators are encoded as attribute names i1, i2, etc. and corresponding values for each indicator.

  • A data field is encoded as element d concatenated with the tag value of the data field or using the attribute code as described in the rules for control fields. The children of the data field element are subfield elements. Each subfield element is encoded as s concatenated with the sub field code. The text of the subfield element is the contents of the subfield. Indicators are encoded as attributes for the data field element, similar to the encoding for control fields.

Prev Up Next
4. Log Home 6. Retrieval Facility
yaz-5.37.0/doc/yaz-config.10000644000175000017500000000477115130444225013745 0ustar00adamadam'\" t .\" Title: yaz-config .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-CONFIG" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-config \- Script to get information about YAZ\&. .SH "SYNOPSIS" .HP \w'\fByaz\-config\fR\ 'u \fByaz\-config\fR [\fB\-\-prefix[=\fR\fB\fIDIR\fR\fR\fB]\fR] [\fB\-\-version\fR] [\fB\-\-libs\fR] [\fB\-\-lalibs\fR] [\fB\-\-cflags\fR] [\fB\-\-include\fR] [\fB\-\-comp\fR] [\fB\-V\fR] [libraries...] .SH "DESCRIPTION" .PP \fByaz\-config\fR is a script that returns information that your own software should use to build software that uses YAZ\&. .PP The following libraries are supported: .PP threads .RS 4 Use the threaded version of YAZ\&. .RE .SH "OPTIONS" .PP \-\-prefix[=\fIDIR\fR] .RS 4 Returns prefix of YAZ or assume a different one if DIR is specified\&. .RE .PP \-\-version .RS 4 Returns version of YAZ\&. .RE .PP \-\-libs .RS 4 Library specification be used when using YAZ\&. .RE .PP \-\-lalibs .RS 4 Return library specification\&. .RE .PP \-\-cflags .RS 4 Return C Compiler flags\&. .RE .PP \-\-include .RS 4 Return C compiler includes for YAZ header files (\-Ipath)\&. .RE .PP \-\-comp .RS 4 Returns full path to YAZ\*(Aq ASN\&.1 compiler: yaz\-asncomp\&. .RE .PP \-V .RS 4 Returns YAZ SHA1 ID (from Git) and version\&. .RE .SH "FILES" .PP /usr/bin/yaz\-config .PP /usr/lib/libyaz*\&.a .PP /usr/include/yaz/*\&.h .SH "SEE ALSO" .PP yaz(7) .PP Section "How to make apps using YAZ on UNIX" in the YAZ manual\&. .SH "AUTHORS" .PP \fBIndex Data\fR yaz-5.37.0/doc/asn.pdu.html0000644000175000017500000004645515130444232014056 0ustar00adamadam4. PDU Contents Table
4. PDU Contents Table
Prev Chapter 5. The Z39.50 ASN.1 Module Next

4. PDU Contents Table

We include, for reference, a listing of the fields of each top-level PDU, as well as their default settings.

Table 5.1. Default settings for PDU Initialize Request

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
protocolVersionOdr_bitmaskEmpty bitmask
optionsOdr_bitmaskEmpty bitmask
preferredMessageSizeOdr_int30*1024
maximumRecordSizeOdr_int30*1024
idAuthenticationZ_IdAuthenticationNULL
implementationIdchar*"81"
implementationNamechar*"YAZ"
implementationVersionchar*YAZ_VERSION
userInformationFieldZ_UserInformationNULL
otherInfoZ_OtherInformationNULL

Table 5.2. Default settings for PDU Initialize Response

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
protocolVersionOdr_bitmaskEmpty bitmask
optionsOdr_bitmaskEmpty bitmask
preferredMessageSizeOdr_int30*1024
maximumRecordSizeOdr_int30*1024
resultOdr_boolTRUE
implementationIdchar*"id)"
implementationNamechar*"YAZ"
implementationVersionchar*YAZ_VERSION
userInformationFieldZ_UserInformationNULL
otherInfoZ_OtherInformationNULL

Table 5.3. Default settings for PDU Search Request

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
smallSetUpperBoundOdr_int0
largeSetLowerBoundOdr_int1
mediumSetPresentNumberOdr_int0
replaceIndicatorOdr_boolTRUE
resultSetNamechar *"default"
num_databaseNamesOdr_int0
databaseNameschar **NULL
smallSetElementSetNamesZ_ElementSetNames NULL
mediumSetElementSetNamesZ_ElementSetNames NULL
preferredRecordSyntaxOdr_oidNULL
queryZ_QueryNULL
additionalSearchInfoZ_OtherInformation NULL
otherInfoZ_OtherInformationNULL

Table 5.4. Default settings for PDU Search Response

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
resultCountOdr_int0
numberOfRecordsReturnedOdr_int0
nextResultSetPositionOdr_int0
searchStatusOdr_boolTRUE
resultSetStatusOdr_intNULL
presentStatusOdr_intNULL
recordsZ_RecordsNULL
additionalSearchInfoZ_OtherInformationNULL
otherInfoZ_OtherInformationNULL

Table 5.5. Default settings for PDU Present Request

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
resultSetIdchar*"default"
resultSetStartPointOdr_int1
numberOfRecordsRequestedOdr_int10
num_rangesOdr_int0
additionalRangesZ_RangeNULL
recordCompositionZ_RecordCompositionNULL
preferredRecordSyntaxOdr_oidNULL
maxSegmentCountOdr_intNULL
maxRecordSizeOdr_intNULL
maxSegmentSizeOdr_intNULL
otherInfoZ_OtherInformationNULL

Table 5.6. Default settings for PDU Present Response

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
numberOfRecordsReturnedOdr_int0
nextResultSetPositionOdr_int0
presentStatusOdr_intZ_PresentStatus_success
recordsZ_RecordsNULL
otherInfoZ_OtherInformationNULL

Table 5.7. Default settings for Delete Result Set Request

FieldTypeDefault Value
referenceId Z_ReferenceIdNULL
deleteFunctionOdr_intZ_DeleteResultSetRequest_list
num_idsOdr_int0
resultSetListchar**NULL
otherInfoZ_OtherInformationNULL

Table 5.8. Default settings for Delete Result Set Response

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
deleteOperationStatusOdr_intZ_DeleteStatus_success
num_statusesOdr_int0
deleteListStatusesZ_ListStatus**NULL
numberNotDeletedOdr_intNULL
num_bulkStatusesOdr_int0
bulkStatusesZ_ListStatusNULL
deleteMessagechar*NULL
otherInfoZ_OtherInformationNULL

Table 5.9. Default settings for Scan Request

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
num_databaseNamesOdr_int0
databaseNameschar**NULL
attributeSetOdr_oidNULL
termListAndStartPointZ_AttributesPlus... NULL
stepSizeOdr_intNULL
numberOfTermsRequestedOdr_int20
preferredPositionInResponseOdr_intNULL
otherInfoZ_OtherInformationNULL

Table 5.10. Default settings for Scan Response

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
stepSizeOdr_intNULL
scanStatusOdr_intZ_Scan_success
numberOfEntriesReturnedOdr_int0
positionOfTermOdr_intNULL
entriesZ_ListEntriesNULL
attributeSetOdr_oidNULL
otherInfoZ_OtherInformationNULL

Table 5.11. Default settings for Trigger Resource Control Request

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
requestedActionOdr_int Z_TriggerResourceCtrl_resou..
prefResourceReportFormatOdr_oidNULL
resultSetWantedOdr_boolNULL
otherInfoZ_OtherInformationNULL

Table 5.12. Default settings for Resource Control Request

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
suspendedFlagOdr_boolNULL
resourceReportZ_ExternalNULL
partialResultsAvailableOdr_intNULL
responseRequiredOdr_boolFALSE
triggeredRequestFlagOdr_boolNULL
otherInfoZ_OtherInformationNULL

Table 5.13. Default settings for Resource Control Response

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
continueFlagbool_tTRUE
resultSetWantedbool_tNULL
otherInfoZ_OtherInformationNULL

Table 5.14. Default settings for Access Control Request

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
whichenumZ_AccessRequest_simpleForm;
uunionNULL
otherInfoZ_OtherInformationNULL

Table 5.15. Default settings for Access Control Response

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
whichenumZ_AccessResponse_simpleForm
uunionNULL
diagnosticZ_DiagRecNULL
otherInfoZ_OtherInformationNULL

Table 5.16. Default settings for Segment

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
numberOfRecordsReturnedOdr_intvalue=0
num_segmentRecordsOdr_int0
segmentRecordsZ_NamePlusRecordNULL
otherInfoZ_OtherInformationNULL

Table 5.17. Default settings for Close

FieldTypeDefault Value
referenceIdZ_ReferenceIdNULL
closeReasonOdr_intZ_Close_finished
diagnosticInformationchar*NULL
resourceReportFormatOdr_oidNULL
resourceFormatZ_ExternalNULL
otherInfoZ_OtherInformationNULL

Prev Up Next
3. EXTERNAL Data Home Chapter 6. SOAP and SRU
yaz-5.37.0/doc/yaz-record-conv.10000644000175000017500000000524015130444230014705 0ustar00adamadam'\" t .\" Title: yaz-record-iconv .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-RECORD\-ICONV" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-record-conv \- YAZ Record Conversion Utility .SH "SYNOPSIS" .HP \w'\fByaz\-record\-conv\fR\ 'u \fByaz\-record\-conv\fR [\fB\-v\ \fR\fB\fIloglevel\fR\fR] [\fIconfig\fR] [\fIfname\fR...] .SH "DESCRIPTION" .PP \fByaz\-record\-conv\fR is a program that exercises the record conversion sub system\&. Refer to record_conv\&.h header\&. .SH "OPTIONS" .PP \-v \fIlevel\fR .RS 4 Sets the LOG level to \fIlevel\fR\&. Level is a sequence of tokens separated by comma\&. Each token is a integer or a named LOG item \- one of fatal, debug, warn, log, malloc, all, none\&. .RE .SH "EXAMPLES" .PP The following backend configuration converts MARC records (ISO2709) to Dublin\-Core XML\&. .sp .if n \{\ .RS 4 .\} .nf .fi .if n \{\ .RE .\} .PP We can convert one of the sample records from YAZ\*(Aq test directory with: .sp .if n \{\ .RS 4 .\} .nf $ \&.\&./util/yaz\-record\-conv record\-conv\-conf\&.xml marc6\&.marc How to program a computer Jack Collins text Penguin eng .fi .if n \{\ .RE .\} .sp .SH "FILES" .PP record_conv\&.h .SH "SEE ALSO" .PP yaz(7) .SH "AUTHORS" .PP \fBIndex Data\fR yaz-5.37.0/doc/yaz-ztest.html0000644000175000017500000005760515130444232014457 0ustar00adamadamyaz-ztest
yaz-ztest
Prev Reference Next

Name

yaz-ztest — Z39.50/SRU Test Server

Synopsis

application [-install] [-installa] [-remove] [-a file] [-v level] [-l file] [-u uid] [-c config] [-f vconfig] [-C fname] [-t minutes] [-k kilobytes] [-K] [-d daemon] [-w dir] [-p pidfile] [-r kilobytes] [-ziDSTV1] [listener-spec...]

DESCRIPTION

yaz-ztest is a Z39.50/SRU test server that uses the YAZ generic front-end server (GFS) API. The server acts as a real Z39.50/SRU server but does not use a database. It returns a random hit count and returns a subset of a few built-in records.

The listener-spec consists of a transport mode followed by a colon, followed by a listener address. The transport mode is either tcp, unix, or ssl.

For TCP and SSL, an address has the form: 

    hostname | IP-number [ : portnumber ]

For UNIX local socket, the address is the filename of the local socket.

OPTIONS

-a file

Specify a file for dumping PDUs (for diagnostic purposes). The special name - (dash) sends output to stderr.

-S

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.

-1

Like -S but after one session the server exits. This mode is for debugging only.

-T

Operate the server in threaded mode. The server creates a thread for each connection rather than fork a process. Only available on UNIX systems that offer POSIX threads.

-s

Use the SR protocol (obsolete).

-z

Use the Z39.50 protocol (default). This option and -s 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.

-l file

The logfile.

-c config

A user option that serves as a specifier for some sort of configuration, usually a filename. The argument to this option is transferred to member configname of the statserv_options_block.

-f vconfig

This specifies an XML file that describes one or more YAZ frontend virtual servers.

-C fname

Sets SSL certificate file name for server (PEM).

-v level

The log level. Use a comma-separated list of members of the set {fatal,debug,warn,log,malloc,all,none}.

-u uid

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.

-w dir

The server changes to this directory before listening to incoming connections. This option is useful when the server is operating from the inetd daemon (see -i).

-p pidfile

Specifies that the server should write its Process ID to the file given by pidfile. A typical location would be /var/run/yaz-ztest.pid.

-i

Use this to make the the server run from the inetd server (UNIX only).

-D

Use this to make the server put itself in the background and run as a daemon. If neither -i nor -D is given, the server starts in the foreground.

-install

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.

-installa

Use this to install the server as an NT service and mark it as "auto-start. Control the server by going to the Services in the Control Panel.

-remove

Use this to remove the server from the NT services (Windows NT/2000/XP only).

-t minutes

Idle session timeout, in minutes.

-k size

Maximum record size/message size, in kilobytes.

-K

Forces no-keepalive for HTTP sessions. By default GFS will keep sessions alive for HTTP 1.1 sessions (as defined by the standard). Using this option will force GFS to close the connection for each operation.

-r size

Maximum size of log file before rotation occurs, in kilobytes. Default size is 1048576 k (=1 GB).

-d daemon

Set name of daemon to be used in hosts access file. See hosts_access(5) and tcpd(8).

-m time-format

Sets the format of time-stamps in the log-file. Specify a string in the input format to strftime().

-V

Display YAZ version and exit.

TESTING

yaz-ztest normally returns a random hit count between 0 and 24. However, if a query term includes leading digits, then the integer value of that term is used as hit count. This allows testers to return any number of hits. yaz-ztest includes 24 MARC records for testing. Hit counts exceeding 24 will make yaz-ztest return the same record batch over and over. So record at position 1, 25, 49, etc. are equivalent.

For XML, if no element set is given or element has value "marcxml", MARCXML is returned (each of the 24 dummy records converted from ISO2709 to XML). For element set OP, then OPAC XML is returned.

yaz-ztest may also return predefined XML records (for testing). This is enabled if YAZ_ZTEST_XML_FETCH environment variable is defined. A record is fetched from a file (one record per file). The path for the filename is FE.d.xml where F is the YAZ_ZTEST_XML_FETCH value (possibly empty), E is element-set, d is record position (starting from 1).

The following databases are honored by yaz-ztest: Default, slow and db.* (all databases with prefix "db"). Any other database will make yaz-ztest return diagnostic 109: "Database unavailable".

Options for search may be included in the form or URL get arguments included as part of the Z39.50 database name. The following database options are present: search-delay, present-delay, fetch-delay and seed.

The former, delay type options, specify a fake delay (sleep) that yaz-ztest will perform when searching, presenting, fetching records respectively. The value of the delay may either be a fixed floating point value which specifies the delay in seconds. Alternatively the value may be given as two floating point numbers separated by colon, which will make yaz-ztest perform a random sleep between the first and second number.

The database parameter seed takes an integer as value. This will call srand with this integer to ensure that the random behavior can be re-played.

Suppose we want searches to take between 0.1 and 0.5 seconds and a fetch to take 0.2 second. To access test database Default we'd use: Default?search-delay=0.1:0.5&fetch-delay=0.2.

GFS CONFIGURATION AND VIRTUAL HOSTS

The Virtual hosts mechanism allows a YAZ front-end server to support multiple back-ends. A back-end is selected on the basis of the TCP/IP binding (port+listening address) and/or the virtual host.

A back-end can be configured to execute in a particular working directory. Or the YAZ front-end may perform CQL to RPN conversion, thus allowing traditional Z39.50 back-ends to be offered as a SRW/SRU service. SRW/SRU Explain information for a particular back-end may also be specified.

For the HTTP protocol, the virtual host is specified in the Host header. For the Z39.50 protocol, the virtual host is specified as in the Initialize Request in the OtherInfo, OID 1.2.840.10003.10.1000.81.1.

Note

Not all Z39.50 clients allow the VHOST information to be set. For those, the selection of the back-end must rely on the TCP/IP information alone (port and address).

The YAZ front-end server uses XML to describe the back-end configurations. Command-line option -f specifies filename of the XML configuration.

The configuration uses the root element yazgfs. This element includes a list of listen elements, followed by one or more server elements.

The listen describes listener (transport end point), such as TCP/IP, Unix file socket or SSL server. Content for a listener:

CDATA (required)

The CDATA for the listen element holds the listener string, such as tcp:@:210, tcp:server1:2100, etc.

attribute id (optional)

Identifier for this listener. This may be referred to from server sections.

Note

We expect more information to be added for the listen section in a future version, such as CERT file for SSL servers.

The server describes a server and the parameters for this server type. Content for a server:

attribute id (optional)

Identifier for this server. Currently not used for anything, but it might be for logging purposes.

attribute listenref (optional)

Specifies one or more listeners for this server. Each server ID is separated by a comma. If this attribute is not given, the server is accessible from all listeners. In order for the server to be used for real, however, the virtual host must match if specified in the configuration.

element config (optional)

Specifies the server configuration. This is equivalent to the config specified using command line option -c.

element directory (optional)

Specifies a working directory for this backend server. If specified, the YAZ 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).

element host (optional)

Specifies the virtual host for this server. If this is specified a client must specify this host string in order to use this backend.

element cql2rpn (optional)

Specifies a filename that includes CQL to RPN conversion for this backend server. See Section 1.3.4, “Specification of CQL to RPN mappings”. If given, the backend server will only "see" a Type-1/RPN query.

element ccl2rpn (optional)

Specifies a filename that includes CCL to RPN conversion for this backend server. See Section 1.2.2, “CCL Qualifiers”. If given, the backend server will only "see" a Type-1/RPN query.

element stylesheet (optional)

Specifies the stylesheet reference to be part of SRU HTTP responses when the client does not specify one. If none is given, then if the client does not specify one, then no stylesheet reference is part of the SRU HTTP response.

element client_query_charset (optional)

If specified, a conversion from the character set given to UTF-8 is performed by the generic frontend server. It is only executed for Z39.50 search requests (SRU/Solr are assumed to be UTF-8 encoded already).

element docpath (optional)

Specifies a path for local file access using HTTP. All URLs with a leading prefix (/ excluded) that matches the value of docpath are used for file access. For example, if the server is to offer access in directory xsl, the docpath would be xsl and all URLs of the form http://host/xsl will result in a local file access.

element explain (optional)

Specifies SRW/SRU ZeeRex content for this server. Copied verbatim to the client. As things are now, some of the Explain content seem redundant because host information, etc. is also stored elsewhere.

element maximumrecordsize (optional)

Specifies maximum record size/message size, in bytes. This value also serves as the maximum size of incoming packages (for Record Updates etc). It's the same value as that given by the -k option.

element retrievalinfo (optional)

Enables the retrieval facility to support conversions and specifications of record formats/types. See Section 6, “Retrieval Facility” for more information.

The XML 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 public and the other server internal. 

  
 <yazgfs>
  <listen id="public">tcp:@:9900</listen>
  <listen id="internal">unix:/var/tmp/socket</listen>
  <server id="server1">
    <host>server1.mydomain</host>
    <directory>/var/www/s1</directory>
    <config>config.cfg</config>
  </server>
  <server id="server2" listenref="public,internal">
    <host>server2.mydomain</host>
    <directory>/var/www/s2</directory>
    <config>config.cfg</config>
    <cql2rpn>../etc/pqf.properties</cql2rpn>
    <explain xmlns="http://explain.z3950.org/dtd/2.0/">
      <serverInfo>
        <host>server2.mydomain</host>
        <port>9900</port>
        <database>a</database>
      </serverInfo>
    </explain>
  </server>
  <server id="server3" listenref="internal">
    <directory>/var/www/s3</directory>
    <config>config.cfg</config>
  </server>
 </yazgfs>

There are three configured backend servers. The first two servers, "server1" and "server2", can be reached by both listener addresses. "server1" is reached by all (two) since no listenref attribute is specified. "server2" is reached by the two listeners specified. In order to distinguish between the two, a virtual host has been specified for each server in the host elements.

For "server2" elements for CQL to RPN conversion is supported and explain information has been added (a short one here to keep the example small).

The third server, "server3" can only be reached via listener "internal".

FILES

yaz-<version>/ztest/yaz-ztest.c

yaz-<version>/include/yaz/backend.h

SEE ALSO

yaz(7) yaz-log(7)

Prev Up Next
yaz-client Home yaz-config
yaz-5.37.0/doc/sru-diagnostics.html0000644000175000017500000002025115130444232015606 0ustar00adamadamAppendix C. SRU diagnostics
Appendix C. SRU diagnostics
Prev   Next

Appendix C. SRU diagnostics

List of SRU diagnostics that are known to YAZ.

CodeText
1 Permanent system error
2 System temporarily unavailable
3 Authentication error
4 Unsupported operation
5 Unsupported version
6 Unsupported parameter value
7 Mandatory parameter not supplied
8 Unsupported parameter
10 Query syntax error
11 Unsupported query type
12 Too many characters in query
13 Invalid or unsupported use of parentheses
14 Invalid or unsupported use of quotes
15 Unsupported context set
16 Unsupported index
17 Unsupported combination of index and context set
18 Unsupported combination of indexes
19 Unsupported relation
20 Unsupported relation modifier
21 Unsupported combination of relation modifiers
22 Unsupported combination of relation and index
23 Too many characters in term
24 Unsupported combination of relation and term
25 Special characters not quoted in term
26 Non special character escaped in term
27 Empty term unsupported
28 Masking character not supported
29 Masked words too short
30 Too many masking characters in term
31 Anchoring character not supported
32 Anchoring character in unsupported position
33 Combination of proximity/adjacency and masking characters not supported
34 Combination of proximity/adjacency and anchoring characters not supported
35 Term contains only stopwords
36 Term in invalid format for index or relation
37 Unsupported boolean operator
38 Too many boolean operators in query
39 Proximity not supported
40 Unsupported proximity relation
41 Unsupported proximity distance
42 Unsupported proximity unit
43 Unsupported proximity ordering
44 Unsupported combination of proximity modifiers
45 Prefix assigned to multiple identifiers
46 Unsupported boolean modifier
47 Cannot process query; reason unknown
48 Query feature unsupported
49 Masking character in unsupported position
50 Result sets not supported
51 Result set does not exist
52 Result set temporarily unavailable
53 Result sets only supported for retrieval
54 Retrieval may only occur from an existing result set
55 Combination of result sets with search terms not supported
56 Only combination of single result set with search terms supported
57 Result set created but no records available
58 Result set created with unpredictable partial results available
59 Result set created with valid partial results available
60 Result set not created: too many matching records
61 First record position out of range
62 Negative number of records requested
63 System error in retrieving records
64 Record temporarily unavailable
65 Record does not exist
66 Unknown schema for retrieval
67 Record not available in this schema
68 Not authorised to send record
69 Not authorised to send record in this schema
70 Record too large to send
71 Unsupported record packing
72 XPath retrieval unsupported
73 XPath expression contains unsupported feature
74 Unable to evaluate XPath expression
80 Sort not supported
81 Unsupported sort type
82 Unsupported sort sequence
83 Too many records to sort
84 Too many sort keys to sort
85 Duplicate sort keys
86 Cannot sort: incompatible record formats
87 Unsupported schema for sort
88 Unsupported path for sort
89 Path unsupported for schema
90 Unsupported direction value
91 Unsupported case value
92 Unsupported missing value action
93 Sort ended due to missing value
100 Explain not supported
101 Explain request type not supported (SOAP vs GET)
102 Explain record temporarily unavailable
110 Stylesheets not supported
111 Unsupported stylesheet
120 Response position out of range
121 Too many terms requested
235 Database does not exist
236 Access to specified database denied
1015 Init/AC: Maximum number of simultaneous sessions for Userid
1074 Proxy failure
Prev   Next
Appendix B. Bib-1 diagnostics Home Appendix D. License
yaz-5.37.0/doc/soap.srw.html0000644000175000017500000001101715130444232014244 0ustar00adamadam4. SRU
4. SRU
Prev Chapter 6. SOAP and SRU Next

4. SRU

SRU SOAP is just one implementation of a SOAP handler as described in the previous section. The encoder/decoder handler for SRU is defined as follows: 

#include <yaz/srw.h>

int yaz_srw_codec(ODR o, void * pptr,
                  Z_SRW_GDU **handler_data,
                  void *client_data, const char *ns);

Here, Z_SRW_GDU is either searchRetrieveRequest or a searchRetrieveResponse.

Note

The xQuery and xSortKeys are not handled yet by the SRW implementation of YAZ. Explain is also missing. Future versions of YAZ will include these features.

The definition of searchRetrieveRequest is: 

typedef struct {

#define Z_SRW_query_type_cql  1
#define Z_SRW_query_type_xcql 2
#define Z_SRW_query_type_pqf  3
    int query_type;
    union {
        char *cql;
        char *xcql;
        char *pqf;
    } query;

#define Z_SRW_sort_type_none 1
#define Z_SRW_sort_type_sort 2
#define Z_SRW_sort_type_xSort 3
    int sort_type;
    union {
        char *none;
        char *sortKeys;
        char *xSortKeys;
    } sort;
    int  *startRecord;
    int  *maximumRecords;
    char *recordSchema;
    char *recordPacking;
    char *database;
} Z_SRW_searchRetrieveRequest;

Please observe that data of type xsd:string is represented as a char pointer (char *). A null pointer means that the element is absent. Data of type xsd:integer is represented as a pointer to an int (int *). Again, a null pointer is used for absent elements.

The SearchRetrieveResponse has the following definition. 

typedef struct {
    int * numberOfRecords;
    char * resultSetId;
    int * resultSetIdleTime;

    Z_SRW_record *records;
    int num_records;

    Z_SRW_diagnostic *diagnostics;
    int num_diagnostics;
    int *nextRecordPosition;
} Z_SRW_searchRetrieveResponse;

The num_records and num_diagnostics is number of returned records and diagnostics respectively, and also correspond to the "size of" arrays records and diagnostics.

A retrieval record is defined as follows: 

typedef struct {
    char *recordSchema;
    char *recordData_buf;
    int recordData_len;
    int *recordPosition;
} Z_SRW_record;

The record data is defined as a buffer of some length so that data can be of any type. SRW 1.0 currently doesn't allow for this (only XML), but future versions might do.

And, a diagnostic as: 

typedef struct {
    int  *code;
    char *details;
} Z_SRW_diagnostic;

Prev Up Next
3. SOAP Packages Home Chapter 7. Supporting Tools
yaz-5.37.0/doc/odr.use.html0000644000175000017500000005043515130444232014056 0ustar00adamadam2. Using ODR
2. Using ODR
Prev Chapter 8. The ODR Module Next

2. Using ODR

2.1. ODR Streams

Conceptually, the ODR stream is the source of encoded data in the decoding mode; when encoding, it is the receptacle for the encoded data. Before you can use an ODR stream it must be allocated. This is done with the function 

     ODR odr_createmem(int direction);

The odr_createmem() function takes as argument one of three manifest constants: ODR_ENCODE, ODR_DECODE, or ODR_PRINT. An ODR stream can be in only one mode - it is not possible to change its mode once it's selected. Typically, your program will allocate at least two ODR streams - one for decoding, and one for encoding.

When you're done with the stream, you can use 

     void odr_destroy(ODR o);

to release the resources allocated for the stream.

2.2. Memory Management

Two forms of memory management take place in the ODR system. The first one, which has to do with allocating little bits of memory (sometimes quite large bits of memory, actually) when a protocol package is decoded, and turned into a complex of interlinked structures. This section deals with this system, and how you can use it for your own purposes. The next section deals with the memory management which is required when encoding data - to make sure that a large enough buffer is available to hold the fully encoded PDU.

The ODR module has its own memory management system, which is used whenever memory is required. Specifically, it is used to allocate space for data when decoding incoming PDUs. You can use the memory system for your own purposes, by using the function 

     void *odr_malloc(ODR o, size_t size);

You can't use the normal free(2) routine to free memory allocated by this function, and ODR doesn't provide a parallel function. Instead, you can call 

     void odr_reset(ODR o);

when you are done with the memory: Everything allocated since the last call to odr_reset() is released. The odr_reset() call is also required to clear up an error condition on a stream.

The function 

     size_t odr_total(ODR o);

returns the number of bytes allocated on the stream since the last call to odr_reset().

The memory subsystem of ODR is fairly efficient at allocating and releasing little bits of memory. Rather than managing the individual, small bits of space, the system maintains a free-list of larger chunks of memory, which are handed out in small bits. This scheme is generally known as a nibble-memory system. It is very useful for maintaining short-lived constructions such as protocol PDUs.

If you want to retain a bit of memory beyond the next call to odr_reset(), you can use the function 

     ODR_MEM odr_extract_mem(ODR o);

This function will give you control of the memory recently allocated on the ODR stream. The memory will live (past calls to odr_reset()), until you call the function 

     void odr_release_mem(ODR_MEM p);

The opaque ODR_MEM handle has no other purpose than referencing the memory block for you until you want to release it.

You can use odr_extract_mem() repeatedly between allocating data, to retain individual control of separate chunks of data.

2.3. Encoding and Decoding Data

When encoding data, the ODR stream will write the encoded octet string in an internal buffer. To retrieve the data, use the function 

     char *odr_getbuf(ODR o, int *len, int *size);

The integer pointed to by len is set to the length of the encoded data, and a pointer to that data is returned. *size is set to the size of the buffer (unless size is null, signaling that you are not interested in the size). The next call to a primitive function using the same ODR stream will overwrite the data, unless a different buffer has been supplied using the call 

     void odr_setbuf(ODR o, char *buf, int len, int can_grow);

which sets the encoding (or decoding) buffer used by o to buf, using the length len. Before a call to an encoding function, you can use odr_setbuf() to provide the stream with an encoding buffer of sufficient size (length). The can_grow parameter tells the encoding ODR stream whether it is allowed to use realloc(2) to increase the size of the buffer when necessary. The default condition of a new encoding stream is equivalent to the results of calling 

     odr_setbuf(stream, 0, 0, 1);

In this case, the stream will allocate and reallocate memory as necessary. The stream reallocates memory by repeatedly doubling the size of the buffer - the result is that the buffer will typically reach its maximum, working size with only a small number of reallocation operations. The memory is freed by the stream when the latter is destroyed, unless it was assigned by the user with the can_grow parameter set to zero (in this case, you are expected to retain control of the memory yourself).

To assume full control of an encoded buffer, you must first call odr_getbuf() to fetch the buffer and its length. Next, you should call odr_setbuf() to provide a different buffer (or a null pointer) to the stream. In the simplest case, you will reuse the same buffer over and over again, and you will just need to call odr_getbuf() after each encoding operation to get the length and address of the buffer. Note that the stream may reallocate the buffer during an encoding operation, so it is necessary to retrieve the correct address after each encoding operation.

It is important to realize that the ODR stream will not release this memory when you call odr_reset(): It will merely update its internal pointers to prepare for the encoding of a new data value. When the stream is released by the odr_destroy() function, the memory given to it by odr_setbuf will be released only if the can_grow parameter to odr_setbuf() was nonzero. The can_grow parameter, in other words, is a way of signaling who is to own the buffer, you or the ODR stream. If you never call odr_setbuf() on your encoding stream, which is typically the case, the buffer allocated by the stream will belong to the stream by default.

When you wish to decode data, you should first call odr_setbuf(), to tell the decoding stream where to find the encoded data, and how long the buffer is (the can_grow parameter is ignored by a decoding stream). After this, you can call the function corresponding to the data you wish to decode (e.g. odr_integer() odr z_APDU()).

Example 8.1. Encoding and decoding functions

      int odr_integer(ODR o, Odr_int **p, int optional, const char *name);

      int z_APDU(ODR o, Z_APDU **p, int optional, const char *name);

If the data is absent (or doesn't match the tag corresponding to the type), the return value will be either 0 or 1 depending on the optional flag. If optional is 0 and the data is absent, an error flag will be raised in the stream, and you'll need to call odr_reset() before you can use the stream again. If optional is nonzero, the pointer pointed to/ by p will be set to the null value, and the function will return 1. The name argument is used to pretty-print the tag in question. It may be set to NULL if pretty-printing is not desired.

If the data value is found where it's expected, the pointer pointed to by the p argument will be set to point to the decoded type. The space for the type will be allocated and owned by the ODR stream, and it will live until you call odr_reset() on the stream. You cannot use free(2) to release the memory. You can decode several data elements (by repeated calls to odr_setbuf() and your decoding function), and new memory will be allocated each time. When you do call odr_reset(), everything decoded since the last call to odr_reset() will be released.

Example 8.2. Encoding and decoding of an integer

The use of the double indirection can be a little confusing at first (its purpose will become clear later on, hopefully), so an example is in order. We'll encode an integer value, and immediately decode it again using a different stream. A useless, but informative operation. 

void do_nothing_useful(Odr_int value)
{
    ODR encode, decode;
    Odr_int *valp, *resvalp;
    char *bufferp;
    int len;

    /* allocate streams */
    if (!(encode = odr_createmem(ODR_ENCODE)))
        return;
    if (!(decode = odr_createmem(ODR_DECODE)))
        return;

    valp = &value;
    if (odr_integer(encode, &valp, 0, 0) == 0)
    {
        printf("encoding went bad\n");
        return;
    }
    bufferp = odr_getbuf(encode, &len, 0);
    printf("length of encoded data is %d\n", len);

    /* now let's decode the thing again */
    odr_setbuf(decode, bufferp, len, 0);
    if (odr_integer(decode, &resvalp, 0, 0) == 0)
    {
        printf("decoding went bad\n");
        return;
    }
    /* ODR_INT_PRINTF format for printf (such as %d) */
    printf("the value is " ODR_INT_PRINTF "\n", *resvalp);

    /* clean up */
    odr_destroy(encode);
    odr_destroy(decode);
}

This looks like a lot of work, offhand. In practice, the ODR streams will typically be allocated once, in the beginning of your program (or at the beginning of a new network session), and the encoding and decoding will only take place in a few, isolated places in your program, so the overhead is quite manageable.


2.4. Printing

When an ODR stream is created of type ODR_PRINT the ODR module will print the contents of a PDU in a readable format. By default output is written to the stderr stream. This behavior can be changed, however, by calling the function 

      odr_setprint(ODR o, FILE *file);

before encoders or decoders are being invoked. It is also possible to direct the output to a buffer (or indeed another file), by using the more generic mechanism: 

      void odr_set_stream(ODR o, void *handle,
                         void (*stream_write)(ODR o, void *handle, int type,
                                              const char *buf, int len),
                         void (*stream_close)(void *handle));

Here the user provides an opaque handle and two handlers, stream_write for writing, and stream_close which is supposed to close/free resources associated with handle. The stream_close handler is optional and if NULL for the function is provided, it will not be invoked. The stream_write takes the ODR handle as parameter, the user-defined handle, a type ODR_OCTETSTRING, ODR_VISIBLESTRING which indicates the type of contents being written.

Another utility useful for diagnostics (error handling) or as part of the printing facilities is: 

      const char **odr_get_element_path(ODR o);

which returns a list of current elements that ODR deals with at the moment. For the returned array, say ar, then ar[0] is the top level element, ar[n] is the last. The last element has the property that ar[n+1] == NULL.

Example 8.3. Element Path for record

For a database record part of a PresentResponse the array returned by odr_get_element is presentResponse, databaseOrSurDiagnostics, ?, record, ?, databaseRecord . The question mark appears due to unnamed constructions.


2.5. Diagnostics

The encoding/decoding functions all return 0 when an error occurs. Until you call odr_reset(), you cannot use the stream again, and any function called will immediately return 0.

To provide information to the programmer or administrator, the function 

     void odr_perror(ODR o, char *message);

is provided, which prints the message argument to stderr along with an error message from the stream.

You can also use the function 

     int odr_geterror(ODR o);

to get the current error number from the screen. The number will be one of these constants:

Table 8.1. ODR Error codes

codeDescription
OMEMORYMemory allocation failed.
OSYSERRA system- or library call has failed. The standard diagnostic variable errno should be examined to determine the actual error.
OSPACENo more space for encoding. This will only occur when the user has explicitly provided a buffer for an encoding stream without allowing the system to allocate more space.
OREQUIREDThis is a common protocol error; A required data element was missing during encoding or decoding.
OUNEXPECTEDAn unexpected data element was found during decoding.
OOTHEROther error. This is typically an indication of misuse of the ODR system by the programmer, and also that the diagnostic system isn't as good as it should be, yet.

The character string array 

     char *odr_errlist[]

can be indexed by the error code to obtain a human-readable representation of the problem.

2.6. Summary and Synopsis

     #include <yaz/odr.h>

     ODR odr_createmem(int direction);

     void odr_destroy(ODR o);

     void odr_reset(ODR o);

     char *odr_getbuf(ODR o, int *len, int *size);

     void odr_setbuf(ODR o, char *buf, int len, int can_grow);

     void *odr_malloc(ODR o, int size);

     NMEM odr_extract_mem(ODR o);

     int odr_geterror(ODR o);

     void odr_perror(ODR o, const char *message);

     extern char *odr_errlist[];
Prev Up Next
Chapter 8. The ODR Module Home 3. Programming with ODR
yaz-5.37.0/doc/zoomsh.10000644000175000017500000000677315130444226013223 0ustar00adamadam'\" t .\" Title: zoomsh .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "ZOOMSH" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" zoomsh \- ZOOM shell .SH "SYNOPSIS" .HP \w'\fBzoomsh\fR\ 'u \fBzoomsh\fR [\fB\-a\ \fR\fB\fIapdufile\fR\fR] [\fB\-e\fR] [\fB\-v\ \fR\fB\fIloglevel\fR\fR] [commands...] .SH "DESCRIPTION" .PP \fBzoomsh\fR is a ZOOM client with a simple command line interface\&. The client demonstrates the ZOOM API and is useful for testing targets\&. .PP You may pass one or more commands to \fBzoomsh\fR\&. These commands are invoked first\&. .SH "OPTIONS" .PP \-a \fIapdufile\fR .RS 4 Logs protocol packages into apdufile (APDU log)\&. .RE .PP \-e .RS 4 Makes zoomsh stop processing commands as soon as an error occur\&. The exit code of zoomsh is 1 if error occurs; 0 otherwise\&. .RE .PP \-v \fIloglevel\fR .RS 4 Sets YAZ log level to \fIloglevel\fR\&. .RE .SH "EXAMPLES" .PP If you start the \fByaz\-ztest\fR in one console you can use the ZOOM shell as follows: .sp .if n \{\ .RS 4 .\} .nf $ zoomsh ZOOM>connect localhost:9999 ZOOM>search computer localhost:9999: 7 hits ZOOM>show 0 1 1 Default USmarc 001 11224466 003 DLC 005 00000000000000\&.0 008 910710c19910701nju 00010 eng 010 $a 11224466 040 $a DLC $c DLC 050 00 $a 123\-xyz 100 10 $a Jack Collins 245 10 $a How to program a computer 260 1 $a Penguin 263 $a 8710 300 $a p\&. cm\&. ZOOM>quit .fi .if n \{\ .RE .\} .PP You can also achieve the same result by passing the commands as arguments on a single command line: .PP $ zoomsh "connect localhost:9999" "search computer" "show 0 1" quit .SH "COMMANDS" .PP connect \fIzurl\fR .RS 4 Connects to the target given by \fIzurl\fR\&. .RE .PP close [\fIzurl\fR] .RS 4 Closes connection to target given by \fIzurl\fR or all targets if \fIzurl\fR was omitted\&. .RE .PP show [\fIstart\fR [\fIcount\fR]] .RS 4 Displays count records starting at offset given by \fIstart\fR\&. First records has offset 0 (unlike the Z39\&.50 protocol)\&. .RE .PP quit .RS 4 Quits \fBzoomsh\fR\&. .RE .PP set \fIname\fR [\fIvalue\fR] .RS 4 Sets option \fIname\fR to \fIvalue\fR\&. .RE .PP get \fIname\fR .RS 4 Prints value of option \fIname\fR\&. .RE .PP help .RS 4 Prints list of available commands\&. .RE .SH "SEE ALSO" .PP \fByaz\fR(7), \fByaz-ztest\fR(8), .PP Section "Building clients with ZOOM" in the YAZ manual\&. .PP \m[blue]\fBZOOM home page\fR\m[]\&\s-2\u[1]\d\s+2\&. .SH "AUTHORS" .PP \fBIndex Data\fR .SH "NOTES" .IP " 1." 4 ZOOM home page .RS 4 \%http://zoom.z3950.org/ .RE yaz-5.37.0/doc/comstack.client.html0000644000175000017500000000501015130444232015545 0ustar00adamadam4. Client Side
4. Client Side
Prev Chapter 9. The COMSTACK Module Next

4. Client Side

    int cs_connect(COMSTACK handle, void *address);

Initiate a connection with the target at address (more on addresses below). The function will return 0 on success, and 1 if the operation does not complete immediately (this will only happen on a nonblocking endpoint). In this case, use cs_rcvconnect to complete the operation, when select(2) or poll(2) reports input pending on the association. 

    int cs_rcvconnect(COMSTACK handle);

Complete a connect operation initiated by cs_connect(). It will return 0 on success; 1 if the operation has not yet completed (in this case, call the function again later); -1 if an error has occurred.

Prev Up Next
3. Common Functions Home 5. Server Side
yaz-5.37.0/doc/yaz-url-man.xml0000644000175000017500000000752315123757344014524 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-url 1 Commands yaz-url YAZ URL fetch utility yaz-url -H name:value -m method -O fname -p fname -R num -u user/password -v -x proxy url DESCRIPTION yaz-url is utility to get web content. It is very limited in functionality compared to programs such as curl, wget. The options must precede the URL given on the command line, to take effect. Fetched HTTP content is written to stdout, unless option -O is given. OPTIONS -H name:value Specifies HTTP header content with name and value. This option can be given multiple times (for different names, of course). -m method Specifies the HTTP method to be used for the next URL. Default is method "GET". However, option -p sets it to "POST". -O fname Sets output filename for HTTP content. -p fname Sets a file to be POSTed in the following URL. -R num Sets maximum number of HTTP redirects to be followed. A value of zero disables follow of HTTP redirects. -u user/password Specifies a user and a password to be used in HTTP basic authentication in the following URL fetch. The user and password must be separated by a slash (thus it is not possible to specify a user with a slash in it). -v Makes yaz-url dump each HTTP request/response to stdout. -x proxy Specifies a proxy to be used for URL fetch. SEE ALSO yaz 7 yaz-5.37.0/doc/zoomsh-man.xml0000644000175000017500000001257215123757344014440 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data zoomsh 1 Commands zoomsh ZOOM shell zoomsh commands DESCRIPTION zoomsh is a ZOOM client with a simple command line interface. The client demonstrates the ZOOM API and is useful for testing targets. You may pass one or more commands to zoomsh. These commands are invoked first. OPTIONS -a apdufile Logs protocol packages into apdufile (APDU log). -e Makes zoomsh stop processing commands as soon as an error occur. The exit code of zoomsh is 1 if error occurs; 0 otherwise. -v loglevel Sets YAZ log level to loglevel. EXAMPLES If you start the yaz-ztest in one console you can use the ZOOM shell as follows: connect localhost:9999 ZOOM>search computer localhost:9999: 7 hits ZOOM>show 0 1 1 Default USmarc 001 11224466 003 DLC 005 00000000000000.0 008 910710c19910701nju 00010 eng 010 $a 11224466 040 $a DLC $c DLC 050 00 $a 123-xyz 100 10 $a Jack Collins 245 10 $a How to program a computer 260 1 $a Penguin 263 $a 8710 300 $a p. cm. ZOOM>quit ]]> You can also achieve the same result by passing the commands as arguments on a single command line: $ zoomsh "connect localhost:9999" "search computer" "show 0 1" quit COMMANDS connect zurl Connects to the target given by zurl. close [zurl] Closes connection to target given by zurl or all targets if zurl was omitted. show [start [count]] Displays count records starting at offset given by start. First records has offset 0 (unlike the Z39.50 protocol). quit Quits zoomsh. set name [value] Sets option name to value. get name Prints value of option name. help Prints list of available commands. SEE ALSO yaz 7 , yaz-ztest 8 , Section "Building clients with ZOOM" in the YAZ manual. ZOOM home page. yaz-5.37.0/doc/zoom.queryconversions.html0000644000175000017500000000606615130444232017121 0ustar00adamadam9. Query conversions
9. Query conversions
Prev Chapter 3. ZOOM Next

9. Query conversions

    int ZOOM_query_cql2rpn(ZOOM_query s, const char *cql_str,
                           ZOOM_connection conn);

    int ZOOM_query_ccl2rpn(ZOOM_query s, const char *ccl_str,
                           const char *config,
                           int *ccl_error, const char **error_string,
                           int *error_pos);

ZOOM_query_cql2rpn translates the CQL string, client-side, into RPN which may be passed to the server. This is useful for servers that don't themselves support CQL, for which ZOOM_query_cql is useless. 'conn' is used only as a place to stash diagnostics if compilation fails; if this information is not needed, a null pointer may be used. The CQL conversion is driven by option cqlfile from connection conn. This specifies a conversion file (e.g. pqf.properties) which must be present.

ZOOM_query_ccl2rpn translates the CCL string, client-side, into RPN which may be passed to the server. The conversion is driven by the specification given by config. Upon completion 0 is returned on success; -1 is returned on failure. On failure error_string and error_pos hold the error message and position of first error in original CCL string.

Prev Up Next
8. Options Home 10. Events
yaz-5.37.0/doc/zoom.query.html0000644000175000017500000001032115130444232014615 0ustar00adamadam2. Queries
2. Queries
Prev Chapter 3. ZOOM Next

2. Queries

Query objects represents queries. 

     ZOOM_query ZOOM_query_create(void);

     void ZOOM_query_destroy(ZOOM_query q);

     int ZOOM_query_prefix(ZOOM_query q, const char *str);

     int ZOOM_query_cql(ZOOM_query s, const char *str);

     int ZOOM_query_sortby(ZOOM_query q, const char *criteria);

     int ZOOM_query_sortby2(ZOOM_query q, const char *strategy,
                            const char *criteria);

Create query objects using ZOOM_query_create and destroy them by calling ZOOM_query_destroy. RPN-queries can be specified in PQF notation by using the function ZOOM_query_prefix. The ZOOM_query_cql specifies a CQL query to be sent to the server/target. More query types will be added in future versions of YAZ, such as CCL to RPN-mapping, native CCL query, etc. In addition to a search, a sort criteria may be set. Function ZOOM_query_sortby enables Z39.50 sorting and it takes sort criteria using the same string notation as yaz-client's sort command.

ZOOM_query_sortby2 is similar to ZOOM_query_sortby but allows a strategy for sorting. The reason for the strategy parameter is that some protocols offer multiple ways of performing sorting. For example, Z39.50 has the standard sort, which is performed after search on an existing result set. It's also possible to use CQL in Z39.50 as the query type and use CQL's SORTBY keyword. Finally, Index Data's Zebra server also allows sorting to be specified as part of RPN (Type 7).

Table 3.2. ZOOM sort strategy

NameDescription
z39.50Z39.50 resultset sort
type7Sorting embedded in RPN(Type-7)
cqlCQL SORTBY
sru11SRU sortKeys parameter
solrSolr sort
embedtype7 for Z39.50, cql for SRU, solr for Solr protocol

Prev Up Next
Chapter 3. ZOOM Home 3. Result sets
yaz-5.37.0/doc/common/0000755000175000017500000000000015130444232013072 5ustar00adamadamyaz-5.37.0/doc/common/style1.css0000644000175000017500000000152015123757402015033 0ustar00adamadam .table table { border-collapse: collapse; border: 1px solid black; border-spacing: 0; width: 94%; margin-left: auto; margin-right: 0; } .author { font-style: italic; } .TITLEPAGE, .LOT, .TOC { font-family: sans-serif; } .TITLEPAGE .abstract { margin: 0 150px 1em 0; font-style: oblique; } .TITLEPAGE .inlinemediaobject { position: absolute; top: 60px; right: 0; width: 140px; } .table th { padding: 3px 6px; border: 1px solid black; } .table td { text-align: left; padding: 3px 6px; } h1, h3, h4 { font-family: sans-serif; } h2 { font-style: italic; font-family: sans-serif; } .figure b, .table b, .example b { font-style: italic; } .example , .figure { margin-left: 3%; } .screen, .synopsis, .programlisting { margin-left: 6%; padding: 4px; border-style: solid; border-width: 1px; border-color: #bbbbbb; } yaz-5.37.0/doc/common/ref2dbinc.xsl0000644000175000017500000000141115123757402015465 0ustar00adamadam Generated by stripref.xsl . Do not edit
<xsl:value-of select="refmeta/refentrytitle"/>
yaz-5.37.0/doc/common/id.png0000644000175000017500000006147315123757402014217 0ustar00adamadam‰PNG  IHDRxð+´sRGB®Îé pHYsgŸÒRtIMEÙ±Þ— IDATxÚì½i°l[RöeæZ{ïª:ÓÞ½ož»ûu7tÓØÉ2 a…ÀÈÈÈV ÛüÃ’-ý1G¶C¿›PØa›  ‡$!,‹ Œ›¦^7Ý@Oožî}÷Ý{Ï=S {¯µ2Ó?Ö®sê¯qóóùUœ¨S§Î®ª]¹ÖÊÌõ}_æ&wÇÿç›#+ÅÎj xîEüÄ÷O~÷SÏéÊÒ@ƇÀ+¹h¿½Ó¹ößý=ßþ_þWß1™!F ÊJЛk ¾5~ áw£¯ÓÐèW2 “Ÿú_¾ú·þöy±ó—½uý*c0¦jèè`' s7 †´¿5Ù¯ÞjÛægþÁßûÞï},´ ¤€žw!Ÿz×У¡³bò‹ÿÇ õ¯þ- h!-©¾žÑÑÁ§/ ‰-ëQÓuaµÚoÚü ¿ð?÷_|î‘{‚¹¼c Í_ÿñq1ÇOþ÷ÿãöì"Ðu[(tLMà.p¤ ƒ4A"‡È!25"1ëââùG'íÎju²3»$<ýß~æçníC˜¡(†¼ ü§6ôñqŸ>ûìÁ#@ýw¿3¿;£ÿ„¹¶Ô]ïï|ûŒöÍ)웯w~wFoZ•¿Ö¿ª­ý4²…õ|ç»bææx8Þ †o·NmGgœ^ÏeÀ힉[ {v–h¬§w }›•iÃ-ÐúÉu¾Qÿ;Zá¶1©íN—Cëqr¼ƒo_Ÿ¡É«e Pr#¸8œ °o ÀÝœŒÜn_Êã`¶f@Aïd[ýÁÇÐZ hà#ì&@Cè€\ ði™‚8Ôá˜Z!Ϥ…B07‚ÅÆŒû]CêH)1¼d¬šš·›±Uƒ(P@Êq¢+K ÙÝ>çf†ùÖ´mš¢XBÁÝgÁ;5›þú íÄnæ š†s·í( ep6NNƒÑ`<€2À^ÐÆs 9:¹¦X6¼5_§4lmmÙ)ÐAìöÎ …Š`Ø÷xôÉ=n\².Ë!Ð`PÀaYÍüÌ0ru"ä´C^2šé}ð¾ïo|6i/]¼Ð4PŠ… wsâw7,€v‰øÎïùæ¡\L °:wqv°ƒÄ êm Sa  ËãåóÕ¾3ôþ»þ܃qÁf5Z AÞõÑg·Ù ÿéßü÷?t_hàæÁÍ€ òŠÕœA aìœËÂl^ü á2ëZÇ<—ƒ‡<÷Ã?ü׺ Üဈpè]Picg²XâÏþ™'~ögzÖÉlº½µ½‡²„&h)´¸«{ ÈÀóç™ižì­¦]8®}è#ÿʯþ܇¾i‚9ˆÀLx'¹fÆ_9»F©~úï?û‡ôÜÍý[ïÃä äx;óƒÃ·vwwc "ýÞ¿ôÝßû}Ï8 '‹²»¸3Ãaêè]C0©½‡9àëMÆ){M ?Êüv¤ƒÖG2Õ?ílmùí›ùÿŸgkÓdñm†€(Du³Ñ§›ôÛ¸ -½£Y¬?•¡Þ®ç5þ¼‰ZÜfJ!¯ðs5ä)Ëå·ÛœÖÏ󻆾ÃU3PÖÞo(h ݹÀ‚1tÃÊw ›·wðìþú Mëí5$ 8uʣʀÇp@xC±Áw‚ãýæ0¼3mý§˜ÑÕ åN?Ko“ zMÜgÁŽÏLy ¥ž-‘w]Ns M€ Øm{9Â:wf§H§x¿‡{ä‰wŒÇ;ÝM CßËcà° 6ƒñš§Ñ©½FN– à ÷}^Dϯ'µAÒ6ÇÂ^S ôµiÊOƒ4ï¨*Eɧ/Òõ‡óøF¬Fé♤n_÷ºf¿C¬8 i1 \ B€šéÛá³ïF¨©ßñn·²´<Ð:*úY®í0»B”ŒÐÀ‰r‹; F#Òzúu.;6â@ì•o'7ÃìŒéqWí0ȫà €¢¹1z˜˜ÀÙ ê`d‚,€8œ×¼‘ãõ9ªÁ t¾¦þïih¡”Ä¡•@N©s€\˜œœêãñtǹ\…d8•T/QMOº¶•Ôñ†»‘ PæXG+ĺ*\] Quët‘ÇLqƒóÒfcJY¡,­§3Bkf’G- Ø+ƒIÄ@€(Œu@Rß?–õ”©ìÄYxqAV6&f˜©®‰JVóö{rO¨babÜ ­gG0#Ü>_˜Áw8Ô;×õøwñ1òzªÙè”È™‰@›y.¤‘|Ð:ÜkcÂX7E§câ€mø‡SÓЩò»Îø4<(ãŽ-.Öþ…YÓú›!Î㌦²Nwã½¾´ÈZ¢XO#ek"ÿ‰ÐÒ™Iýk·¹¯æ»"€ŽÙ‹ŠÁ ´wù9¾#Ô ÷Ú‚å̾¶áOÏ| [Gm6Ô2>£° ¯ÍâÆÇÕcÒ†ë§ÃÆ(@Ïh7Ž¼W0$Y¬Ðµ÷#f0ÃÛ¦ v½ ì´^°›{ÅÑÐr8Á«‚РÀ3zƒæp9œ!§‹ïš^¾ahŒöl i#Š®Ï×hã_õµuðx#Eõ—„ʯ-[)[;ÁÊ:AtNG?ãà{ú'~âWŸýýϹ3œ‰H$º“™‘WÏ\œŒŽ@ÖeP9=+'Àeý5mýÍÎõ$ *5’W²TJvî>þo}èáox É2sRÊf94M.0;¼ ùí»Fe&ëH×ÁGPˆ¯%O•i·oM0'(Nb @Jp²×)"†àF•ÆÈ<~®={²Ý¸¼º(|þsoý³_yV 3S%fæ %3Z£ÂÈFÊ0Cd› $PÕ16£1?­§ <ÌÀ@Èábd`Es‚Kýò¡ö#Oɪ—3 ©_ˆ…,1Ln¼öîgªÂ,ÕúŽÂ‚S£àÆXFC›Â2ÃàF¶^a À` eq%ed°ÄYÍŠÀÈ‚#*‚û¸þª¿ªy­£UPê(v´e<™zÀÛd¼£©!žÅØÚ»!Ä-+ì ^1 €±G`ˆ€Â30TçOÎÕ ëÐWç{]I‘<0"P Ü×a]Aáç¶[üV™{c¡…‹/µ¯Su!lú(Ó»‹‘²÷ÊhŠã°NJ¬H)ìÊvšà‘3;ŒÆ7 ÊÀ}`Ä¡„!ÀÉZµ` 5€ì¥ñž€¶€,£eƒb‹AŽz&b÷ΤƒºC‚R1Ãk eÇd–l–‰Xœ‹BD¸yŒï^׳¸ûe@"vew$ _ÞÄÝb쬞瓞섆lê—ÇÐH}ò·~ÛÇ¿ÿ¾#§“_þÅ_ûÌ'¯8„Ð: (ƒð0 8RñØ“ýÈò׺Žoüæoüîoýúo϶wÿÒ÷ýÅ?óíÿêW^øéÿ饹9!›ÁrÐ!hš¸·&±ÐÍÖc{÷íðtu2o§“›áÖ›7Žû¸Ý…fÚ«¦`€,Ä\ŒŒœƒ4‘ÎñÎùÉìéG#œŒ´Àê¹kÏïÌsô'.RÜÜCãa—\sÔ Wyüþ§ãs_øò¯ïðv×MÓý»ç÷yü­Å­«ýQD”ÅÆd‰„ÅЖêO°Ö±‹æƒ—»zõêÕ”&¾Ç†%Œq¬ÞûÙÄÜ[>óþ§ÿÆ´¾ð…/~ú“/5³U€4ò)0Mƒ™Wyé—~îŸÜXôd‚!ƒ î¤EJ‰¦*´ç?Äïx¾½œaöÄŧö/~eÿ…—o¼iÙÃ,ªYaÀM‚•*U(N…B”K{—Â#K† „Ð…­ C1‡Iˆ­»©ZKaÖÌ–É Ø%4¼õ$·Gí·¯¿b»Ûó7>ò4creØ‚dLnbìµèÌXªgÈ.,Qd&Ó§ñdß.¯·$¸‰ÛXV›÷.ð‰båÙÙ@0"Ã]‘0 ƒ¼êB©¨u+‚±¥”a ,» ´ 6ø¶oýÀG?òÄoÿ?Ÿ™NÕ „E E- &`q ˜ee_ ¶ÜΦ¿ü⯠Ë~ø‘‡žÚ~êñ ï;ârcu´$/ÄIL+Øâ,n¢±€^sIÅè->yᎆy’Ôwùļ;)^4i %0ÑÀ‰T°5›ÍSþÒ•—{h÷™Ù^Ø>Þß¿ñ¾ïA\úíùçß¼u.ÎTG` î„}]™S'¤:(›»oaM¬8„Åüžt>¿Ö^‹ÁˆAŒ(ÙWÇë€ÇÌá%Ú7”O>.?ôüåV iAˆˆÂh Ubl"H,Ã@|a›Ø;ü•+/¿0¼ö¶·Ê0ˆ»¸‰Ì̩(›²5QˆÀ¢_-ûÕ¼_õšÏÉsï9£xqòBÂ@JÁéxµøÒÍ×nâäãßû¡ ?=yèåáÕ—Þx­ÛΗ‹cÍÌÉŒàä^Q¬ HZ4‚Õ´2DŒQøî{‚t ¬f‡„DÐâè‹.8 ià¾p¬b“×uàQó¦£Y@£)›‚ Ïþþ§ø¿üÏ<ñÌÉ~/†€vµ€c’ ÆYhî…J­ÚÈe~ý-?Âù¨\?x“‘/‡½-ø´¤YIÓ’§%OJn-·šÅó"$̇€rÝ{î»ü±ÇŸúØcO¼ÿâ¥û$JßsêYœ[h£¹)Ú˜†,ÁrÜiÞ;7}G¿{ü‡Ï`ï;/¾7aþå+ÏaJ“VmEœ•“rrNÆÉi|`œ!…¢ æè… (ƒmtªwýðXÞCv;âbÄÊ0³’3RÀÂLdU¥OÈZöˆs”•ºFoRòþ/~ý÷?ûâÖ~ìÇþóÝ-q9Ú&¶1*z0AZ≹ 9gM 3'C8wá¼™‘ÃÃÄ4CGnäFîâÆnÁ-ØøÃ̱ ÌpOtßîKN.D'6ml„x†>/!à ‹Å‚Ó¦2_ö‹“åÜ‘fh®] !0ó­ýýsۻêg¸“+»±™òX}Sòs"MLpv5MÁï"ç «0ÁÝÝAÑÕàpg3$w‰m‹Ršbd†•À:Á”0c´F}Á‰H›áÜuÈF_yîÊÏþܯ*áûÿÊ'ž~¦°ä°Zæk-+€g™J; ``ÛͲg3=J{“Ý“9Ê aY’H¡PZ1 6  3'.d×qý‹¯é7¿úÉϼüù×÷÷ 5fðÖ ØÐ…¨Ãà ³f' ¦•ˆ¨?„É'îïüE}ó½»ÏÜ7ݳy¾´{yukµ-31"˜”` œ@p‰.‘ÛÅ0í¢€§Ô‘É™_Ýøa–î(b¢8¤Ò·±ëÚY°š£kv»¸•´b'3x†eXB2,€>ëwVhĶþå¯}êù¯”Ðàñ'àN)÷­„b+,!MäVРXN'¹,³&¦wÐH¯»ÍìáËø¦ÝRâÂœ‰¹0)±;± Ç>•!gn±üdX-†!eu«¾Ý„Ð5M˱_ö«!u;[«œæóùSx ~æä>ûÆó·püäÅ'Îmïï4±Uu÷¨gT¯i–yR)…b4p&·âV§±òöÖœPhM®IKrÏny£æ’ú¡ŽHIªÙÚÐjÐK  L$…¥Æˆ|Ö5R€„aÊç^üÊ«¿úK¿‘ØÛÛs iÎkn ˜Î`î® â\œ[’+réW“¶Úö¡Ë—éîÑ¿õÖ["âe¡0’`YÐÌ&`¯c_à`âJ8ñB7 ªñšÜݵ¢¶m{öJa<úè£ïíž¾†·^¾yõÊbÿK‡/u˜>óÐû¶§³0íW¿+Sfw'ò¦¦ì@o/† MÓHìŒ[¶€ˆ`."}^dÃÔ!}I v!îÉK|ay² `¹@û"îÿþÞÏß÷ÿ…'߇Հ“c´ínÖ#…! n0°zPBH!âø£|LG)ˆ*ìÕþµkû×e§³†o£ÍœŒó~Œgm#[Ø}Ï…gôí+¸º\–ż7‡"µRO54Ñ£/Ó*v“KÍòçÞø£^”¶ÛWn\i÷¦»¸¼}~÷Æþ5jV›‰ŒÂ×q¾:À"‘Aoá`ÐÄÊo‹Í‡”I‹C]Ý׈«SFkH¿òþæ«WßДþð Ï4„© µÇD0„­…Ë´¹0O·>ùé/ýÐôÓªþ©O~Þå¡×oÿ‡?üß>ôèÞª`q¢7n,M‹8È,€ƒÔX3奧7ß*ÄÇœú’”²Z,—˹lµ³½­ƒaÉ6TNF Á7 ƒJ²WŽß¸ÙÜ´âTÈ»¸ìÅrE·Ýˆ8†\4õe6Ý‚€½†«WN^Yت˜NÚ.‹}õÚ+“ûOöûãe^mµÓ;Êj020Š„èðãÅñ+xm¹Z([6ópo['[#ç4Ò9V«ªh®\ßý_ürÌB{¾(¡¤‘UàÊ䨉M èŠù?ýÇÿšT “Ø\üO1<›sQ„I(€ Œl À•ÈÁ^Hýp9_Þ¼:Le>,Z â”–‹B3›œ ‹Z>.>òTlˆ%$æàä7Nn*¢4Ì\ȇc[Y ]ôyð’c$Ì,yH^TKRò«G×ÓÁâòÎNe¾Zì̶ŽòòÕ×ãÎd2iSî­÷ßkñÛœš 9€UY^=( +B};ÅDHX‚V¤‚êA,-ჱ#0œa¹ØÅ1mF(žÊèÍ XÔâÍQÙVGY·BØV/ cPKÎ! (™‘¹š¨]èÕ^JKDI$t,¢ä‹~»¶Æ%ÄHÁ wOšX ’+‰yg+$!ÎLDª9ÄVš )¹šw¦°;9Ñ~gÒYòžri©(B@CayÒS”‘‘[#ãNîav7¥OYˆ\äkô >¶¯FáF¸q ˜EÌ,ª­`Ù˜š@Óbš‘”+¼ÒÚ ú›¥\–>å­¤i˜ß’­KšVÈvO³©’W戃)u¡É% CADD$Nœ”œ¨ˆ“³ÇVJ?”’"KÖ""¡mœÎªÆk8"‚8†œ„yÊÈÁªÅ¡‹¦CJ}ÝÈ5MÃD}Ÿ<˜gÕ­í•–å°Úšn÷'‹cÓÉv7ï{‰¼µ=],—ƒ{Ó6nzÊÃݦd.9Qlµì'ÓÛɭ·üíÇÿ÷€©%iK&QÝ™¸€ ;& €T$^$™·òlÇ.ýƒŸø¥ÏýÃÏAΧR±‘=;a‹€Xb J©Š/wƒ÷%E„œ—p'g/®Ô6æœ#I°âCj@¼¦ŒÍ´ ù”oÓõ$¯,¢r”lª®# (0‚{&f&TC—Rˆƒ2ëd‘ršˆxß·QŒ°@â–ÍM–ýŒ8”6H“Ê”úºîFDVJ²wûFñ]†¾&Ï]ko0E’®08Dƒ*2q9›,L^˜²`pWxÛЮiZÄ› h"HÁ.ÈUÛ±F°6eÑVaZr!¯Uù¬4VdUšj3—:}`§”Ç„µÀé´¸Üïd”k¡ØZlL0B´Qåëieƒ¡öka%K›Ü?;2¯u-ÝwÝÎ4:þyoC Å“‘[va¨ÁƒSœ)Âj×?c@Ù]äTL,Á àFTšÌi€góÂÀ”¼nô®t&]¯ º ¬™„‘ýVÚ`Ó7V®Ü“k¯Úœµ­yãe|ª#Yÿ§þ%kÖ‘…Íâp@ ¶~Ÿõb ÊÎì¸Þs³Sšøm}´ eÌ%š ±E‰¨¦)@,N WKÌØ붧NßZü 3+ZÄAk-V¥œn×S;Ó=h€èš·>5­÷ !£S+ûm\øéýÚÜ·Á’§d¸2UN1ø:Õª(seÄ‹œ}¨ÝKÐâ#T;ÿ¨½Ñ{,‚M‘cÇ¥#xt²à`°Âën2ÂZXK(ŒØZ76b±€BTY AjÞ†fýå8;»£Š¦NÕ½f¾FÄÁëDÂ0åõú¥MʊשUe:6㺌èt®Í=ÎD´.Æ8U˜È‚D\&öJŒ‘#9œQ˜*ËF¾Vx¬O #Þì`G­p·{ª/ïœÑÚŠFƒV""%cR7Ø•Ac>éÆ梀ƒ‰¥î&!(ŠÇu£5¦Ú¬êÒnçýÈA0v9¡¨fÊwöMÙОÊn›¹›‚¿«QUBc\æÌtF¨ãv_ïóQ©÷vï¶yþ§Ç3ùÛ²‡hª2ÈÆÏa'ÐYPeÄ0#Í …—DÉP\$$F!!¹6ux£IØÐY‰Än·Ù¨ñE!Pt‚”}œ}õÛ­9ÿê%«Ç¨TKTðF²Û#/ÆÖ|*—b‡2avD3qDß¼¢ô9ÊØ´ÌO]Æéú0Å ´n!¿ÛKÝ!Û…»×Ö•Npsªj´èdp'ÏÁÐ$(àÁ+ª SdõÕ-k¥ZõX¼Eæ0r¸‡µ¯ÿ NpΠ,>o·³õ|áÓv5 8Ö3ÚFì4æºäg…äÊJ£*•¬ú2€ÝŒ@Ž"€›Ä=ؘ„ؽ8¨Í9«<¶å 6ŒÂ(q>] d 6¿k‘± Yà„¤¸I AU‰:÷)hË¢¨õ1wœSœ¬Â–SŒƒ[P0˜AÑÑ®Ð%t ›ŽŠP+±Ç*cÑP„2TC3…+B n‹‹JÏ’ƒÉÉ$‹à}Ë=SH‘¨º:)qý©VG«ˆÆÒvK³ÂÞkj(úà$—à²rIl½PæàFž]¬Ù‚f±hÖªE³AƒØ îbÜ’ˆ65 ” ­"¤<éš¹”ë'ÄMV2y)%P„‘“°zöˆ½j–%¨Q©È+¶¹±")3/RðF ì&õëŽôy¨̸5ú„›¬Ú&9‹,†I¶ ¿xùá²:hºm“-r'ccr!F ’ÉBF4‰& ‘q}ldÅkÿž†U›Ö¸³ØPìâÄsA2¬UÊÈj9LDBhê¬g·ZÊêdˆq^ RÈ“•¤Ù´"žTLì,Ïѵd‰Sí¹gÛžl§“UK1PH}ªd“#Àà®f¡Æß*qû·¶&3™ö‹Cn95ÁÔ.Ѭ-qe‹Ìy£öÆÜNÚ!ÍË©9S¦eB²:>^lµÓù°¼ùÖkÍì¾Ü¯`yTéùZÜíND­Ñ–uS¶&RYÙ`ÅÐ2™+i"ùÆÆ$v{ØVÅõýÃvk2 H‹a›ÚFx&È­€¡kq«-†ÖúX‰ Ô©lw;ûÃb¡\sTwµµòÞ×WWÓÉ@s'u ì#„³âƒªYus0yJÞA.†ß½þ…iØBû?à“á•£—, IDATWÁàwˆùLÓÌŸyÿCÿñX㇕0,Ð4€c9ÿ·ÿÑ?ü­¿ûwòdÙ›AÍórd‹ÑÖJwsB=ƒÇ ùN° —’i¯©Vbܵ‰1S%å~ Ì]¼øÒsztüäå‡>€÷yû…+ó›Ùµnw$6­—Í:;2°;Âåvï)ÌÈÙÝKP÷Žì EÕ%’)bÁüqÜÿêÖ•ý7¯t±á”/6{ló¿ÿÌ?û®ïøáæ}Ï<Á G†+HÇò„µ0°nnA)D=Ë‚mÉVºv§IªnÆ*@±ŽQ,íÔÛöN¾rðÜþ¯=òßöžoÙÁÞï½öÇ/ͯ­hÛ˜LÕÃf¬JÒŽ¯ÞºvýðÍGèþ§»'ÿàÊç:`º-%ÌW)£ Ì·ë ‘3œ‘5‚XYBDä®`ÒµÖ¿.ú Ü*åc‚ß\_ö¿içf™ÛÂS´€i.D5$øÈŸùZ]ƒ‡±.ïÀ·–ó—ñÚǦœ¹ ‰ö6 ‰ˆŒ“Žé¥$C‰RJóùŽ®ëš¦<ç ©§1v aff®§åð¦;´}ç·±ÍÌ"b÷¨¨wƒ¥”cιë:U=°)¥@¬ª)%!jÛ–™K)ªo{‚Bë¨÷}of1F5K‚̈†F!ëŽ`†û†þà¹/­°úÀÓïÅP×s®çÆÌ1F3 RÓ;re8;ªÈÄêÓøåן?ÿÈî3ïyzž—“öœ×]çi5÷Gm7mšF­"8)a nÒ~øCp|´º~ã&S¬Ç¤YoïBàW^ûì+|+ô«=ñ²r3™æ~AÎcJ‹šŒÀ;»SOf'ÃÃ?ùhûÄþòè8®¾ù‰¿qãxÑïSôÐ…¡_r;‰F¾m¨È6e7Q#ž(HpÖ”]¹¨êVÐÀfXWò2sBYŠë,-ôƒ H»7 i5äv‚UòìÇ÷]Šøð?õ¿þÔåËpÇW¾zå«_yykk ôi,›÷ÖW?õâï¤Ü÷¾Ë´Y†ʪo¨é…œá›…S&î@Yq^"±Á’ Aꮚ2ÃmAWÆò‹$( ¤°!ê"æ/¾ùÂ!–÷?ö@[w‘Âê&bfîî„À6â,Z)/¸±Õ ¤–öûã°_¸öÒÞóGðÄx]ÙØ¡µÖj$' z@c˜–ýÍÿìGð¯ühÛàÂÅ•×ñßü×?©ÎÇ'‡Mœ%ê¨z£Z­6ø4ÚÞ…YÃÝjê^LYB±tJ²8ay¹¤óÝì›/ô2.?{ô×í9=»ø܇gyâòƒÃõåæBŒu"f.nêÆÎa3U]t&[D=A*LÞ`znzpóèÅþsÝà ~Z`z†xÖ²Þé´,ª“’&ì^À¤Eßã—á•ÿ±ÿbÙ{-zLy!»3õkÞBÔT¿¡„¹8¹ûñK8Æê«xéÕ¯ŸÆÙ¤C?k¬ú÷vÒM±µÃ篿Öî´ñK×^¸øÔ¥-éöövGsg5ײ»µ7¤ÅFE¡óØÍËFßÄÑÔÑúb®ˆkrG NfÌJeˆlŽpšíf²×¾zôÖ¸¹Ù‰/IØL‰"ƒ‘ÂiH+ˆ0SùW×~¯ 4”Õñ±ºçço¾ößjf[Ž°.â»-2•åaú+¿ò[_øüúÖdg²êspõý~>yv.Ì^Ĺês@lã·rÊlÿòÆïte¿ä&ri©DÛ[»K/®ùÔ¡C Giõ¹ùVËÔ‡ìçiÙNå3×>îüîA´,)ve(­ÌNfäõzÁ(o¼5¿h«c¯Åö@ààfmí5 c‰/`Ê\Ø®^_ÙïÝ@^ Kk²Pþµ¯þß=pùRq38T•Ü& $«ãBAcžØD‡ «ÕâÅó{;D¦“Æœ¯Ý:œˆG8¡J9ÆË%(Èh2ñAo‹?¾Q2nŽ0A)m{.¢› Ü„¶›¿)çîW?˜Ø7.tüå~¿mBAi,¶¥I–0˜Qš9AÖÕ–8¶K·ç篗¡\?L©…†œW©_!ŒÕ†ëÚiƒo '7Râ g§ CTÆ"º¢Ö‚Q+Ìâ~ìmØšµê.l/Þºuuq«'ƒŒ¸Fm=%"E5€¨ïŒõ7' [Ý<õ±COúå¤Û:wéüáÁbä0ªvÇx9È;/Õæ¸)Wª¨Åø£x§ê&wС§…ÚãÑHZ9Ÿª$èöÀ»n44žÁ™Îâô8òÊ`õ"•s£mK:@ækÙͺl}ÝÎh-%P"1°¡Ëu;ÆpB’‘g¯ŽÁ°æïÚyÞÙp¤2c£‚b\°Ææð57F%Â=úüœ¶ªDøØÆGj> `Fím%8éúÁë$y%Y6¹×5aXçãiòsJæn63¹­èÌad#›N&ë‹ôÜñBÚàúhCµc>J“·Iú+W™dœGööý>CáZsFM™ÃÈxÌš]!^‹uéí¥ÖõªAÕËŒm$ ¯ßºqŒjS/!‚qOÅk7õñH6{í#åvÚGȹÊVlÔk8sfª +ß!:X3Ògàªøiƒ­Ñ¼§öº cZÛ½&6QI×ìx’Ѳ…aã)„,È@f0 E»çŒö*êJm2ìp‡¸ÛÚãÒ8‡ìîºÄ·AÕ±„â°^ŸÍ»mÔf:îëMv-îe÷Ó6oä›=YÈ*|çg»MKÕ&`}­4³…S^ÝGmmVñÛZãTF¿Jd`¨Ø¿VÐÈ ÑѽÔï¤|ç•iî4ô4cša‚¢ 3!)¢£%(Û'ÿ“:ÿ¬/TŸTð0¨ŽmxéTy±ÖÙX £JHªT@Ê>6¦²õ|dØ ÓiŒ­w6£ xÏmmÄê‘õ6Í8¨ì·Iù´v1€ñ¦bäTÂŽ˜)Ľ¼2©,ÌÛ´e,sÕù¬†>„&±¦3& €UÇçªêîfV 3kˆ”"e6fR’ád9›ÍB Á³;†e‘ŒÀ¹ýÚm§r´þÍŒŠ5Þôý-B?è¢SŠ1÷²²å„÷V©’sF7ƒ/¬$-·6éZfh¶\òD¶-3±oM&ðCÓ4âºq[]ç´)ï,Å„xÖti1,'¤mbñ³¶g§i;’û!5MÓ¶lÚ˜•Žc¯Î!ó%é2µ»Ñ˜=€¬ÜÖŠ`Äì˜5Sv.É‚pŸMÝÈ&a¯TQE¢E¤®¹°­´Lž)Ö(쑨µpŽgñ„W'±a{ZL©¨‘ÓmÅg%¸ÝÎ}ýñõ T²€ÓlÒ-W7<çØÜ¿#[«@ ¢Ãx…¶%ˆ™Ã$÷žsÖ‚N&¤ê)u³N‡Dª³¶+jê™}뤺Z`1ãYב„ì5ÈZ¹¾@ €íéäx¹š÷ƒ7–i‚V’¥Rš­ÜQž5m³3[¦U¡ä͆ýÔ³G嶷NiµXJÛ bhc AVei̵ܳª‚* îŸÃ–8ixÎœ˜ÆÛ%|ÏÃßü(.øé9\éÖÕÒa>YøpWdeýñ!bCy¸xßö‹¯ý<''h:„y…ç>oÿó} ²âÍt+EÇâjÎÞÐv Ú&>òàÄ3/¦Ïíï;ÙÉj~þÁGoŸz¯]=ººÌ«2?ÝF«£ë&>OË“ùNœ~üòǾðú…F1]è:L‹ÃyœtMŒpÞ[ßúà7=€ '˜ÿ«7þ Òîlû‘K—£ËÏÞøBï«”{ DîU÷_­Ü(¶Þ7½ü¯ï}Ãm@8F>ÀÉ o¾ôÜ /54«hDL•ç¯õÌ#LIŽè MáF¹…LÑ,pôêÁ‹7Wo݇Ýãü'>qù›ÁÅO¯0;VüUö»yhÖ\n{‹Ž°\aH`2+fiyˆå ¦mÁÝ-—~ÑÞ:xsÿÚU¼ñ¡æ™óÖ¬®t%<ÖÞß‚‹ãÕ|U C§{Ô­ÃÕ"B4ÙÆd“bLÎt[Àæ(q •FýñÈÛˆ—pþÒÖyQ¢^gÔ>€ rpŽÒT%6bb\Û‘Åä{˜ 8~yÿ…«G¯î`òÑ>øû³-‰™•Rª‰+£""áÊ.]ｶ•dyTb šÿ·²7µ,»Îû¾µÖÞg¸÷¾±Æ®žçæÐÔ$E‘VhG¢&;4dYŽÉ14À`eÁ‘(q,8‘dv"ØŽ-;r€0¶$ÃN+‰)Š¢„ÑTìf³«YÝ]óðÆ;aï½VþØç¾÷ªYEÈ…F£Ð¨®÷Þ¾çì½×Zß÷ûÞm¯½~íbp]?öÀƒ=ùÑGžýÝÝ—ñõWÚ<£aZöûEñ 8DÅßÿ{¿òá`:5.ÎÇùxÚ(PPQ[ßñ¤ÔtÖš- óñº¯j ñöõ;í g>óÜÙÇiO=tҼ5ß›z'É,ÝG~£xTV© sÌz„’½ZŠÙ„b'[#p ¾í:ÑíÉæ¸Ä(£~¡On>:].g»ûÖW›´ª¢®*Ä q(Ž²tzáh ~içêå+W[¦óæç6NŸ-ίmmÏ–·û¾ÏÇ`>ðhØJ BnRXN|:·~3-ß¼z%¢}Ü?$w5ò 8Ѻ.*·µ˜MIÀŒ²BÛÌSìv÷vövï(¼¯¬ŸÕD÷÷‚ˆˆ—û®_¨¦„~ÙÌ߸óÚþñ<þ‡ê³s,®\» 8]Qî œ 'Z!N@±OH´Žõ1F±wucVéJHFEY\h—(¢D5Åô¥w^:sç7ÏŒ”7¨¨@#)U5f¼Áªu''.é\ø%â;»ÖlUoܺxûණíq1r&82hBJɦ¥1„{h"Kï(ÂÆÐ3\õl;ºt§G˹^;¸þͧDÄ‘‹JŸŒhiÔ‚&ˆ1ÁÕ•eáô÷ý©ïùžïüîd%’|ñÿºüÃ?öõ©­×·šé"p>D3ª¤XKmTsL~ìòáÞùÚóÛO]ÇÎk—_Y ™&c%zÑÊÌ’ "6uâ´·Ò•‚W§ºb´£{G"(É¥E;*Ç úkw–Sgï|lôüaw±8l'•ëgKÞs¬)N¬ \'K4˜!ts{1m«²\«oÞ¾s7ÏáìÛÍ¥‘«LѦP”EÓ…²®¸ÈâuµÕNŒ 5àº@ò-†Ô™Z¤vLïÍp¢¢|€1»Aˆ“Qí}9™H쳟’ }3½SÖ0Á9céBÛu®šùu]è‰í§÷0u¨Æã13×ãœä³ˆWË# ‰%]¤Ž™H"(œ÷ù²a|2¹<¿}Ú„I  ±¢•¿µsg‰ùóϼ¯3´¬<;ic0°‚óÍVwJQ”$}«!ê…6G£ $r:Hn5Tá Æj`•¡ìåhð€"Á¬êh”ô”+KÃÓ“­²?¬msŸšPÐGùÙŸùùÿê¯þmȤ’3…žQŒêz³éS»Œ)%Pß{q¡÷]šðöûÞ÷±€ôû7ß|ìüOžztgq{o>·1÷ÐÄ(ÓÐ#Ž<ÈؘYƒ*‰ =zu©S¦û)ª,*1ÐÅ®C ­…°8¼væÖû6Ù^m‘zM!%¹¨FPQäö ‹‘S.•+ÐzòûMwö·Š-”W°É’æ% £ $ö ‰F«4ÒÜNÐÈ|tïpÔ§ÇÏ_Ø^;½ƒƒDv$•¯×`øz\`”ÈP8:{执žüÀSO>ûð£­m¬3¹¦Y‚ˆ¨ÆÊì˜`˜QQT§OŸ~TùƒƒWß<¸új{ñ ¶äa!‹)e›K(Òqy€bVF¤<ô༷޳;, b!EÒ” µœZJïÞººDØZ?­ ¡ mQJHÄ—èˆÈlÚhHÔ–oõL½öGŸ:‹­½~/¤d«7@u˜l¸QÐB5-D좥F#ßÝÜþðO@ _mc{ŠðÚλ‘7”õ¸?­š)b¨c|ÿ÷}÷w}×w÷a\¾¨?öcÿáµÝƒØ4 Ú%Ä9Ô¤ãÐÖDÞarîÔù§ÜsïâÖ¥+ó‘¾~û³l¬’.†;˽ËéÚåÉÊ•7C]žÃ$f²£dS Ê gâQÍ“ÑYœz£Kñí;{‘DˆÉŒ’¦ÜrÆ”ò¸‚R:ŠïâÎRøú,ê€t7nïí¿µsN•Y±NDw;­PÔ2.ªÑ믃%…FÄC9G‡‹¶ ± T­UxU3crŽ½©–X¾~íµÞ÷mì•[¯?wîÉ ¥NbD‡  jaa¤i» ©×dwW’|¬A³%UCê)ÞÁAƒ8ÓV N°¯Ý¾R?P8p/Z:¿Ð»Zu–ï-DѲ]Ƕ=9áîàðöüê¥+oOÇAK¢”ç fY]ææšA`g³`ÖŠýî­×G(c ç¢m[¾8µÖ Š€”2È4“„¼.S×_|÷«ÿö÷ÿhÛÍ&1I›šª\“0Ù9°6®OÏÛ; ,ÅF¤ôUc1z0?|Í]íIÀ²*öfÓo½º¶±.D^._S°!rö˜"Ì M—g×C‘ß³+ÂÌS‚“Ò»{×ʲ\j/®h¯[¾|ý<·–ôÈžK 0G\ïw®¼ØåÆdiº···Áe¹]v©£Â…ÔŒ™Á`b5sS'y2FN-P[ŠWºöÔÆæ<$ Ý„ËT"HŒf&z/’?Á4u3Ÿg/_¾nH…”!ExYLgW‚JÑÏ÷÷ÈÕ—(KµBˆ®gâ8i{ë`¶¹yaÿöþödk1ŸŽ6Æ{‡ûýöf ,F?Q^F&8,)6¤Ê²×ìõL²UvY» Ê;/}좩ffYŒ.Â&DpAI$8$‹¼Qî IÄó2$fô2ìfFȞδé‹©‚EU»>M”S ‚YAL …€d¦<Ð'5Se©&K,ùj´šb³ÒÐԞ穱µ²ê…òçÛ Áѱ‰ÌYšß¦ â0û¼ÊGÆÛ“u>X(„À€”NÉ%8qóØø’:Õ!Ï`S¶ãÉMÖ­'Fc‰ Œ$è9õ ª –bäÄAŒ4™Â@ ç²,²eg€ê”EeC”#õÝ5-4~¯;×2]xe_Íü@GqöGR`3¤0(Qd˜eXdãÈN‘ÇèJGþU‚)ƒ3áp„Á¨p2fÌ@ Íl¿MœíкòP jµ ¥D9)Æ¢XŽ>€”܉ï9¿v£H£@ÊÄ.CLÀ§ÃèI'È+°ãXêŒ:¥tŒŠTäæ¢3(¬ð@–1è ÑÞ0„U"P„¥fÃÔnÅÓÈ’ ÊR•ÈÃÈ# Np‚Às"²E³–ãÄ¢ŸlH '«©>ŽFœ Ðñã!ºÒÄÐ1ƒ²ƒE4Q¿CA÷Nq’µì'„yôk'@ùèu:¨Õì=_`ã¤\‘V:s†9­²Mâ×…‰¨‘T¢‰1e/ ]ñJ"ÑýFà¶ÜËÊ÷%½ïÓŽ#çìîÆ”Ò]¨‚̶«™øXr¥dœcâV?«Ë™ –Å Ø=¹Æ.2'b6e5¦¬%Kdi%ÉB£*dA4f#ûÑàÙ˜à Ð,R1øã™iÎÊ‚c¨Ú‘ÄéDLððžª!È)à (ù4(²"CWy|bNyì8¼‹¢|bß8Îz/y‚ÌøÄMÕ)Ó,2å¡+3ÈŒA”ùzÔA#¬®G) |Ý`¥…5AG+1W¾¦ë@â:Yæ¯uú^G6ñRZŽ>UÎ ={/ƒö.ñJ¦–ˆux„”9^)ñ :ùJæ'ÿY6MÕNÓýbí¾.ÄãÈVä ¶#¯=ñÝ* … <fKDDÆF‰LyH­¸¯#1¡èøá"F Å dÑ8$BpF¦‰õn@/+eI9ŸØ¢âjC'„‘ìXLföæ ÕnIèGÂÊY%d3Í÷h5ÄwS¦îÖ|½æä$À¼ÚŒ‡×b%š5€GÇÏÊE:í$â,\Ê)ÛyNÖ;mÜ°ó)•îÚ£Oìcjeͱ I…V²  èÌ‘‚4DÍó#¨’îÍ­~¦¸zƆ$ö´r¦ã[Gþ{LpÌT2î<9é!Ã>“‚za>Àé*óGñn e$ÿ·á[%gɺåØ0ß­i"ã!>Ó‘Èò¡žØVŠÕ¼ÖƒÛE¡ Ö¼•åg )'F¤¼{Ùý$sœ_ Q” “>­uVF#Cï©)dæ©"ñb ¤…8QQ/êÈÉŽ‚Z ªá X* $ï¥d7Œ IDATE™3P4] ÀŠBáa%«g-r{Ìœö¤|BAPÏÁ´‡çÀ‰‹deR†%†!ÿ„A*§Öšhôè…1 u×ý™7ò`§‘cô`‹)?nÚöÎdäkRòRXjeoDdì¹K ”÷F*ˆ…¦ÂB™’ÓÔ§(u™’‰/#C q],ºÄj–_l£UV’'‚Š©S:àêc²hJÎû¢EM)µmK'XBlyÔLq)ãµñf´ÎbðÐïµ0©Ï&d „Éöy´ýÉ”N‚RîГvÙ9Ï•çÂk ùàUb€%§B¬6%ӮªžPé£F탋ñä«À¬Œdjyã‹šqá¼”U0L—ÍbÞôMï]YTu2íº.Æ^a]è‡!úPdjþ‘5ö!4m×…”¬¿UOî7«wG7Íœœ“ùRdVùBƒR€!$"~<Ö¶K#SUõÐ:‚y–š™(Çãõår™Òª\k»4o¥Ce}ïƧæû‹QO=¨7à¼ÿt™±àÀÒEÒÄ%3÷É„N§»:ìL\,--=DÜöÒqχÖG‡ˆ^¬˜)%"ï k{íR+ÚyQæ1•ë“ éS›ºÐ/4Šz}<6BŠIwÿÄÙ;Î<‹7Ú¨×G®`ë“¥¾oS³Gæž´Ýe MCÅU$.(±3Òˆ>%J]š·‹r½2ò,Köµ„–hUÒÂÁ‹ëâ} ¡ífeµÑµ‡õ£{Í>IKpQœ>Ûã:VÇãqµf,"¬ìC4O&NØkLN†þF:îã)‹xôT›km'±.}EÞzuòz1ÕD¥0“cR3#´]'DäD˜¤6ö}ë|4b*Ö•cÓx°?CèE„‹RI wíDIZµ¦ñ½‡æäJa-ØQ£1ò=áU¤zº5Ô`("Wm:[­}Í«•­ö7mw¦¡e™r€ãp°1k¶˜ž=?yò©³ä—7níÞ±ƒé\q볟ý£aêCzâ÷^}%r… ýí[(Í8©GìºÚºˆ÷J4tùjlDÃD#Q éŸ~챧ð8ÚC/áê\tÚîæÏH•Ã…·^€¢mÛ¿ûwÿ³j ]ÀÿÐ_þýß»ø=ßûÇþößüÇ„ÏþÒï½ü¢p™Ü©³׎.X–/0êA¤)8r?{Í_yyzÕæÄIŠ£tìƤ\ª¼ýñ åWñ΋/µ]Ú¬ª÷Ÿ~TœÛYÞYéŒXL(È4Ï’¼]Vªsaî¶7P2æ{åé+˜·ÀY·6‚[ï%0E…0#%¨¡ë@ìªZzZëå *Azãæ;Óƒ .œœùøäùÉ•—/5067·CÛ€4£4ó?œåw£\ÙÀ®-ÞýÚ|§ñ)-RïS&1ݲœ±.dXNg| —ÚÐ7ݲí—mWzŸ¥J&ê†ÐOñ´éþù/ÿÚ~÷RøSúü­¿óŸ?ð`þÑ/üoWÞy§k;ò('Çr€üQåE'-Š¢]´„¦ïÚ E•e±Jôni³ª²q@œãÐ#=0Þ^›lΗmjAÑ+•Ü)®Ê^Ų›DhàM0(‚À0gÔ]3þ‰ÿ«žqþ<¾ïÏ|ª*ñÎÛÍOÿµŸY¶©®Ï©ið;P^‚à%¨‹±UµÀ$YY–I5¥ÄÌ‘˜Þ ‡u®€ó ÄÃØ_Ù½ýLýl¿ìÖë ŠBQÏ]Òª(BÛÅ’RÅ–´O!Hu¹°ÚÑU ³Óã¿6»|“s\oMÖà bË ÅÄà#¯sU4Ñ¡;-õi+N©?Ç㺠,ôu}¥\_žè/®T—!E‡j[Ï>óþozæãO?ôÜÆÖ¶ñI–:ÑÀ]9q\ˆÇõöWß|ûŸüâo\WÂÏýÜßdv Ú5-€¨=DŽ›n©€† ™'Òöxc¼Ÿ«#hšÏç5ªhúîîí}4/<ðAÌ:h£)˜šÙ^Qó,”"¼÷ŽàkI—ž4öžnïî0âC[gšåR)²ÈNø5!ƶ f|þOèãO|ò±óOnŸ>u?c‹ñʪ8:"£sh+™B¯böêþÕ×ìúEì\ÓeSKbe€Ì­>’l›ˆÝ|O“–(w›Ý÷?ý¾Ï}î3M“éøþ?ý½Û‘+ÅÙd} háW›9 ¦ÌFvDD¹ÀÉ T–eÊ÷{ú÷ cNÛöFš¿…âüc£í20çya–T‚– ’´o»6ô}êµïâ®"qF•ó%¸`1¤®oº®•‘¦Wë½ Ž‹nìg 7íÖK³w^Á•¯è­=éï»GŸè±ádÄjb$Ðý;·¯~åk/]}÷àp/¥¸2‰0!7¹m˜ç» fÐŒHþ›¿ñ×67qãjóê+×`øìgßÿ#?òçË’bjæÓË£r‚ùš¹¼ÌçW¤(ŠºmSHËʦH‰ŽJ'ûp±,=Ð¥ÒȽsps·>öè󈪈Î9‰šRJ>Z öľôn\ø²ðà R¤ U›Ê¦ï÷.œ= ¸vêK¿XÌNÚdŽÝËЙÁMÛååë×.^þÚå«ïN§Óû)¸9ðq GNáT-ôïï%ÚN|6ÊZ—¼œ®Õ„%ÛŒKDÕ0Tügþìw|òÓ§Aø¥öÿÄÿô| þƒÿGϜݥ¬—Ý~yêìêq®†zÇ*µ2‡@E êEÁ$ÄófiLùÜ?2EYp—}—XX9NBûíü­;_[Çd}´€’jß«já|vŠ¾ïÍ1 —X%™Gtè'MÜ\Ä­þÐÃO<\=xûoMo™ÓÂKb$0¯p ŸP\4ESE;SŽÎr}*ºQoî~mÒ¬ÄQ:ÂÁƒ9ï}D¬Q=ýÔ“$¬À®Mßݹv`‡šù‡–7VÂÜx}{1ßSÌþëŸùsëë¸t ¿ô?ÿú;ïÜü_ÿå~ðÏ~ò©§ðWþò_ùsñÇIÄIÝíÝÁÚ±Éj5Ü‚QŠ®ô=ûÊ/Sc¬Ü8©á$5û(Äjä‚Yãµ²Ùkµ ÛÓýKgn<‰Ç#š¬«f_¹ÐõMLªe»@g­¸ZÇú‡Ÿy__z™;Ø}éàµ4PTEµì{¥¼¯*­žhœ÷…wŠxzm›ÖÆbB?µæ˷ߺÖ˜ßÓÉÕJc¬mÈi¿ÀrA½óŒ8ôè@kJh ðbzÉOêçþäÅ‹!½Õ¾ø¥×^þòþúOÿüž}!Íüdtê…~úÅ?øý¢ÚŠTí [¦Ê9"_^ÆõÝù¡÷>„EYVÐ!˜óä‰mÙ±\HgüÜ M6ïd.ñ‹7ßÔók7±×Š9çM£šÍœ&ÂzY³1bÏUÑJq³ ÌÇåƪëØo½=»>³êÌFè‡Ó}©k»Ç¬@gÍb]ê)–§°¹…É!f‚‘Ý?‡…þ‹þó7îÜŽÎRI]êEÄ%r‘Š^(h%år¹$’&ãMç»(Jꪰuªì—þúÿñÕ_|——ä"¨a‡´(Ê¢ïPû‡bŒÁn3é¸.Öæ}n}$”K\˜}î§þÄÃß9>,n°£l„v& )ZÞŠk‹nÙN;ÝÞ©SgöçRŒ  bXÎ닱Õ,6)Òr-EI¶ˆ•• BSšú5 ]oÞ/œe‰e#†^­*JŠÀa{¦+êˆfÙ8}©ÝåÍŠ5ílcT¥”(+÷WwZݵ<7qma%I*ÝA»Ø˜Œ§Ý"­Qdýúësªb1Øh5,Q#Ó¬À!u:’üÈ÷ÖH$ aí¢°9o¨"÷DqL(ɨ7ƒ÷mC wAI?‰¹} ö` r6&Behc"õ$Á© §…›¥BS keÝ-æeÁi•I2é `¶¸&N,̪9i, ×[oFÑ3RŠä¼ÂItÉb#Bª8rìÙÔO´¯ú¨°mÙცô‘ƒ™JŽ©Éúë•äŽ‡˜òï*ZÔ%R«Ç`-ÆÆÝË·íV&ÿãìœË8ЋFF}9òÎÐÁG»~v?ÆQšá#²^Õ ”g*Çå\¨̧œœ7ïÌ'væle‡EÖ šÈ”3xäxÞ¨^qvóÜÊ)ÚKbîaŽcM¦‰ôhò«9ÞD=çÂ}Ŧ‰té}²=i’]‘ýèëÝ~YLÒñÑ„ÚiÎ9¾_jÅ`Î\´ÕbŽ†X&–‡ÊG¶tI°û‚‰I\åPy‘Qš%ËJZ fØ´0XP`”]oð~K.T_ê‚*ˆˆY1ƲÀ'¤m•Äd'½Þ:$,O™MÈ@èP•¡Ñ¦C¥bIr8‹2›D%d©ù‰í5w÷Né¬ÊzJ°ÁëŠÃ3ÈqDÌ «õ úÑvŸŒ§!—c{¨‚S4˜ !ôÜÃS¸¿•”!ÝPé©ÅèE;AJ¯€RôŸE‡~c¤4H¦¤°H%¯3”[1z\ÁĈÁ<ä5ÉMF"Rã0èE±Dʇ•üC‰³:ÔÀ'Âr@CV‚“£Øœ—0Eø˜äF‰†µ>®¨ï|8 $±x¼ƒè ÓpS$!Â|9 U‹µp±1¸[}a0NÐDspFá­4VÀõ(ã ;½qUôÜuqé]𥷸ÐådL+¬E–àøò~ô¯HÔå$˜ËÞ>…7cåĹim*VÀf+OÊ€Ý>«•2‹Œsp•Á× L¤Œ™°JRBõ2”"'اo°u|}wé(táHw²Š53q f}´;{æc–T×q³5•Æ( sÇ ÍŒSÏÞåÀ22²4 gž74ïÐ%1QŽMZ2¼³Ûñ4¢v—¬k•c¡«†8œZþÿÄ †Z ¬ßeõ¥IlÇ b‡¸ÉJ-ÈClžÉ1_„T³’x "«LؼÂÁâ×Qy†™!ß“b«'h6Jj†ü 3÷°¤´T´©ìžùæ3Ï}艊65$)7ƽ`ÌZ“ºŒÈ‰Ñ)È”=¤æÝ´ß#{°|\vc7TGõn¾ é1–‡‡Dt”£Ï2ÿR1*€˜ç5LJdŒ@`#N³ìã1‚1óJJ@tdUC2Ä<ÌFR¦£÷(¿ G 5…å)¡(Æ«%ìï=aÉ°'¾˜C«Yb†‘ÙpLsê¢wT¸±Yj»¾¨=qÚïÈX”£q£†þ€-`…(¥Ü…‘ÄèÙR¡êTI)‚"×uˆ!ÆXÔŸX㨫o l´¢Ì0¯¸=ùÎÛ+ƒrZ"5X&Ö ƒ$&ƒpF”8§])`]f<©#²a:ˆ³ ¾Êƒ^L3• £˜á¦k Œ9ÓýåQjBDf1%bÊÌÏ’TŹzå,ALcW†ž×-!¥J$è•{°bdJÄYÂ7̙̈‘Ž‘!Š%¶˜™pÞ•ª.v* q9éöfkk)yß·] ±ª*6¤”|ábŒ™ˆ~Œä1˜ ¾ KsÖhWÖ¥†Þ£°¨¥”b¢&‰Š6†HZ—œZ«‹²‹èz-«µd¤±÷RÇÐ7Жł†jì5„˜zGãAaG‡!‚‚Åñb±¨j‰)ˆpLí¨,ÛESø{¯µ;Ñ—ZñF d<6‰8hð®ÐÀÃñhƒ<8域@Hù:F9UëøªÇfÒ¶ï< È9Ï8Fo›ÐQbGR:rÔ#©EÕØ´(Jw†Á 1ŽŒÉèøŒâ)¥¹Rpœ@AC—’*’ðåÈXºÔ{Õa$ðè8’p(bÓµžQx_x¶¾ïÚ%œl®¯·S;' éjÔƒRØØ‚uÜõMá|HS_ìÞsGÐŒ›ÍÊ>^e&Å£©¯‹  o]ŠèØÅDÑ­Ä«¼šåæуËA/8*ªKbä@‘U`‹EB,Ê·)ij=Ç”lc¼®„Xó~s‡ˆFã}ß#WõrÙ’1{«[í-.„ ΗEiNèC» 5.&^*À‘I]#bãÔ·ÍÈ l¤=u½Í,ï®j¾¤Q=F§m虉ÁÃÞÎî¨ÜÐ}&ƒ¯’”‘úú>´‹¶®ëIáÖÆåt¶0c|¢ôûº'úÄÓÇ00öe¯f¾iŒë ìmaË•tquÙ%Í÷\çÌKÎñ«œÏ4S¨X+Ì‘ ˆEb2afƒ¦°ì•Öû.ö]¿6•ošÅ¢YÔã(]¿uys}Ë@šõ)–¿"‘²K–·©òÅ(ã ’ÆMMª’Èw!…>Á/}0ö\j]9Çj¤fd>8Zj3í¨¨+ñ¤…jéÚŒtxÓ™äš6ªÚ”}±Y»Q·˜¶M[~TtñÞ‹;9…öeG› ©hÛa¬mÒ&Xåæ¬[Áv²`›WDW–Äl ÆJ®¨Ê½qP¯vL ºL˜“ÑzÝl¬û:I˜pÃ#çK•´LÅÈÛØŽÉ1¤¬J&Fð“:4sßÛmú®öVšQ›–~´ltÞõsöc"D>%/ÎF!„¦m¬Oä’VVNdÃu¥D· WG‡íAÐ~¯ÙYÛ J5¿º!*RcÇk~[:¿A뱟z×,öç2½WÞ½K+°Šž ‹áÜ©s]fó¹Ázl¶l$ï„;n'ïéœ7¥•ñvÐhÆ>¥co_ÏÆ„(&dHF,¬dª*ÆÖQš»×¾xÅ-Æãº:8Ü+Ætá‰ó§ÏnwnÙ†…Jç=”³íOÙ(c ø§?ýk¸ØÀ×Øšÿ…öï•oxÛ~I†ŽÐp²Q½†pC_ù•w¾ú?}7=äAX‰2wððüßü¸œªcÙ%í`Dêaó0©$‰ó¢æÓð[¯~éŸünîƒû¾íÃ?ú“?À›-\ï'Y«DJIÞ8üÚg6>õÄúüÌì±S*L^»ó%Â`•¼{Ã!%3VUg™®Ôæ¹[à³îXssªæBÕÝÂAF\oÔ[د1åñ¹ Ûç6ÛÑòÎí5¼~ýÅË¿½¸>÷¾6QÌbØ#Èpmãl“·ÓTæWZ¼³?ÙÀþ»—_ºùÄÖFq¾°0WflFâ ^“Ηˢ(77Ï<úè“{ߤgúG^ÿWW0~pÝ?ùØÁèÒxkmoyUJ$V6–”mÐPrJäjïu†K/ÞÂFyÍÞWv{Ìë‚»‚:HªüÑŸúåri™ŸH‰Ø:²$Ò´ŠŸàçiÙlXõì泿ӽz¥ÝW3ŸD‘/¶yÂD2@¾ 9BÎXTÄàL½’O´ˆbÁÅ( dèAdV‡ /ïØ[¿~3¤³œü¥Ÿûw·?3zà#½õò>vüÎ?ôo~ Îõ.k¢doìûÀä&åòNnöè¯þƒÿ}ñîõG?õéÃ+W`탫ßùÇ?½Ç7hdÖ9Sðˆ#)‚#FÚq×Øòô§>úÙ}˧¾å7ÿûÁ¹cüƒ?õo½ð½ï;t·\¡FQ%Å.MÒØ'gˆ(¹õ1XX/êÛoì|ñç¿€Åø}ßþÑÛï P·Q>ó­fv¬ J…ëB¨Gkm8eƈÁÁ˜”¢hpÔ„xíê­xó[|á<ö‰íµ+7¯/bcflšû·FJdÊÖ.9òëäEWòÊ9"URÁV$¢ÈE¡B”L#‘r)̬MÂt7Ö{ûÕåÉsöø'Î~Ó'_@ÐúËðZbSND™ÕX”DÑÏš3å™t·_¼ öŸúôÇ¿éÓß‚yœ¾5ûÚ®lÓ)i؃E¤KD(Yt][4‹j:í,ê=¸>†z:+îÌd'º…°rb"WU£‘sÞ,Ƹl›>ÆBFýn¸úÊ ô#Þ<ÿCß÷ýhvè­/Ý8¼¹ð(44ZŒQU˲äžR¤\Š3bƒØ°µ¾Ñ.–7nÞ iwwWíöh-¦Ù}ñ‡øe¤zìMË}"*¸pæHã–Kóã²Â¤jm²™’ŽÆüôÆ8Bgû³CÒR´v©s¢pšJíF½nÇz»]û½ñEÜPœ}ú‰Çß÷üG¾Õ»Y¼ñ[W6Û ÕrÝGqF̙䲞ŒØ\&÷—=¼÷…ó…Ž=”b»¥öm˜7ûËjRVUUiQ-Æ›‡¼ò«qcöÑgŸ}èìùg?ô­°Çg_<Ø¿ØnðùQÚóƈ«Š}èšÐÍÙlؾ²èÞ ¬æbêO­¯=üÐc»Xìcñ؃Oœ_ÛŠ»Ó£q:­~}ÃEÎ}‰»t\9tj¹l,qÍ£±›ˆ¹ÔƦiÐ5¡‰Îæ(Ô½séMè ¾l`ÂZJOŒH‰4¹Dã4±yñ·^æê%üæoþÆ×._„0úòâ+·ö®tÖ,¬cW¯ã•WIIô(£V¡ ÂᢟgK™IYÖ£²®Ê‘YLÖ'bSvÑü‚oõ¯í© ŸÿçŸ×xn8ÀW¾p1ì2- ,„zùÚ“¢ó Q¨Pt0gê{L kìŸ~øÑþý[¯CðÓÏ>ÿðãý¥ù®…ø‡{#€&õ@pÉOž HÂF¥pÞ×Ü£:EOÌéòWv.}õmh ×<ýü“ffêId >D‚KÎ[­}õÖ«—»[¦Åÿï_ücL¶1;€?·{ãð¥WÞ~ÿÃD,B3-bÑ.{¿² gG*'œªÎq JAÉÌ•Ò†vTWä}H<[Db;3.Î…Ñ/ÿËßÄA‡5ÿú—~ýõ·ôÒbùΗ/‡½o?pnæ9à‘™XéÙy#!4©F ªŒkå [§Ocû’^½ÖšC…ëOáôçÎv×è„ïAÜk×zÁ686Ø(åÇÛU.¥c$bƒ)…Ʀè§;Wäþ»z½÷æ—_Ç+»8µuþ3yì¹nÛ5+qëœ&€à¼oüêÿò+èfXëÛÜï#17õ‹ÿãÿ‹ezå•7žûŽÇF§Æ]ê*+´³”N¸-mÈJ±¸ª[«'™&‹m !ED²Èe%ÆÌÌÚ]¿våÕÿçwÀÅú|îS/´ãE·ñìWîÜd¶ ÞüCíÔÇ*=EÏé²Yz/¾,hŒ…TN1iAñK¿øyœeH¶<ýmÏ÷|Ûœw£³ìñK1ס lÅ¥×/÷¯ëãÍ=úÉy?m/coõrûÅßøu´»o_|ûÍçN=Ëmq0šŒBL5j"9Õˆ©‘Eé°ÞÂ4Mš¡ï]M"»¸QŸÖ(3Wõ.dîàpúÚKo€x¤zè3kß÷Ÿü±tKçÅíßi^zù—á–o\|í©>Rl±Š)“2Øe°ËE /NŒýëíŃÃù6¼V(ëAXþÞí—677ÌåüüÆ«œ›G ¶ã•ÇÉú¦ï*àô#g>ñ'¿y g§M?ÚúŽû£Z¾å#/”k´_ìö>(3ælÏ…’‡ ‚ñþ{ªåäéço¶æ‡z}­õÚ~ïùßx·Ï·Î›…Æœ‹lD#U“‘qŒ®ûÄ_úP>Åãíz¿›ÁØ9ÒÚŒ4uírT®MÖ×ýFñÂO|®®ÖûÄö;Ý›ûºWUëë;ýM?ù]Ëfºuvc´Yô®3xIÆŠD?iŸß½y»´ä„ p’Rª’Ü3G¦DpŠµÞº(b¸Ÿ ÷~"cÒ‰£q0ÊÆ)Hod’|ÕO6çg],;ßE×z2uŠÄ©-º^¢R26½?„qçE‹ž…ÓZÙžQâ®ÜKÒˆ:0©IDATQ‘T*YWªtd0¸€1@Œ ÊýêHt•ýÚæüÏêi[Ì’kŒ’ȈÔi’ÎÀÐ  [úD>l*\çCp]ïZÀœJ‹ª±q\ß»†A†:ŒT ‘3JFQ²‚r*œ Ðc^-ò_{•sæ}þ·‘!qÊY@JjˆÁ5óêP”»b™¤eË46ÒÞÅD k‘ÙNá bFÔ™h/!°|âUdŠ¤Þ̓ÉPI%L”(q3êÉ«'ÀQBSÌ ®Ilp6æã;÷p²ËÑ2$+J ²¯DŠB bH»¢‰"@u‰5JLœ@ìœé‘­,­txFˆÃc«9*§¿é¿æ:Ÿðª¯èù£M †RP²Þ*çd%™˜bËööÌ’Ð죘™"‰D >8vÅAdND¢ìS!*¹(QØàѾœ«èQúä‘]$}[ÎŽÒÅUîŸb§†räS²Õ‰´/æ€JrEb‰.Z°¢ë’u9¶P9ëk€ó *Ü+˜˜3Çò*K>RN$yodÍòž§'ƒ]Þ³‰d¤½ëØVÀ2ÿä9 :ÀïáqÏ,–}]Q¹S™J:±ª&bž`ÊÄB2…ù\4aÚ0J½ëŒ q”®8h rRž@BLÍXY/.‰S!ãHš$(Ep29h9?®Ž*ªËRRÙ Š1Y†7%%bá ¿AYˆÁxÇ‹›ñædÈùȦ{qaDVw žˆ"S2ÒD:$ÝgG"ê”ÊE‚K^“R"ÄlQ%o ¡±=³aØÍŽ$ ‰]gR¦yĬ0Rp0k)ÊC ã”Șá2$¥‚CDeÅÈðÞHæ˜þÿîÓüü©bhIEND®B`‚yaz-5.37.0/doc/common/common.ent0000644000175000017500000002603415127451052015103 0ustar00adamadam Anders Sønderberg"> Adam Dickmeiss"> Heikki Levanto"> Marc Cromme"> Mike Taylor"> Sebastian Hammer"> Index Data ApS"> Metaproxy"> YAZ"> YazPP"> Yazproxy"> Zebra"> Zebra 1.3"> Zebra 2.0"> ANSI"> API"> APT"> BIB-1"> CQL"> DOM"> Explain"> EXSLT"> GET"> GRS-1"> IDXPATH"> MARC"> MARCXML"> MARC21"> OAI"> PHP"> POST"> PQF"> PQN"> REST"> RPN"> SGML"> SOAP"> SRU"> SRW"> SUTRS"> USMARC"> XML"> XPATH"> XSLT"> Z39.50"> ZOOM"> ZeeReX"> ZOOM.NET"> yaz-5.37.0/doc/common/xml.dcl0000644000175000017500000001522115123757402014367 0ustar00adamadam" PIC "?>" SHORTREF NONE NAMES SGMLREF QUANTITY NONE ENTITIES "amp" 38 "lt" 60 "gt" 62 "quot" 34 "apos" 39 FEATURES MINIMIZE DATATAG NO OMITTAG NO RANK NO SHORTTAG STARTTAG EMPTY NO UNCLOSED NO NETENABL IMMEDNET ENDTAG EMPTY NO UNCLOSED NO ATTRIB DEFAULT YES OMITNAME NO VALUE NO EMPTYNRM YES IMPLYDEF ATTLIST NO DOCTYPE NO ELEMENT NO ENTITY NO NOTATION NO LINK SIMPLE NO IMPLICIT NO EXPLICIT NO OTHER CONCUR NO SUBDOC NO FORMAL NO URN NO KEEPRSRE YES VALIDITY TYPE ENTITIES REF ANY INTEGRAL YES APPINFO NONE SEEALSO "ISO 8879:1986//NOTATION Extensible Markup Language (XML) 1.0//EN" > yaz-5.37.0/doc/common/id.eps0000644000175000017500000004137715123757402014223 0ustar00adamadam%!PS-Adobe-3.0 EPSF-3.0 %%Creator: GIMP PostScript file plugin V 1.12 by Peter Kirchgessner %%Title: /home/adam/ID.eps %%CreationDate: Wed May 1 13:27:33 2002 %%DocumentData: Clean7Bit %%LanguageLevel: 2 %%Pages: 1 %%BoundingBox: 14 14 135 172 %%EndComments %%BeginProlog % Use own dictionary to avoid conflicts 10 dict begin %%EndProlog %%Page: 1 1 % Translate for offset 14.173228 14.173228 translate % Translate to begin of first scanline 0.000000 157.000000 translate 120.000000 -157.000000 scale % Image geometry 120 157 8 % Transformation matrix [ 120 0 0 157 0 0 ] % Strings to hold RGB-samples per scanline /rstr 120 string def /gstr 120 string def /bstr 120 string def {currentfile /ASCII85Decode filter /RunLengthDecode filter rstr readstring pop} {currentfile /ASCII85Decode filter /RunLengthDecode filter gstr readstring pop} {currentfile /ASCII85Decode filter /RunLengthDecode filter bstr readstring pop} true 3 %%BeginData: 16148 ASCII Bytes colorimage mf*=@B(7YXB%aEgJ,~> mf*=\g%!8eg%DTLJ,~> mf*=IN:CK\N8h)AJ,~> n,EBom5"aKZ2]=~> n,ECSmE>RsZ2]=~> n,EC-m:H@ nG`OP5j^?.5j,HQJ,~> nG`OacgApWchOgGJ,~> nG`OVE:%6 nG`KIlSAO"ZN#F~> nG`LJlc]@gZN#F~> nG`KflXg-rZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K#lSANQZN#F~> nG`LAlc]@^ZN#F~> nG`KIlXg-UZN#F~> nG`K=lSANkZN#F~> nG`LGlc]@dZN#F~> nG`K\lXg-hZN#F~> nG`L4lSAObZN#F~> nG`LZlc]A"ZN#F~> nG`LAlXg.MZN#F~> n,EB n,ECFmE>RfZ2]=~> n,EB[m:H?jZ2]=~> mf*9TmkXs3YlB4~> mf*:Ln&tdoYlB4~> mf*9nmq)R+YlB4~> mJd4X^[mio^[eT.J,~> mJd4bn+5ZBn,0BhJ,~> mJd4[ch"IDch4LAJ,~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> M>r)~> fDr35J,~> fDr5$J,~> fJBgFJ,~> fDr35J,~> fDr5$J,~> fJBgFJ,~> fDr35J,~> fDr5$J,~> fJBgFJ,~> fDr35J,~> fDr5$J,~> fJBgFJ,~> fDr35J,~> fDr5$J,~> fJBgFJ,~> pAk3,oDel[rk8OC!%5LpAGcH*1B= pAk3,oDel[rk8OH!%5LpAGcH*bQ-o,ncA4:o$%%&!9s4$!n-Z+rQG?-o$[0S!oNS"pWS-~> pG;floJ6KNrlYI,1K2K?KD[P'AcTLCf`BEknn.gQ!5/#;!dWJ=rFQ,Dfm34%!h\.upL\p~> pAk3moDem*rr3.P!!*'!JG]EF1C)/(bfoYXk?7F5!WV?^bQ+O51C(\pN&*82s1e.]!h'(#pG7=~> pAk3moDem*rr3.P!!*'!JG]EFbQm_=o()_Ypt#)]!WVronc7qIbQmV:iloX%s6oR'!p9O9pWS-~> pG;gKoJ6Kjrr3.i1Gf(2RJ\l=Ad@#hg"H&um=Y%C!WVQdf`8\XAd?Z^WFfb.s3L:K!jhocpL\p~> pAk3moDem*rr3/b$3:,+JG]EF1BG`"r\FV7s6'#1!WSSX1C$29nl\]Xk pAk3moDem*rr3/s%flY0JG]EFbQ7;7rlbH's7l61!WV pG;gKoJ6Kjrr3/h4#?p:RJ\l=Ac^Tbral52s6]Gj!WTLrAd<;Jon.P_m;VZ/!jhocpL\p~> pAk3moDem*rVm"N!<<(LquHXN!R1TB1BOo_JFt]!s-`@4"_Refbl;;G1BO!EB(n*3~> pAk3moDem*rVm"N!<<(LquHZ=!V69hbQ@/2ht>1os5rgp"kiqKo)ID6bQ?r,g%W^@~> pG;gKoJ6KjrVm"g1]RKCr%n7_!SRMOAcg!PTCldss0M3,"cWK@g&I$%Acf==N;$q7~> pAk3moDf33s1[Cjk6h7hJG]EF1BG`"rA+Les-`O9!WV?^bQ(f;1BXNSs-`C5!h'(#pG7=~> pAk3moDf33s1[Cjp^dE)JG]EFbQ7;7rQG>rs5s!u!WVronc784bQI,0s5rjq!p9O9pWS-~> pG;gKoJ6fss3'R)m5t@JRJ\l=Ac^TbrFQ+is0MB1!WVQdf`6ZrAco^Gs0M6-!jhocpL\p~> pAk3moDf33s1W%Ds+(.LJG]EF1BG`"rA+Les-`O9!WV?^bQ(f;1BX'Fs-`C5!h'(#pG7=~> pAk3moDf33s1W%Ds+(.LJG]EFbQ7;7rQG>rs5s!u!WVronc784bQI#-s5rjq!p9O9pWS-~> pG;gKoJ6fss3$&ps-`oeRJ\l=Ac^TbrFQ+is0MB1!WVQdf`6ZrAcoC>s0M6-!jhocpL\p~> pAk3moDf33s1SKjs6'F^JG]EF1BG`"rA+Lrs-`O9!WSSW1Bgq]bif"/nhU?8s(;!]J,~> pAk3moDf33s1SKjs7lWoJG]EFbQ7;7rQG>us5s!u!WV pG;gKoJ6fss3!4\s6]jdRJ\l=Ac^TbrFQ+ss0MB1!WTLqAd*heg$Sflnn%s0s,?\aJ,~> pAk3moDf$.s5*ferVlkJquHXN!R1TB1BQ80=nOQOs-`C5#=.JC9kOFg5k?c5RK$mn1Oo~> pAk3moDf$.s5*ferVlkJquHZ=!V69hbQ@J;f(I5fs5rjq#LE2Cdb4Zqch#?^k5X-/b^]~> pG;gKoJ6Wns5l+irVlkcr%n7_!SRMOAcgulKCrgWs0M6-#B9)'H&VdjE:[ZCZi?!YAq0~> pAk3moDf'/s8N'!huR!WTM*AcQ!,1C(8dN&*8es/,BD!h'(#pG7=~> pAk3moDf'/s8N'!hu pG;gKoJ6Zos8Ol2k5PA\RJ\l=Ad@#hN/XCgs2O\C!WU1=Mu\M'Ad??UWFfbTs1Ir8!jhocpL\p~> pAk3moDf'/s8N'!AH)T/JG]EF1B>YtrrM\Yo/$=E!6k-m!d"Ccr\FXAg&H-c1BO!EB(n*3~> pAk3moDf'/s8N'!AH)T/JG]EFbQ.54rrN&[o?@.4!:oj-!o3hHrlbJjp&Eh>bQ?r,g%W^@~> pG;gKoJ6Zos8Ol2KDtlNRJ\l=AcUN_rrMf!o4Iq#!87'X!g`l>ral7Oir>>:Acf==N;$q7~> pAk1ZoDeq?6:1YOr^$T4quHXN!*T;5!*ShJr+5q3p+lbQAjH;N!_m90oJ6PCAjH)HJ,~> pAk1ZoDeq?6:1YOr^$T4quHZ=!7q/&!7p\ar7M)$p<3Thg!BW@!n,cQoZRBbg!BE:J,~> pG;e]oJ6PIB4q3"rau40r%n7_!/(90!/'fRr/:W.p1=AYN,\`-!dT`WoO\/MN,\N'J,~> fDr35J,~> fDr5$J,~> fJBgFJ,~> fDr35J,~> fDr5$J,~> fJBgFJ,~> fDr35J,~> fDr5$J,~> fJBgFJ,~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> qD/DFs7/E21M6ZTr%n6N!5AF3!oKGWq>gCK!1Ecb!+tp\!iH!cr\FUYs4R!"s31'j!h')4r\FUf s(;*`J,~> qTK6-s8:3ebh<$Yr65'=!5AF3!oKGWq>gE:!9X4Z!87(i!pTaIrlbGps7Q!-s75d*!p9ORrlbGs s4R7mJ,~> qIU#>s7L>CArQbrr+>j_!6b?@!p6\=qD8"\!42V'!0$V`!keQ>ral4as5NW^s4R!U!jhp[ral4j s,?edJ,~> qD/DFs8SKC1M6ZTr%n6N!5A=0!1Ncbq_J;As0M]m!) qTK6-s8V6*bh<$Yr65'=!5A=0!1Ncbqof-(s6TaI!7LSb#g`;Gf$)A2s46ecs75d*#j20ehos qIU#>s8TE;ArQbrr+>j_!6b6=!3c8Uqdoo9s2P&E!."9M#]T22K4\`Ts+BoTs4R!U#daR2T4V\o s,?edJ,~> qD/DFs75_G1M6ZTr%n6N"ht$:6:..?rr?U-!;ePRRK$mh1BqIkfg)G7N:Je)bk!UrRK)I51G`YC B)4<6~> qTK6-s8;f@bh<$Yr65'="ht$:6:..?rr?U-!;jtAk5X-)bQcc#p!;n&ipt=no(1'2k5Y5Obfnc? g%rpC~> qIU#>s7Q&(ArQbrr+>j_"j?rGB4nFIrr@]L1](bcZi?!SAd44oic)R1WUa[$g%/e]ZiBF[AnI#% N;@.:~> qD/DFs-`nn1M6ZTr%n6N!l"^7rW!%Ns8Th2!;ePRRK$mg1Ba-Gbl>oW1]P\j1C0EKJH)#nB)cK> 1Oo~> qTK6-s5s@Jbh<$Yr65'=!l"^7rW!%Ns8Th2!;jtAk5X-(bQR).o)J:Nbl@8*bR!A2huDi_g&Kb% b^]~> qIU#>s0MaFArQbrr+>j_!mCWDr\FYEs8U:?1](bcZi?!RAd#I?g&KaqB)gQUAdGaCTDu60N;nk5 Aq0~> qD/DFs(8V;9kOEnr%n6N!l"^7rW!$es8Th2!;ePRRK(t>bjmOlg&LV.nMC3ho.pZ?s"i@!5\C%. qD3X~> qTK6-s4Qc=db4Z_r65'=!l"^7rW!$es8Th2!;jtAk5Y,Ro((!,p&Fs9n]_%(o?7L&s3106ce8?O qTOH~> qIU#>s,=ttH&Vd0r+>j_!mCWDr\FXhs8U:?1](bcZiB%ag%&_WirA[jnRhgSo4A97s(:9`E/agU qIY6~> qD/DFs(5"*b\$mCr%n6N!l"^7rW!$es8Th2!;ePRRK(t>bk!Un5k=sTB(7\Wbk!UrRK#'Ts-[L! B)4<6~> qTK6-s4Pj#o%F'*r65'=!l"^7rW!$es8Th2!;jtAk5Y,Ro(1'.ci!hCg%!;do(1'2k5WZYs5r#7 g%rpC~> qIU#>s,;7'fo5s;r+>j_!mCWDr\FXhs8U:?1](bcZiB%ag%/eYE:s82N:CN[g%/e]Zi=Wrs0I[a N;@.:~> qD/DFs(4'Ts-`nTr%n6N!l"^7rW!%Ns8Th2!;ePRRK$mg1BkPnN;r'+nh^ qTK6-s4PWYs5s@Dr65'=!l"^7rW!%Ns8Th2!;jtAk5X-(bQ[J8irAf"o$%.)o?7L&s3/^Xs53k0 qTOH~> qIU#>s,:Qrs0Ma3r+>j_!mCWDr\FYEs8U:?1](bcZi?!RAd-N\WW2@)nn.pTo4A97s(5lrs.B=M qIY6~> qD/DFs(4&Po()gKr%n6N"ht$:!%3 qTK6-s4PWBr;?TWr65'="ht$:!%3 qIU#>s,:Q/p%A?kr+>j_"j?rG1K0_@rr@]L1](bcZi?!SAd577]OnMMcgk]Jg%/e]Zi=WLH2m:3 N;@.:~> qD/DFs(4&CRK*;Tr%n6N!5A=0!1Ncbq_J;As0M]m!) qTK6-s4PW?k5YJDr65'=!5A=0!1Ncbqof-(s6TaI!7LSb#hJqKccjW+s53Fls75d*!TsF]bQI53 s4R7mJ,~> qIU#>s,:Q%ZiC'3r+>j_!6b6=!3c8Uqdoo9s2P&E!."9M#_Vg;E+W_As.Amps4R!U!OMh*Acp'Q s,?edJ,~> qD/2@s(;6d!pBTOr%n6N!5AC2!PW+@!;ePPRJd'bB(e"^g&G[`1BUABnkJa4s31'j!L`ue1BTo5 s(;*`J,~> qTK$'s4RCq!r2fXr65'=!5AC2!PW+@!;jt?k5>5Zg%NVkp&E_EbQH;kr6k5]s75d*!TsF]bQH2h s4R7mJ,~> qITf8s,?qh!q$#or+>j_!6bOom-1As4R!U!OMh*Acm#F s,?edJ,~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> qD/,>rVloOJGM)!!!'b1rr@TH!;nVSg&G[`1BP>kF7_6iB)e:j1]RITRJnuCbl@Am!6kEA!SMPh 1Oo~> qTJs%rVlokhtkRo!!'b1rr@TH!;t%Bp&E_EbQ@85h"8elg&L4+bl@\Ck5NR*o)JF-!:p*g!VP7C b^]~> qIT`6rVloXTDE0s1B>VqrrAJa1]1hdir=u:AcgN!TKF? Aq0~> qD/AEs,;#ekPqmc1]%.P^AIp1JGT?E1C%(_kVo; VYN#u~> qTK3,s5Mhrq#B^XbkhA?^AIp1JGT?EbQl`!ps71>s6oR'!nmV9o?@46"ObN qITu=s/DRJSf qD/DFs(4&C5hZ0fr%n3M"2=g86MCKW1Brg<^J4:^5k?c5B)e:j1C*sCs0FL;bl@Am!R1TC1BTo* s&o1SJ,~> qTK6-s4PW?ch7=qr65$<"2=g86MCKWbQd),n'_./ch#?^g&L4+bQn1Cs6RtRo)JF-!V69ibQH2d s47%jJ,~> qIU#>s,:Q%E8pnir+>g^"3^`EBD44ZAd577c[#3NE:[ZCN;p6UAdAA's2JY_g&LbX!SRMPAcm#> s+C/[J,~> qD/2@s(;6d!_r^0r%n3M"2=g8AH"mq$Msi"1Bbr%kPo/b1BM1gRI`3>s3.hL=Yn;%p+l`ns8=_T F8r-61Oo~> qTK$'s4RCq!n.,;r65$<"2=g8AH"mq&,QA'bQRM:q#B% qITf8s,?qh!dXglr+>g^"3^`EKDoK`48Ui1Ad$femJi.9AcdqkZh%c6s4PElK4`g:p1=?Ys8?O2 QN+VoAq0~> qD/2@s(;3c!WUCA1]%.P^AIp16MgcZ1BUAOs/, qTK$'s4R@p!WV`gbkhA?^AIp16MgcZbQH;ns69't!nmV9o?7I>o$[I,bjtf-bQ7;7rQG>hs76$1 J,~> qITf8s,?ng!WUjNB)=@abPV;>BDXL]Acm>Ys1Il6!f[/co4A7-fm38DB%d4XAc^TbrFQ+Ms4R6\ J,~> qD/2@s(;3c!WUCA1]%.S^An5jrk8@[qZ-IK"I];inj)b%!bVJ#o.pXObVP[eB$C;K1BG`"rA+L? s31 qTK$'s4R@p!WV`gbkhAB^An5jrk8@[qZ-K:"Qoaar6OrX!nmV9o?7I>o$$7rg%,1:bQ7;7rQG>h s76$1J,~> qITf8s,?ng!WUjNB)=@dbQ%V)rlY:?q_S(\"LJ..ol0J6!f[/co4A7-fk.SjN7n7)Ac^TbrFQ+M s4R6\J,~> qD/2@s(;6d!a5Q0r%n3M"2=g86MCKW1Bgq]b`)S:nhU>Zs-`I7#QN"(5k qTK$'s4RCq!nRD qITf8s,?qh!e^Nmr+>g^"3^`EBD44ZAd*hefr>"tnn%r^s0M qD/DFs(4&C5hZ0Lr%n3M"2=g8AH"mq-i3oA1C$2.nkCpas,?P*!bVJ#o.pOLbVM&6rr;[J!R1TC 1BUeNs%W>GJ,~> qTK6-s4PW?ch7=kr65$<"2=g8AH"mq-i3oAbQlJhr6ig[s5NXo!nmV9o?7@;o$#>;rr;]9!V69i bQHGos3gbfJ,~> qIU#>s,:Q%E8pnVr+>g^"3^`EKDoK`;u8BKAd<;Bom(0&s/GU%!f[/co4A.*fk+iqrr;\(!SRMP Acm\Ys*=HQJ,~> qD/AEs0J-;o)H&n1]%.P^AIp1JGT?E1C1>eN&*7ao(#rU1BM1gRI`38s31Hu!pBU`p+lrts-]b. s8RWF1Oo~> qTK3,s6Sn=r;Z-\bkhA?^AIp1JGT?EbR!S8iloWpr;>. qITu=s2MCup&E&/B)=@abPV;>RJSf qD/,>rr3&D^LmYurrUEN B)"04~> qTJs%rr3&jn(IQ]qZ$W1qu6YHqZ-T=!o3hHrQG>us7Q$.!nmV9o?778o)?i7h#IEJbQ.55rrVcX g%`dA~> qIT`6rr3&Qc]%^4q_J5qqu6Yaq_S1_!g`l>rFQ+ss5NZ_!f[/co4A%'g&>RbQN.!YAcUN`rrUln N;."8~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> q(i"9r+5q'q_S-M#q&&+-NF,o6:*'t!;SDO9kNuQ!^L@0rA+Id:%gCAAcPQr1B9] q9/ibr7M(uqons<#q&&+-NF,o6:*'t!;Xh>db469!mfQQrQG;qde:o`f`9IkbQ,uef`9Irb^]~> q.9VGr/:W$qe#a^#ubJL;_p4.B4k0@1\kV`H&V?,!cX*WrFQ(hH1kkKMu\.oAcQfJMu\/!Aq0~> q(i"_r;Qbbq_S-M$%W'UhZ*Z6s8PF`!;SDORK)k7"(qT5B)XRes-`R:r;Qf\B(RkZB)MZ/RJAXh~> q9/ilr;QcZqons<$%W'UhZ*Z6s8PF`!;Xh>k5Y%s"53_Sg&B1rs5s%!r;Qfmg% q.9Vcr;Qc'qe#a^$(:hnjtegUs8Qa01\kV`ZiBW/"-!9[N;dDis0ME2r;QfbN:^]^N;W\UZh\3`~> q(i(as0M]:!)<>HqZ$lYs8QV?s8Th1!;SDORK)k7"(qT5g& q9/ons6Tak5Y%s"53_Sp& q.9\es2P%s!."HRq_JK>s8R_(s8U:>1\kV`ZiBW/"-!9[ir3Njs0ME2#QMf&N3i3WQM"hkN;omV Mu\/!Aq0~> q(i(as-`U;qZ$jfs8V!6s5td,!;SDORK)k7#\O+\s*um]s-`R:!WSSe1BL_ZkOgV4B)cK91Oo~> q9/ons5s("qZ$jfs8V!6s7du=!;Xh>k5Y%s#hf7Ks52&Es5s%!!WV<]bQ?Aqq";i4g&Kaub^]~> q.9\es0MH3q_JIis8V6Ds6Wb^1\kV`ZiBW/#`Sf:s. q(i(as0M]:!'pE;q>^N0rVlkJq>g=I!L`uZ1C.UmB'8>51]Nm:1BINDrA+M]s(:s\!bVIkratp] J,~> q9/ons6Ta^N0rVlkJq>g?8!TsFRbQuo%g%b?dbl?i!bQ7b+rQG?0s4R+i!nmV5rn7(j J,~> q.9\es2P%s!-%gIqD/,prVlkcqD7qZ!OMgtAdF@qN:$"EB)f42Ac_q q(i"_r;Qb/q_S'K!%7aFq#L4H!L`uZ1C.UmAq9oL1]Nm:1BINDrA+MCs(:s\!+u0/pbRF~> q9/ilr;QcMqonm:!%7aFq#L67!TsFRbQuo%g#)hlbl?i!bQ7b+rQG?*s4R+i!87;Mprn6~> q.9Vcr;QbUqe#[\!)rjrq(qhY!OMgtAdF@qN1^-VB)f42Ac_q q(i(as0M]:!'pE;q>^N0rVlkJq>g=I!L`uZ1C.UmAi%[%5l[8G1BINDrA+MCs(:s\!bVIkratp] J,~> q9/ons6Ta^N0rVlkJq>g?8!TsFRbQuo%g!'$bci q.9\es2P%s!-%gIqD/,prVlkcqD7qZ!OMgtAdF@qN+Uc9E q(i(as-`U;qZ$^bs8V!Urr=GD!;SDORK)k7#\O*K1M6Zas-`R:!WSSd1BQ805kZu8B)cK91Oo~> q9/ons5s("qZ$^bs8V!Urr=GD!;Xh>k5Y%s#hf72bh<$\s5s%!!WV<\bQ@J;ch>Qag&Kaub^]~> q.9\es0MH3q_J=es8V6\rr?!p1\kV`ZiBW/#`SeBArQc&s0ME2!WTM)AcgulE;!lFN;nk0Aq0~> q(i(as-`U;qu@!0huE^CRfEE%qZ-FJ!L`uZ1C.UmAhu6Xs8SM\1C*rJ1G_;&s0MAS!bVIEoeV*~> q9/ons5s("qu@!5huE^CRfEE%qZ-H9!TsFRbQuo%g!%\/s8V6TbQn11bfnE"s6TF&!nmV,ouqp~> q.9\es0MH3r%eU?k5YHoYQ+XGq_S%[!OMgtAdF@qN+Q\Js8TG!AdA@BAnH#%s2O_D!f[/ q(i(as6'C*!.ar&qu?nhs8Te5-iX,G6MpiZ1BEpDo.pYas(4&C:&k6]p+lsRkKM0Ms3*b$1BM1g g&B1qJGD!O~> q9/ons7lTa!8m[tqu?nhs8Te5-iX,G6MpiZbQ6l+o?7Kns4PW?df9@0p<3dAq"""Us74M/bQ?Jt p&=L^htbKH~> q.9\es6]g=!2'.#r%eM[s8U7u;uZdsBDaR]Ac]7 q(i"Rr6,.kq_S0N!"/_>"t'BNAA5dHquHOK!J&Dc1BL_'=oL2YREU3T1]>MuVK;>b!*T6D!.al$ J,~> q9/iir:0jFqoo!=!"](C"t'BNAA5dHquHQ:!T3J>bQ?Adf)Ekpk47F'bl.)5l.kmS!7q)=!8mUr J,~> q.9VZr7M(Bqe#d_!'C2'##d<6K?MHAr%n.\!MA':AcdV lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> lne#/Z87"~> m*+hsZHRh~> lt5W@Z=\U~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> qD/2'R8*Z:!^N0(j>-c\r#,S\0(Uk!0)cah0(^q",PrAZ,P3bl0)cah0).5Q~> qTK#uk0j7Q!mg#djNIU^r+?%g\F[oE\Gg+@\FduFMu.,eMtG3n\Gg+@\G49u~> qITf$Z[)O^!cYK qD/1os31Hu!l+bcj>-cSqZ$X()Y>fc)ZB^:%.l=U%/U#)%.l=U)ZB^:%/;W/~> qTK#rs7605!q60HjNIU:qZ$X-BCsCJBDql21%`Zi1&CqN1%`ZiBDql21&/tC~> qITeps4RB`!mgn=jCSBdq_J77:%W#t:&ZpK5P/Of5Pm5:5P/Of:&ZpK5PSi@~> q(i5is,8aTs1dSM"W@@@"q1_8!!!r11B7XX!!"YE1C"U&"onW-$l&=i!!`B%!&"('J,~> q90'3s5M8Xs6o!l"_Rf8)DN00!!$[)bQ&R[!!'P%bQh!")?9aU0i@Se!#ke9!4_jKJ,~> q.9iWs/BUrs3K_;"\gd/3BoP'1B:/BAcOji1B:kVAd:gj3AWHO5=b?X!'1!6!+G\8J,~> q(i4?kPo/bk q90&hq#B%Fps8!E$"j5 q.9hMmJi. pbMn^rr2t1i\LZT!!!r:1BRsa!&""%"r%%;/cYkUo.pIe!!!r/1BnNn!%n6O#5L'*~> pri`krr2uOilhL;!!$[2bQA@U!4_dI##P@#\,ZLIo?7;L!!$['bQ^oE!4W"/)YqU-~> pgsMbrr2tWiar9e1G_c)Ack+N1L^#i#"LI*@5B]"o4A)!1G_bsAd1a]1LW'q3Vd9;~> pG2m(s6&>s!u_.>)ZDMp$ig8PpbN1.!!!]h,6.]goJ6Rf!!!r01C,T5!#.46!!"8?1Oo~> pWN^3s7kQs"(qT6BE$*W0`V33prj#R!!#m?MZ pLXKds6\cW"&1R-:&\`,5;P)rpgse?1G_O5<\lO4oO\2"1G_btAdDg$1Il%X1G`).Aq0~> pbN&@s6'EMi\LZT!!!r:1BRg]!&"%&![@[FrXAf,!#5&]!u_.>)Y>fe,6.`C%0$;-'`'V9~> prim's7lWVilhL;!!$[2bQAa`!4_gJ!fI$Yr\=EQ!)`C4"(qT6BCsCLMZSLe~> pgsZ8s6]imiar9e1G_c)Ack%L1L^&j!`h*5r]gE=!(ZZn"&1R-:%W$!<\lQ25Q8,?hJ~> q(i4Xs4K[#s(::I#oWdD)Da/f!!!5t1B7XU!!*EZoeQ[g!!!r01B7XU!!*EZq_Na~> q90&os7O_5s4QGV$"j5 q.9h`s5J"bs,>uM#u*339kJ!31G_&cAcOjf1BBRGok";#1G_btAcOjf1BBRGqdt?~> qD/CBkOMb3B)h$Zj>-rX!!!33#6"T&)Yc)j/cYkUrYbkI!!"8:1BSNq!#kMd""jQR#6#MC$ig8P q_Na~> qTK5kq#&^eg&LinjNId?!!!ol)ZB^:BDB[Q\,ZLIrau qIU"PmIc*DN;r9ajCSQi1G_$U3W:f7:&&<&@5B]"r_3JZ1G`))Acka`1JROS"( qD/2Zs,?q5!h')'j>-cSqZ$X()YZ#i'EA+Or\FX$!!!5r1BSNq!#kMd!u(_8)ZDMp,6.]Jq_Na~> qTK$-s5O%%!p9OOjNIU:qZ$X-BD9UP;#gT/rlbJ&!!!r1bQDJX!,(uK"&T$uBE$*WMZ<_qqojQ~> qITfKs/H!0!jhpQjCSBdq_J77:%r6%7l)qqral751G_&aAcka`1JROS"%P.':&\`,<\lNlqdt?~> q_J:=R>h&"s-WjPjYHl]r#,S\0(q(',8qIQr\FO,rYkGc"!\^&,P qof,fk2Q<_s5j=-jid^_r+?%g\G",KMe?\4rlbAPrb(oJ",gf)MtP9rMe?\4rlbAPrb),PJ,~> qdonKZ`3k7s0D]Ej^nKnr(R2m@J4:8<_Z:sral.=r_<&t"'/,j M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> M)0Y~> M9LJ~> M.V8~> %%EndData showpage %%Trailer end %%EOF yaz-5.37.0/doc/common/id.htmlhelp.xsl0000644000175000017500000000124615123757402016045 0ustar00adamadam 0 1 1 3 3 1 yaz-5.37.0/doc/common/id.tkl.xsl0000644000175000017500000000260715123757402015024 0ustar00adamadam 1 .tkl 0 <xsl:apply-templates select="." mode="object.title.markup"/> 1 yaz-5.37.0/doc/common/print.dsl.in0000644000175000017500000000107215123757402015347 0ustar00adamadam ]> (define preferred-mediaobject-notations (list "PDF" "JPG" "JPEG" "PNG" "linespecific")) (define preferred-mediaobject-extensions (list "pdf" "jpg" "jpeg" "png")) yaz-5.37.0/doc/common/stripref.xsl0000644000175000017500000000047215123757402015473 0ustar00adamadam Generated by stripref.xsl . Do not edit yaz-5.37.0/doc/common/README0000644000175000017500000000012215123757402013755 0ustar00adamadamThis directory contains various common files for our Docbook based documentation. yaz-5.37.0/doc/common/Makefile.in0000644000175000017500000003715615130444201015147 0ustar00adamadam# Makefile.in generated by automake 1.18.1 from Makefile.am. # @configure_input@ # Copyright (C) 1994-2025 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY, to the extent permitted by law; without # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. @SET_MAKE@ VPATH = @srcdir@ am__is_gnu_make = { \ if test -z '$(MAKELEVEL)'; then \ false; \ elif test -n '$(MAKE_HOST)'; then \ true; \ elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \ true; \ else \ false; \ fi; \ } am__make_running_with_option = \ case $${target_option-} in \ ?) ;; \ *) echo "am__make_running_with_option: internal error: invalid" \ "target option '$${target_option-}' specified" >&2; \ exit 1;; \ esac; \ has_opt=no; \ sane_makeflags=$$MAKEFLAGS; \ if $(am__is_gnu_make); then \ sane_makeflags=$$MFLAGS; \ else \ case $$MAKEFLAGS in \ *\\[\ \ ]*) \ bs=\\; \ sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \ | sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \ esac; \ fi; \ skip_next=no; \ strip_trailopt () \ { \ flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \ }; \ for flg in $$sane_makeflags; do \ test $$skip_next = yes && { skip_next=no; continue; }; \ case $$flg in \ *=*|--*) continue;; \ -*I) strip_trailopt 'I'; skip_next=yes;; \ -*I?*) strip_trailopt 'I';; \ -*O) strip_trailopt 'O'; skip_next=yes;; \ -*O?*) strip_trailopt 'O';; \ -*l) strip_trailopt 'l'; skip_next=yes;; \ -*l?*) strip_trailopt 'l';; \ -[dEDm]) skip_next=yes;; \ -[JT]) skip_next=yes;; \ esac; \ case $$flg in \ *$$target_option*) has_opt=yes; break;; \ esac; \ done; \ test $$has_opt = yes am__make_dryrun = (target_option=n; $(am__make_running_with_option)) am__make_keepgoing = (target_option=k; $(am__make_running_with_option)) am__rm_f = rm -f $(am__rm_f_notfound) am__rm_rf = rm -rf $(am__rm_f_notfound) pkgdatadir = $(datadir)/@PACKAGE@ pkgincludedir = $(includedir)/@PACKAGE@ pkglibdir = $(libdir)/@PACKAGE@ pkglibexecdir = $(libexecdir)/@PACKAGE@ am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd install_sh_DATA = $(install_sh) -c -m 644 install_sh_PROGRAM = $(install_sh) -c install_sh_SCRIPT = $(install_sh) -c INSTALL_HEADER = $(INSTALL_DATA) transform = $(program_transform_name) NORMAL_INSTALL = : PRE_INSTALL = : POST_INSTALL = : NORMAL_UNINSTALL = : PRE_UNINSTALL = : POST_UNINSTALL = : build_triplet = @build@ host_triplet = @host@ subdir = doc/common ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/m4/ac_check_icu.m4 \ $(top_srcdir)/m4/acx_pthread.m4 $(top_srcdir)/m4/libtool.m4 \ $(top_srcdir)/m4/ltoptions.m4 $(top_srcdir)/m4/ltsugar.m4 \ $(top_srcdir)/m4/ltversion.m4 $(top_srcdir)/m4/lt~obsolete.m4 \ $(top_srcdir)/m4/yaz.m4 $(top_srcdir)/m4/yaz_libxml2.m4 \ $(top_srcdir)/configure.ac am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON) mkinstalldirs = $(install_sh) -d CONFIG_HEADER = $(top_builddir)/src/config.h CONFIG_CLEAN_FILES = print.dsl CONFIG_CLEAN_VPATH_FILES = AM_V_P = $(am__v_P_@AM_V@) am__v_P_ = $(am__v_P_@AM_DEFAULT_V@) am__v_P_0 = false am__v_P_1 = : AM_V_GEN = $(am__v_GEN_@AM_V@) am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@) am__v_GEN_0 = @echo " GEN " $@; am__v_GEN_1 = AM_V_at = $(am__v_at_@AM_V@) am__v_at_ = $(am__v_at_@AM_DEFAULT_V@) am__v_at_0 = @ am__v_at_1 = SOURCES = DIST_SOURCES = am__can_run_installinfo = \ case $$AM_UPDATE_INFO_DIR in \ n|no|NO) false;; \ *) (install-info --version) >/dev/null 2>&1;; \ esac am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; am__vpath_adj = case $$p in \ $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \ *) f=$$p;; \ esac; am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`; am__install_max = 40 am__nobase_strip_setup = \ srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'` am__nobase_strip = \ for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||" am__nobase_list = $(am__nobase_strip_setup); \ for p in $$list; do echo "$$p $$p"; done | \ sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \ $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \ if (++n[$$2] == $(am__install_max)) \ { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \ END { for (dir in files) print dir, files[dir] }' am__base_list = \ sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \ sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g' am__uninstall_files_from_dir = { \ { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \ || { echo " ( cd '$$dir' && rm -f" $$files ")"; \ $(am__cd) "$$dir" && echo $$files | $(am__xargs_n) 40 $(am__rm_f); }; \ } am__installdirs = "$(DESTDIR)$(commondir)" DATA = $(common_DATA) am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP) am__DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/print.dsl.in README DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) ACLOCAL = @ACLOCAL@ AMTAR = @AMTAR@ AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@ AR = @AR@ AUTOCONF = @AUTOCONF@ AUTOHEADER = @AUTOHEADER@ AUTOMAKE = @AUTOMAKE@ AWK = @AWK@ CC = @CC@ CCDEPMODE = @CCDEPMODE@ CFLAGS = @CFLAGS@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CSCOPE = @CSCOPE@ CTAGS = @CTAGS@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ DLLTOOL = @DLLTOOL@ DSSSL_DIR = @DSSSL_DIR@ DSYMUTIL = @DSYMUTIL@ DTD_DIR = @DTD_DIR@ DUMPBIN = @DUMPBIN@ ECHO_C = @ECHO_C@ ECHO_N = @ECHO_N@ ECHO_T = @ECHO_T@ EGREP = @EGREP@ ETAGS = @ETAGS@ EXEEXT = @EXEEXT@ FGREP = @FGREP@ FILECMD = @FILECMD@ GREP = @GREP@ HIREDIS_LIBS = @HIREDIS_LIBS@ HTML_COMPILE = @HTML_COMPILE@ ICU_CFLAGS = @ICU_CFLAGS@ ICU_CONFIG = @ICU_CONFIG@ ICU_CPPFLAGS = @ICU_CPPFLAGS@ ICU_LIBS = @ICU_LIBS@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ LD = @LD@ LDFLAGS = @LDFLAGS@ LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ LIPO = @LIPO@ LN_S = @LN_S@ LTLIBOBJS = @LTLIBOBJS@ LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@ MAKEINFO = @MAKEINFO@ MANIFEST_TOOL = @MANIFEST_TOOL@ MAN_COMPILE = @MAN_COMPILE@ MEMCACHED_LIBS = @MEMCACHED_LIBS@ MKDIR_P = @MKDIR_P@ NM = @NM@ NMEDIT = @NMEDIT@ OBJDUMP = @OBJDUMP@ OBJEXT = @OBJEXT@ OTOOL = @OTOOL@ OTOOL64 = @OTOOL64@ PACKAGE = @PACKAGE@ PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@ PACKAGE_NAME = @PACKAGE_NAME@ PACKAGE_STRING = @PACKAGE_STRING@ PACKAGE_TARNAME = @PACKAGE_TARNAME@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ PDF_COMPILE = @PDF_COMPILE@ PKG_CONFIG = @PKG_CONFIG@ PTHREAD_CC = @PTHREAD_CC@ PTHREAD_CFLAGS = @PTHREAD_CFLAGS@ PTHREAD_LIBS = @PTHREAD_LIBS@ RANLIB = @RANLIB@ READLINE_LIBS = @READLINE_LIBS@ SED = @SED@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ SSL_CFLAGS = @SSL_CFLAGS@ SSL_LIBS = @SSL_LIBS@ STRIP = @STRIP@ TCLSH = @TCLSH@ TCPD_LIBS = @TCPD_LIBS@ TKL_COMPILE = @TKL_COMPILE@ VERSION = @VERSION@ VERSION_HEX = @VERSION_HEX@ VERSION_SHA1 = @VERSION_SHA1@ WIN_FILEVERSION = @WIN_FILEVERSION@ XML2_CFLAGS = @XML2_CFLAGS@ XSLTPROC_COMPILE = @XSLTPROC_COMPILE@ XSL_DIR = @XSL_DIR@ YACC = @YACC@ YAZ_CONFIG_CFLAGS = @YAZ_CONFIG_CFLAGS@ YAZ_CONF_CFLAGS = @YAZ_CONF_CFLAGS@ abs_builddir = @abs_builddir@ abs_srcdir = @abs_srcdir@ abs_top_builddir = @abs_top_builddir@ abs_top_srcdir = @abs_top_srcdir@ ac_ct_AR = @ac_ct_AR@ ac_ct_CC = @ac_ct_CC@ ac_ct_DUMPBIN = @ac_ct_DUMPBIN@ acx_pthread_config = @acx_pthread_config@ am__include = @am__include@ am__leading_dot = @am__leading_dot@ am__quote = @am__quote@ am__rm_f_notfound = @am__rm_f_notfound@ am__tar = @am__tar@ am__untar = @am__untar@ am__xargs_n = @am__xargs_n@ bindir = @bindir@ build = @build@ build_alias = @build_alias@ build_cpu = @build_cpu@ build_os = @build_os@ build_vendor = @build_vendor@ builddir = @builddir@ datadir = @datadir@ datarootdir = @datarootdir@ docdir = @docdir@ dvidir = @dvidir@ exec_prefix = @exec_prefix@ host = @host@ host_alias = @host_alias@ host_cpu = @host_cpu@ host_os = @host_os@ host_vendor = @host_vendor@ htmldir = @htmldir@ includedir = @includedir@ infodir = @infodir@ install_sh = @install_sh@ libdir = @libdir@ libexecdir = @libexecdir@ localedir = @localedir@ localstatedir = @localstatedir@ mandir = @mandir@ mkdir_p = @mkdir_p@ oldincludedir = @oldincludedir@ pdfdir = @pdfdir@ pkgconfigpath = @pkgconfigpath@ prefix = @prefix@ program_transform_name = @program_transform_name@ psdir = @psdir@ runstatedir = @runstatedir@ sbindir = @sbindir@ sharedstatedir = @sharedstatedir@ srcdir = @srcdir@ sysconfdir = @sysconfdir@ target_alias = @target_alias@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ commondir = $(datadir)/doc/$(PACKAGE)$(PACKAGE_SUFFIX)/common common_DATA = style1.css id.png SUPPORTFILES = \ xml.dcl \ common.ent \ id.eps \ ref2dbinc.xsl \ stripref.xsl \ print.dsl.in \ id.htmlhelp.xsl \ id.man.xsl \ id.tkl.xsl EXTRA_DIST = $(SUPPORTFILES) $(common_DATA) README all: all-am .SUFFIXES: $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps) @for dep in $?; do \ case '$(am__configure_deps)' in \ *$$dep*) \ ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \ && { if test -f $@; then exit 0; else break; fi; }; \ exit 1;; \ esac; \ done; \ echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu doc/common/Makefile'; \ $(am__cd) $(top_srcdir) && \ $(AUTOMAKE) --gnu doc/common/Makefile Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status @case '$?' in \ *config.status*) \ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \ *) \ echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \ cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \ esac; $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(top_srcdir)/configure: $(am__configure_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(ACLOCAL_M4): $(am__aclocal_m4_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(am__aclocal_m4_deps): print.dsl: $(top_builddir)/config.status $(srcdir)/print.dsl.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ mostlyclean-libtool: -rm -f *.lo clean-libtool: -rm -rf .libs _libs install-commonDATA: $(common_DATA) @$(NORMAL_INSTALL) @list='$(common_DATA)'; test -n "$(commondir)" || list=; \ if test -n "$$list"; then \ echo " $(MKDIR_P) '$(DESTDIR)$(commondir)'"; \ $(MKDIR_P) "$(DESTDIR)$(commondir)" || exit 1; \ fi; \ for p in $$list; do \ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ echo "$$d$$p"; \ done | $(am__base_list) | \ while read files; do \ echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(commondir)'"; \ $(INSTALL_DATA) $$files "$(DESTDIR)$(commondir)" || exit $$?; \ done uninstall-commonDATA: @$(NORMAL_UNINSTALL) @list='$(common_DATA)'; test -n "$(commondir)" || list=; \ files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \ dir='$(DESTDIR)$(commondir)'; $(am__uninstall_files_from_dir) tags TAGS: ctags CTAGS: cscope cscopelist: distdir: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) distdir-am distdir-am: $(DISTFILES) @srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ list='$(DISTFILES)'; \ dist_files=`for file in $$list; do echo $$file; done | \ sed -e "s|^$$srcdirstrip/||;t" \ -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \ case $$dist_files in \ */*) $(MKDIR_P) `echo "$$dist_files" | \ sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \ sort -u` ;; \ esac; \ for file in $$dist_files; do \ if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \ if test -d $$d/$$file; then \ dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \ if test -d "$(distdir)/$$file"; then \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \ cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \ else \ test -f "$(distdir)/$$file" \ || cp -p $$d/$$file "$(distdir)/$$file" \ || exit 1; \ fi; \ done check-am: all-am check: check-am all-am: Makefile $(DATA) installdirs: for dir in "$(DESTDIR)$(commondir)"; do \ test -z "$$dir" || $(MKDIR_P) "$$dir"; \ done install: install-am install-exec: install-exec-am install-data: install-data-am uninstall: uninstall-am install-am: all-am @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am installcheck: installcheck-am install-strip: if test -z '$(STRIP)'; then \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ install; \ else \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \ fi mostlyclean-generic: clean-generic: distclean-generic: -$(am__rm_f) $(CONFIG_CLEAN_FILES) -test . = "$(srcdir)" || $(am__rm_f) $(CONFIG_CLEAN_VPATH_FILES) maintainer-clean-generic: @echo "This command is intended for maintainers to use" @echo "it deletes files that may require special tools to rebuild." clean: clean-am clean-am: clean-generic clean-libtool mostlyclean-am distclean: distclean-am -rm -f Makefile distclean-am: clean-am distclean-generic dvi: dvi-am dvi-am: html: html-am html-am: info: info-am info-am: install-data-am: install-commonDATA install-dvi: install-dvi-am install-dvi-am: install-exec-am: install-html: install-html-am install-html-am: install-info: install-info-am install-info-am: install-man: install-pdf: install-pdf-am install-pdf-am: install-ps: install-ps-am install-ps-am: installcheck-am: maintainer-clean: maintainer-clean-am -rm -f Makefile maintainer-clean-am: distclean-am maintainer-clean-generic mostlyclean: mostlyclean-am mostlyclean-am: mostlyclean-generic mostlyclean-libtool pdf: pdf-am pdf-am: ps: ps-am ps-am: uninstall-am: uninstall-commonDATA .MAKE: install-am install-strip .PHONY: all all-am check check-am clean clean-generic clean-libtool \ cscopelist-am ctags-am distclean distclean-generic \ distclean-libtool distdir dvi dvi-am html html-am info info-am \ install install-am install-commonDATA install-data \ install-data-am install-dvi install-dvi-am install-exec \ install-exec-am install-html install-html-am install-info \ install-info-am install-man install-pdf install-pdf-am \ install-ps install-ps-am install-strip installcheck \ installcheck-am installdirs maintainer-clean \ maintainer-clean-generic mostlyclean mostlyclean-generic \ mostlyclean-libtool pdf pdf-am ps ps-am tags-am uninstall \ uninstall-am uninstall-commonDATA .PRECIOUS: Makefile # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: # Tell GNU make to disable its built-in pattern rules. %:: %,v %:: RCS/%,v %:: RCS/% %:: s.% %:: SCCS/s.% yaz-5.37.0/doc/common/id.man.xsl0000644000175000017500000000031315123757402014775 0ustar00adamadam yaz-5.37.0/doc/common/Makefile.am0000644000175000017500000000044615123757402015142 0ustar00adamadamcommondir=$(datadir)/doc/$(PACKAGE)$(PACKAGE_SUFFIX)/common common_DATA = style1.css id.png SUPPORTFILES = \ xml.dcl \ common.ent \ id.eps \ ref2dbinc.xsl \ stripref.xsl \ print.dsl.in \ id.htmlhelp.xsl \ id.man.xsl \ id.tkl.xsl EXTRA_DIST = $(SUPPORTFILES) $(common_DATA) README yaz-5.37.0/doc/yaz-client.10000644000175000017500000005134015130444225013750 0ustar00adamadam'\" t .\" Title: yaz-client .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-CLIENT" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-client \- Z39\&.50/SRU client for implementors .SH "SYNOPSIS" .HP \w'\fByaz\-client\fR\ 'u \fByaz\-client\fR [\fB\-a\ \fR\fB\fIapdulog\fR\fR] [\fB\-b\ \fR\fB\fIberdump\fR\fR] [\fB\-c\ \fR\fB\fIcclfile\fR\fR] [\fB\-d\ \fR\fB\fIdump\fR\fR] [\fB\-f\ \fR\fB\fIcmdfile\fR\fR] [\fB\-k\ \fR\fB\fIsize\fR\fR] [\fB\-m\ \fR\fB\fImarclog\fR\fR] [\fB\-p\ \fR\fB\fIproxy\-addr\fR\fR] [\fB\-q\ \fR\fB\fIcqlfile\fR\fR] [\fB\-t\ \fR\fB\fIdispcharset\fR\fR] [\fB\-u\ \fR\fB\fIauth\fR\fR] [\fB\-v\ \fR\fB\fIloglevel\fR\fR] [\fB\-V\fR] [\fB\-x\fR] [server\-addr] .SH "DESCRIPTION" .PP \fByaz\-client\fR is a \m[blue]\fBZ39\&.50\fR\m[]\&\s-2\u[1]\d\s+2/\m[blue]\fBSRU\fR\m[]\&\s-2\u[2]\d\s+2 client (origin) with a simple command line interface that allows you to test behavior and performance of Z39\&.50 targets and SRU servers\&. .PP From YAZ version 4\&.1\&.0 \fByaz\-client\fR may also operate as a \m[blue]\fBSolr\fR\m[]\&\s-2\u[3]\d\s+2 Web Service client\&. .PP If the \fIserver\-addr\fR is specified, the client creates a connection to the Z39\&.50/SRU target at the address given\&. .PP When \fByaz\-client\fR is started it tries to read commands from one of the following files: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Command file if it is given by option \-f\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \&.yazclientrc in current working directory\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \&.yazclientrc in the user\*(Aqs home directory\&. The value of the $HOME environment variable is used to determine the home directory\&. Normally, $HOME is only set on POSIX systems such as Linux, FreeBSD, Solaris\&. .RE .sp .SH "OPTIONS" .PP \-a \fIfilename\fR .RS 4 If specified, logging of protocol packages will be appended to the file given\&. If \fIfilename\fR is specified as \-, the output is written to stdout\&. .RE .PP \-b \fIfilename\fR .RS 4 If specified, YAZ will dump BER data in readable notation to the file specified\&. If \fIfilename\fR is specified as \- the output is written to stdout\&. .RE .PP \-c \fIfilename\fR .RS 4 If specified, CCL configuration will be read from the file given\&. .RE .PP \-d \fIdump\fR .RS 4 If specified, YAZ will dump BER data for all PDUs sent and received to individual files, named \fIdump\fR\&.DDD\&.raw, where DDD is 001, 002, 003, \&.\&.\&. .RE .PP \-f \fIcmdfile\fR .RS 4 Reads commands from \fIcmdfile\fR\&. When this option is used, YAZ client does not read \&.yazclientrc from current directory or home directory\&. .RE .PP \-k \fIsize\fR .RS 4 Sets preferred messages and maximum record size for Initialize Request in kilobytes\&. Default value is 65536 (64 MB)\&. .RE .PP \-m \fIfilename\fR .RS 4 If specified, retrieved records will be appended to the file given\&. .RE .PP \-p \fIproxy\-addr\fR .RS 4 If specified, the client will use the proxy at the address given\&. YAZ client will connect to a proxy on the address and port given\&. The actual target will be specified as part of the InitRequest to inform the proxy about the actual target\&. .RE .PP \-q \fIfilename\fR .RS 4 If specified, CQL configuration will be read from the file given\&. .RE .PP \-t \fIdisplaycharset\fR .RS 4 If displaycharset is given, it specifies name of the character set of the output (on the terminal on which YAZ client is running)\&. .RE .PP \-u \fIauth\fR .RS 4 If specified, the \fIauth\fR string will be used for authentication\&. .RE .PP \-v \fIlevel\fR .RS 4 Sets the LOG level to \fIlevel\fR\&. Level is a sequence of tokens separated by comma\&. Each token is a integer or a named LOG item \- one of fatal, debug, warn, log, malloc, all, none\&. .RE .PP \-V .RS 4 Prints YAZ version\&. .RE .PP \-x .RS 4 Makes the YAZ client print hex dumps of packages sent and received on standard output\&. .RE .SH "COMMANDS" .PP The YAZ client accepts the following commands\&. .PP open \fIzurl\fR .RS 4 Opens a connection to a server\&. The syntax for \fIzurl\fR is the same as described above for connecting from the command line\&. .sp Syntax: .sp [(tcp|ssl|unix|http)\*(Aq:\*(Aq]\fIhost\fR [:\fIport\fR][/\fIbase\fR] .RE .PP quit .RS 4 Quits YAZ client .RE .PP find \fIquery\fR .RS 4 Sends a Search Request using the \fIquery\fR given\&. By default the query is assumed to be PQF\&. See command querytype for more information\&. .RE .PP delete \fIsetname\fR .RS 4 Deletes result set with name \fIsetname\fR on the server\&. .RE .PP base \fIbase1\fR \fIbase2\fR \&.\&.\&. .RS 4 Sets the name(s) of the database(s) to search\&. One or more databases may be specified, separated by blanks\&. This command overrides the database given in \fIzurl\fR\&. .RE .PP show [\fIstart\fR[+\fInumber\fR [+\fIresultset\fR]]] .RS 4 Fetches records by sending a Present Request from the start position given by \fIstart\fR and a number of records given by \fInumber\fR, from the result set \fIresultset\fR\&. If \fIstart\fR is not given, then the client will fetch from the position of the last retrieved record plus 1\&. If \fInumber\fR is not given, then one record will be fetched at a time\&. If \fIresultset\fR is not given, the most recently retrieved result set is used\&. .RE .PP scan \fIterm\fR .RS 4 Scans database index for a term\&. The syntax resembles the syntax for find\&. If you want to scan for the word water you could write .sp .if n \{\ .RS 4 .\} .nf scan water .fi .if n \{\ .RE .\} .sp but if you want to scan only in, say the title field, you would write .sp .if n \{\ .RS 4 .\} .nf scan @attr 1=4 water .fi .if n \{\ .RE .\} .RE .PP setscan \fIset\fR \fIterm\fR .RS 4 Scans database index for a term within a result set\&. This is similar to the scan command but has a result set as its first argument\&. .RE .PP scanpos \fIpos\fR .RS 4 Sets preferred position for scan\&. This value is used in the next scan\&. By default, position is 1\&. .RE .PP scansize \fIsize\fR .RS 4 Sets number of entries to be returned by scan\&. Default number of entries is 20\&. .RE .PP scanstep \fIstep\fR .RS 4 Set step\-size for scan\&. This value is used in the next scan sent to the target\&. By default step\-size is 0\&. .RE .PP sort \fIsortspecs\fR .RS 4 Sorts a result set\&. The sort command takes a sequence of space\-separated sort specifications, with each sort specification consisting of two space\-separated words (so that the whole specification list is made up of an even number of words)\&. The first word of each specification holds a field (sort criterion) and the second holds flags\&. If the sort criterion includes = it is assumed that the SortKey is of type sortAttributes using Bib\-1: in this case the integer before = is the attribute type and the integer following = is the attribute value\&. If no = character is in the criterion, it is treated as a sortfield of type InternationalString\&. The flags word of each sort specification must consist of s for case sensitive or i for case insensitive, and < for ascending order or > for descending order\&. .sp Example using sort criterion with attributes use=local\-number and structure=numeric and ascending flag: 1=12,4=109 < .sp Another example with "Title" sort field and descending flag: Title > .RE .PP sort+ .RS 4 Same as sort but stores the sorted result set in a new result set\&. .RE .PP authentication [\fIauth1\fR [\fIauth2\fR [\fIauth3\fR]]] .RS 4 Configures authentication strings to be sent to server\&. Zero, 1, 2 or 3 arguments may follow the auth command\&. .sp If no (0) arguments are given, no authentication string is sent\&. .sp If one argument is given, the Z39\&.50 v2 OpenStyle authentication is used\&. A common convention for the \fIauth1\fR string is that the username and password is separated by a slash, e\&.g\&. myusername/mysecret\&. .sp If two or more arguments is given Z39\&.50 v3 authentication is used, in which cased the first argument is used, second argument is group and third argument is password\&. If only two arguments are given the group is assumed to be empty\&. .sp As for other commands in yaz\-client, the arguments are separated by whitespace\&. A backslash character can be used to include a character verbatim\&. For example, auth myuser a\e b is a two argument auth command where user is myuser and password is a b\&. .sp The authentication string is first sent to the server when the open command is issued and the Z39\&.50 Initialize Request is sent, so this command must be used before open in order to be effective\&. .RE .PP sru \fImethod\fR \fIversion\fR .RS 4 Selects Web Service method and version\&. Must be one of post, get, soap (default) or solr\&. Version should be either 1\&.1, 1\&.2 or 2\&.0 for SRU\&. Other versions are allowed \- for testing purposes (version negotiation with SRU server)\&. The version is currently not used for Solr Web Services .RE .PP list_all .RS 4 This command displays status and values for many settings\&. .RE .PP lslb \fIn\fR .RS 4 Sets the limit for when no records should be returned together with the search result\&. See the \m[blue]\fBZ39\&.50 standard on set bounds\fR\m[]\&\s-2\u[4]\d\s+2 for more details\&. .RE .PP ssub \fIn\fR .RS 4 Sets the limit for when all records should be returned with the search result\&. See the \m[blue]\fBZ39\&.50 standard on set bounds\fR\m[]\&\s-2\u[4]\d\s+2 for more details\&. .RE .PP mspn \fIn\fR .RS 4 Sets the number of records that should be returned if the number of records in the result set is between the values of lslb and ssub\&. See the \m[blue]\fBZ39\&.50 standard on set bounds\fR\m[]\&\s-2\u[4]\d\s+2 for more details\&. .RE .PP status .RS 4 Displays the values of lslb, ssub and mspn\&. .RE .PP setname .RS 4 Switches named result sets on and off\&. Default is on\&. .RE .PP cancel .RS 4 Sends a Trigger Resource Control Request to the target\&. .RE .PP facets \fIspec\fR .RS 4 Specifies requested facets to be used in search\&. The notation is specified in ???\&. .RE .PP format \fIoid\fR .RS 4 Sets the preferred transfer syntax for retrieved records\&. yaz\-client supports all the record syntaxes that currently are registered\&. See \m[blue]\fBZ39\&.50 Record Syntax Identifiers\fR\m[]\&\s-2\u[5]\d\s+2 for more details\&. Commonly used records syntaxes include usmarc, sutrs and xml\&. .RE .PP elements \fIe\fR .RS 4 Sets the element set name for the records\&. Many targets support element sets B (for brief) and F (for full)\&. .RE .PP close .RS 4 Sends a Z39\&.50 Close APDU and closes connection with the peer .RE .PP querytype \fItype\fR .RS 4 Sets the query type as used by command find\&. The following is supported: prefix for Prefix Query Notation (Type\-1 Query); ccl for CCL search (Type\-2 Query), cql for CQL (Type\-104 search with CQL OID), ccl2rpn for CCL to RPN conversion (Type\-1 Query), cql2rpn for CQL to RPN conversion (Type\-1 Query)\&. .RE .PP attributeset \fIset\fR .RS 4 Sets attribute set OID for prefix queries (RPN, Type\-1)\&. .RE .PP refid \fIid\fR .RS 4 Sets reference ID for Z39\&.50 Request(s)\&. .RE .PP itemorder \fItype\fR \fIno\fR .RS 4 Sends an Item Order Request using the ILL External\&. \fItype\fR is either 1 or 2 which corresponds to ILL\-Profile 1 and 2 respectively\&. The \fIno\fR is the Result Set position of the record to be ordered\&. .RE .PP update \fIaction\fR \fIrecid\fR \fIdoc\fR .RS 4 Sends Item Update Request\&. The \fIaction\fR argument must be the action type: one of insert, replace, delete and update\&. The second argument, \fIrecid\fR, is the record identifier (any string)\&. Third argument which is optional is the record document for the request\&. If doc is preceded with "<", then the following characters are treated as a filename with the records to be updated\&. Otherwise doc is treated as a document itself\&. The doc may also be quoted in double quotes\&. If doc is omitted, the last received record (as part of present response or piggybacked search response) is used for the update\&. .RE .PP source \fIfilename\fR .RS 4 Executes list of commands from file \fIfilename\fR, just like \*(Aqsource\*(Aq on most UNIX shells\&. A single dot (\&.) can be used as an alternative\&. .RE .PP ! \fIargs\fR .RS 4 Executes command \fIargs\fR in subshell using the system call\&. .RE .PP push_command \fIcommand\fR .RS 4 The push_command takes another command as its argument\&. That command is then added to the history information (so you can retrieve it later)\&. The command itself is not executed\&. This command only works if you have GNU readline/history enabled\&. .RE .PP set_apdufile \fIfilename\fR .RS 4 Sets that APDU should be logged to file \fIfilename\fR\&. Another way to achieve APDU log is by using command\-line option \-a\&. .RE .PP set_auto_reconnect \fIflag\fR .RS 4 Specifies whether YAZ client automatically reconnects if the target closes connection (Z39\&.50 only)\&. .sp \fIflag\fR must be either on or off\&. .RE .PP set_auto_wait \fIflag\fR .RS 4 Specifies whether YAZ client should wait for response protocol packages after a request\&. By default YAZ client waits (on) for response packages immediately after a command (find, show) has been issued\&. If off is used, YAZ client does not attempt to receive packages automatically\&. These will have to be manually received when command wait_response is used\&. .sp \fIflag\fR must be either on or off\&. .RE .PP set_marcdump \fIfilename\fR .RS 4 Specifies that all retrieved records should be appended to file \fIfilename\fR\&. This command does the same thing as option \-m\&. .RE .PP schema \fIschemaid\fR .RS 4 Specifies schema for retrieval\&. Schema may be specified as an OID for Z39\&.50\&. For SRU, schema is a simple string URI\&. .RE .PP charset \fInegotiationcharset\fR [\fIdisplaycharset\fR] [[\fImarccharset\fR]] .RS 4 Specifies character set (encoding) for Z39\&.50 negotiation / SRU encoding and/or character set for output (terminal)\&. .sp \fInegotiationcharset\fR is the name of the character set to be negotiated by the server\&. The special name \- for \fInegotiationcharset\fR specifies \fIno\fR character set to be negotiated\&. .sp If \fIdisplaycharset\fR is given, it specifies name of the character set of the output (on the terminal on which YAZ client is running)\&. To disable conversion of characters to the output encoding, the special name \- (dash) can be used\&. If the special name auto is given, YAZ client will convert strings to the encoding of the terminal as returned by \fBnl_langinfo\fR call\&. .sp If \fImarccharset\fR is given, it specifies name of the character set of retrieved MARC records from server\&. See also marccharset command\&. .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBNote\fR .ps -1 .br Since character set negotiation takes effect in the Z39\&.50 Initialize Request you should issue this command before command open is used\&. .sp .5v .RE .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBNote\fR .ps -1 .br MARC records are not covered by Z39\&.50 character set negotiation, so that\*(Aqs why there is a separate character that must be known in order to do meaningful conversion(s)\&. .sp .5v .RE .RE .PP negcharset \fIcharset\fR .RS 4 Specifies character set for negotiation (Z39\&.50)\&. The argument is the same as second argument for command charset\&. .RE .PP displaycharset \fIcharset\fR .RS 4 Specifies character set for output (display)\&. The argument is the same as second argument for command charset\&. .RE .PP marccharset \fIcharset\fR .RS 4 Specifies character set for retrieved MARC records so that YAZ client can display them in a character suitable for your display\&. See charset command\&. If auto is given, YAZ will assume that MARC21/USMARC is using MARC8/UTF8 and ISO\-8859\-1 for all other MARC variants\&. The charset argument is the same as third argument for command charset\&. .RE .PP querycharset \fIcharset\fR .RS 4 Specifies character set for query terms for Z39\&.50 RPN queries and Z39\&.50 Scan Requests (termListAndStartPoint)\&. This is a pure client\-side conversion which converts from displayCharset to queryCharset\&. .RE .PP set_cclfile \fIfilename\fR .RS 4 Specifies that CCL fields should be read from file file \fIfilename\fR\&. This command does the same thing as option \-c\&. .RE .PP set_cqlfile \fIfilename\fR .RS 4 Specifies that CQL fields should be read from file file \fIfilename\fR\&. This command does the same thing as option \-q\&. .RE .PP register_oid \fIname\fR \fIclass\fR \fIOID\fR .RS 4 This command allows you to register your own object identifier \- so that instead of entering a long dot\-notation you can use a short name instead\&. The \fIname\fR is your name for the OID, \fIclass\fR is the class, and \fIOID\fR is the raw OID in dot notation\&. Class is one of: appctx, absyn, attet, transyn, diagset, recsyn, resform, accform, extserv, userinfo, elemspec, varset, schema, tagset, general\&. If you\*(Aqre in doubt use the general class\&. .RE .PP register_tab \fIcommand\fR \fIstring\fR .RS 4 This command registers a TAB completion string for the command given\&. .RE .PP sleep \fIseconds\fR .RS 4 This command makes YAZ client sleep (be idle) for the number of seconds given\&. .RE .PP wait_response [ \fInumber\fR] .RS 4 This command makes YAZ client wait for a number of response packages from target\&. If \fInumber\fR is omitted, 1 is assumed\&. .sp This command is rarely used and is only useful if command set_auto_wait is set to off\&. .RE .PP xmles \fIOID\fR \fIdoc\fR .RS 4 Sends XML Extended Services request using the OID and doc given\&. .RE .PP zversion \fIver\fR .RS 4 This command sets Z39\&.50 version for negotiation\&. Should be used before open\&. By default 3 (version 3) is used\&. .RE .PP options \fIop1 op2\&.\&.\fR .RS 4 This command sets Z39\&.50 options for negotiation\&. Should be used before open\&. .sp The following options are supported: search, present, delSet, resourceReport, triggerResourceCtrl, resourceCtrl, accessCtrl, scan, sort, extendedServices, level_1Segmentation, level_2Segmentation, concurrentOperations, namedResultSets, encapsulation, resultCount, negotiationModel, duplicationDetection, queryType104, pQESCorrection, stringSchema\&. .RE .SH "EXAMPLE" .PP The simplest example of a Prefix Query would be something like .sp .if n \{\ .RS 4 .\} .nf f knuth .fi .if n \{\ .RE .\} .sp or .sp .if n \{\ .RS 4 .\} .nf f "donald knuth" .fi .if n \{\ .RE .\} .sp In those queries, no attributes were specified\&. This leaves it up to the server what fields to search but most servers will search in all fields\&. Some servers do not support this feature though, and require that some attributes are defined\&. To add one attribute you could do: .sp .if n \{\ .RS 4 .\} .nf f @attr 1=4 computer .fi .if n \{\ .RE .\} .sp where we search in the title field, since the use(1) is title(4)\&. If we want to search in the author field \fIand\fR in the title field, and in the title field using right truncation it could look something like this: .sp .if n \{\ .RS 4 .\} .nf f @and @attr 1=1003 knuth @attr 1=4 @attr 5=1 computer .fi .if n \{\ .RE .\} .sp Finally using a mix of Bib\-1 and GILS attributes could look something like this: .sp .if n \{\ .RS 4 .\} .nf f @attrset Bib\-1 @and @attr GILS 1=2008 Washington @attr 1=21 weather .fi .if n \{\ .RE .\} .sp .SH "FILES" .PP yaz\-/client/client\&.c .PP $HOME/\&.yazclientrc .PP $HOME/\&.yazclient\&.history .SH "SEE ALSO" .PP \fByaz\fR(7) \fBbib1-attr\fR(7) .SH "AUTHORS" .PP \fBIndex Data\fR .SH "NOTES" .IP " 1." 4 Z39.50 .RS 4 \%https://www.loc.gov/z3950/agency/ .RE .IP " 2." 4 SRU .RS 4 \%https://www.loc.gov/standards/sru/ .RE .IP " 3." 4 Solr .RS 4 \%https://solr.apache.org .RE .IP " 4." 4 Z39.50 standard on set bounds .RS 4 \%http://www.loc.gov/z3950/agency/markup/04.html#3.2.2.1.6 .RE .IP " 5." 4 Z39.50 Record Syntax Identifiers .RS 4 \%http://www.loc.gov/z3950/agency/defns/oids.html#5 .RE yaz-5.37.0/doc/zoom.resultsets.html0000644000175000017500000003245515130444232015701 0ustar00adamadam3. Result sets
3. Result sets
Prev Chapter 3. ZOOM Next

3. Result sets

The result set object is a container for records returned from a target. 

     ZOOM_resultset ZOOM_connection_search(ZOOM_connection, ZOOM_query q);

     ZOOM_resultset ZOOM_connection_search_pqf(ZOOM_connection c,
                                               const char *q);
     void ZOOM_resultset_destroy(ZOOM_resultset r);

Function ZOOM_connection_search creates a result set, given a connection and query. Destroy a result set by calling ZOOM_resultset_destroy. Simple clients using PQF only, may use the function ZOOM_connection_search_pqf in which case creating query objects is not necessary. 

     void ZOOM_resultset_option_set(ZOOM_resultset r,
                                    const char *key, const char *val);

     const char *ZOOM_resultset_option_get(ZOOM_resultset r, const char *key);

     size_t ZOOM_resultset_size(ZOOM_resultset r);

Functions ZOOM_resultset_options_set and ZOOM_resultset_get sets and gets an option for a result set similar to ZOOM_connection_option_get and ZOOM_connection_option_set.

The number of hits, also called result-count, is returned by function ZOOM_resultset_size.

Table 3.3. ZOOM Result set Options

OptionDescriptionDefault
startOffset of first record to be retrieved from target. First record has offset 0 unlike the protocol specifications where first record has position 1. This option affects ZOOM_resultset_search and ZOOM_resultset_search_pqf and must be set before any of these functions are invoked. If a range of records must be fetched manually after search, function ZOOM_resultset_records should be used. 0
countNumber of records to be retrieved. This option affects ZOOM_resultset_search and ZOOM_resultset_search_pqf and must be set before any of these functions are invoked. 0
presentChunkThe number of records to be requested from the server in each chunk (present request). The value 0 means to request all the records in a single chunk. (The old step option is also supported for the benefit of old applications.) 0
elementSetNameElement-Set name of records. Most targets should honor element set name B and F for brief and full respectively. none
preferredRecordSyntaxPreferred Syntax, such as USMARC, SUTRS, etc. none
schemaSchema for retrieval, such as Gils-schema, Geo-schema, etc. none
setnameName of Result Set (Result Set ID). If this option isn't set, the ZOOM module will automatically allocate a result set name. default
rpnCharsetCharacter set for RPN terms. If this is set, ZOOM C will assume that the ZOOM application is running UTF-8. Terms in RPN queries are then converted to the rpnCharset. If this is unset, ZOOM C will not assume any encoding of RPN terms and no conversion is performed. none

For servers that support Search Info report, the following options may be read using ZOOM_resultset_get. This detailed information is read after a successful search has completed.

This information is a list of of items, where each item is information about a term or subquery. All items in the list are prefixed by SearchResult.no where no presents the item number (0=first, 1=second). Read searchresult.size to determine the number of items.

Table 3.4. Search Info Report Options

OptionDescription
searchresult.size number of search result entries. This option is non-existent if no entries are returned by the server.
searchresult.no.idsub query ID
searchresult.no.countresult count for item (number of hits)
searchresult.no.subquery.termsubquery term
searchresult.no.interpretation.term interpretation term
searchresult.no.recommendation.term recommendation term

3.1. Z39.50 Result-set Sort

     void ZOOM_resultset_sort(ZOOM_resultset r,
                              const char *sort_type, const char *sort_spec);

     int ZOOM_resultset_sort1(ZOOM_resultset r,
                              const char *sort_type, const char *sort_spec);

ZOOM_resultset_sort and ZOOM_resultset_sort1 both sort an existing result-set. The sort_type parameter is not used. Set it to "yaz". The sort_spec is same notation as ZOOM_query_sortby and identical to that offered by yaz-client's sort command.

These functions only work for Z39.50. Use the more generic utility ZOOM_query_sortby2 for other protocols (and even Z39.50).

3.2. Z39.50 Protocol behavior

The creation of a result set involves at least a SearchRequest - SearchResponse protocol handshake. Following that, if a sort criteria was specified as part of the query, a SortRequest - SortResponse handshake takes place. Note that it is necessary to perform sorting before any retrieval takes place, so no records will be returned from the target as part of the SearchResponse because these would be unsorted. Hence, piggyback is disabled when sort criteria are set. Following Search - and a possible sort - Retrieval takes place - as one or more Present Requests/Response pairs being transferred.

The API allows for two different modes for retrieval. A high level mode which is somewhat more powerful and a low level one. The low level is enabled when searching on a Connection object for which the settings smallSetUpperBound, mediumSetPresentNumber and largeSetLowerBound are set. The low level mode thus allows you to precisely set how records are returned as part of a search response as offered by the Z39.50 protocol. Since the client may be retrieving records as part of the search response, this mode doesn't work well if sorting is used.

The high-level mode allows you to fetch a range of records from the result set with a given start offset. When you use this mode the client will automatically use piggyback if that is possible with the target, and perform one or more present requests as needed. Even if the target returns fewer records as part of a present response because of a record size limit, etc. the client will repeat sending present requests. As an example, if option start is 0 (default) and count is 4, and piggyback is 1 (default) and no sorting criteria is specified, then the client will attempt to retrieve the 4 records as part the search response (using piggyback). On the other hand, if either start is positive or if a sorting criteria is set, or if piggyback is 0, then the client will not perform piggyback but send Present Requests instead.

If either of the options mediumSetElementSetName and smallSetElementSetName are unset, the value of option elementSetName is used for piggyback searches. This means that for the high-level mode you only have to specify one elementSetName option rather than three.

3.3. SRU Protocol behavior

Current version of YAZ does not take advantage of a result set id returned by the SRU server. Future versions might do, however. Since the ZOOM driver does not save result set IDs, any present (retrieval) is transformed to a SRU SearchRetrieveRequest with same query but, possibly, different offsets.

Option schema specifies SRU schema for retrieval. However, options elementSetName and preferredRecordSyntax are ignored.

Options start and count are supported by SRU. The remaining options piggyback, smallSetUpperBound, largeSetLowerBound, mediumSetPresentNumber, mediumSetElementSetName, smallSetElementSetName are unsupported.

SRU supports CQL queries, not PQF. If PQF is used, however, the PQF query is transferred anyway using non-standard element pQuery in SRU SearchRetrieveRequest.

Solr queries need to be done in Solr query format.

Unfortunately, SRU and Solr do not define a database setting. Hence, databaseName is unsupported and ignored. However, the path part in host parameter for functions ZOOM_connecton_new and ZOOM_connection_connect acts as a database (at least for the YAZ SRU server).

Prev Up Next
2. Queries Home 4. Records
yaz-5.37.0/doc/bib1-attr-man.xml0000644000175000017500000001342715123757344014706 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data Bib-1 Attribute Set 7 Conventions and miscellaneous bib1-attr Bib-1 Attribute Set DESCRIPTION This reference entry lists the Bib-1 attribute set types and values. TYPES The Bib-1 attribute set defines six attribute types: Use (1), Relation (2), Position (3), Structure (4), Truncation (5) and Completeness (6). USE (1) 1 Personal-name 2 Corporate-name 3 Conference-name 4 Title 5 Title-series 6 Title-uniform 7 ISBN 8 ISSN 9 LC-card-number 10 BNB-card-number 11 BGF-number 12 Local-number 13 Dewey-classification 14 UDC-classification 15 Bliss-classification 16 LC-call-number 17 NLM-call-number 18 NAL-call-number 19 MOS-call-number 20 Local-classification 21 Subject-heading 22 Subject-Rameau 23 BDI-index-subject 24 INSPEC-subject 25 MESH-subject 26 PA-subject 27 LC-subject-heading 28 RVM-subject-heading 29 Local-subject-index 30 Date 31 Date-of-publication 32 Date-of-acquisition 33 Title-key 34 Title-collective 35 Title-parallel 36 Title-cover 37 Title-added-title-page 38 Title-caption 39 Title-running 40 Title-spine 41 Title-other-variant 42 Title-former 43 Title-abbreviated 44 Title-expanded 45 Subject-precis 46 Subject-rswk 47 Subject-subdivision 48 Number-natl-biblio 49 Number-legal-deposit 50 Number-govt-pub 51 Number-music-publisher 52 Number-db 53 Number-local-call 54 Code-language 55 Code-geographic 56 Code-institution 57 Name-and-title 58 Name-geographic 59 Place-publication 60 CODEN 61 Microform-generation 62 Abstract 63 Note 1000 Author-title 1001 Record-type 1002 Name 1003 Author 1004 Author-name-personal 1005 Author-name-corporate 1006 Author-name-conference 1007 Identifier-standard 1008 Subject-LC-childrens 1009 Subject-name-personal 1010 Body-of-text 1011 Date/time-added-to-db 1012 Date/time-last-modified 1013 Authority/format-id 1014 Concept-text 1015 Concept-reference 1016 Any 1017 Server-choice 1018 Publisher 1019 Record-source 1020 Editor 1021 Bib-level 1022 Geographic-class 1023 Indexed-by 1024 Map-scale 1025 Music-key 1026 Related-periodical 1027 Report-number 1028 Stock-number 1030 Thematic-number 1031 Material-type 1032 Doc-id 1033 Host-item 1034 Content-type 1035 Anywhere 1036 Author-Title-Subject RELATION (2) 1 Less than 2 Less than or equal 3 Equal 4 Greater or equal 5 Greater than 6 Not equal 100 Phonetic 101 Stem 102 Relevance 103 AlwaysMatches POSITION (3) 1 First in field 2 First in subfield 3 Any position in field STRUCTURE (4) 1 Phrase 2 Word 3 Key 4 Year 5 Date (normalized) 6 Word list 100 Date (un-normalized) 101 Name (normalized) 102 Name (un-normalized) 103 Structure 104 Urx 105 Free-form-text 106 Document-text 107 Local-number 108 String 109 Numeric-string TRUNCATION (5) 1 Right truncation 2 Left truncation 3 Left and right truncation 100 Do not truncate 101 Process # in search term . regular #=.* 102 RegExpr-1 103 RegExpr-2 104 Process # ?n . regular: #=., ?n=.{0,n} or ?=.* Z39.58 The 105-106 truncation attributes below are only supported by Index Data's Zebra server. 105 Process * ! regular: *=.*, !=. and right truncate 106 Process * ! regular: *=.*, !=. COMPLETENESS (6) 1 Incomplete subfield 2 Complete subfield 3 Complete field SORTING (7) 1 ascending 2 descending Type 7 is an Index Data extension to RPN queries that allows embedding a sort critieria into a query. SEE ALSO Bib-1 Attribute Set Attribute Set Bib-1 Semantics. yaz-5.37.0/doc/yaz-config.html0000644000175000017500000000763715130444232014553 0ustar00adamadamyaz-config
yaz-config
Prev Reference Next

Name

yaz-config — Script to get information about YAZ.

Synopsis

yaz-config [--prefix[=DIR]] [--version] [--libs] [--lalibs] [--cflags] [--include] [--comp] [-V] [libraries...]

DESCRIPTION

yaz-config is a script that returns information that your own software should use to build software that uses YAZ.

The following libraries are supported:

threads

Use the threaded version of YAZ.

OPTIONS

--prefix[=DIR]

Returns prefix of YAZ or assume a different one if DIR is specified.

--version

Returns version of YAZ.

--libs

Library specification be used when using YAZ.

--lalibs

Return library specification.

--cflags

Return C Compiler flags.

--include

Return C compiler includes for YAZ header files (-Ipath).

--comp

Returns full path to YAZ' ASN.1 compiler: yaz-asncomp.

-V

Returns YAZ SHA1 ID (from Git) and version.

FILES

/usr/bin/yaz-config

/usr/lib/libyaz*.a

/usr/include/yaz/*.h

SEE ALSO

yaz(7)

Section "How to make apps using YAZ on UNIX" in the YAZ manual.

Prev Up Next
yaz-ztest Home yaz
yaz-5.37.0/doc/tools.oid.html0000644000175000017500000002110215130444232014376 0ustar00adamadam2. Object Identifiers
2. Object Identifiers
Prev Chapter 7. Supporting Tools Next

2. Object Identifiers

The basic YAZ representation of an OID is an array of integers, terminated with the value -1. This integer is of type Odr_oid.

Fundamental OID operations and the type Odr_oid are defined in yaz/oid_util.h.

An OID can either be declared as a automatic variable or it can be allocated using the memory utilities or ODR/NMEM. It's guaranteed that an OID can fit in OID_SIZE integers.

Example 7.13. Create OID on stack

We can create an OID for the Bib-1 attribute set with: 

      Odr_oid bib1[OID_SIZE];
      bib1[0] = 1;
      bib1[1] = 2;
      bib1[2] = 840;
      bib1[3] = 10003;
      bib1[4] = 3;
      bib1[5] = 1;
      bib1[6] = -1;


And OID may also be filled from a string-based representation using dots (.). This is achieved by the function 

     int oid_dotstring_to_oid(const char *name, Odr_oid *oid);

This functions returns 0 if name could be converted; -1 otherwise.

Example 7.14. Using oid_oiddotstring_to_oid

We can fill the Bib-1 attribute set OID more easily with: 

      Odr_oid bib1[OID_SIZE];
      oid_oiddotstring_to_oid("1.2.840.10003.3.1", bib1);


We can also allocate an OID dynamically on an ODR stream with: 

    Odr_oid *odr_getoidbystr(ODR o, const char *str);

This creates an OID from a string-based representation using dots. This function take an ODR stream as parameter. This stream is used to allocate memory for the data elements, which is released on a subsequent call to odr_reset() on that stream.

Example 7.15. Using odr_getoidbystr

We can create an OID for the Bib-1 attribute set with: 

      Odr_oid *bib1 = odr_getoidbystr(odr, "1.2.840.10003.3.1");


The function 

     char *oid_oid_to_dotstring(const Odr_oid *oid, char *oidbuf)

does the reverse of oid_oiddotstring_to_oid. It converts an OID to the string-based representation using dots. The supplied char buffer oidbuf holds the resulting string and must be at least OID_STR_MAX in size.

OIDs can be copied with oid_oidcpy which takes two OID lists as arguments. Alternatively, an OID copy can be allocated on an ODR stream with: 

     Odr_oid *odr_oiddup(ODR odr, const Odr_oid *o);

OIDs can be compared with oid_oidcmp which returns zero if the two OIDs provided are identical; non-zero otherwise.

2.1. OID database

From YAZ version 3 and later, the oident system has been replaced by an OID database. OID database is a misnomer .. the old odient system was also a database.

The OID database is really just a map between named Object Identifiers (string) and their OID raw equivalents. Most operations either convert from string to OID or other way around.

Unfortunately, whenever we supply a string we must also specify the OID class. The class is necessary because some strings correspond to multiple OIDs. An example of such a string is Bib-1 which may either be an attribute-set or a diagnostic-set.

Applications using the YAZ database should include yaz/oid_db.h.

A YAZ database handle is of type yaz_oid_db_t. Actually that's a pointer. You need not deal with that. YAZ has a built-in database which can be considered "constant" for most purposes. We can get hold of that by using function yaz_oid_std.

All functions with prefix yaz_string_to_oid converts from class + string to OID. We have variants of this operation due to different memory allocation strategies.

All functions with prefix yaz_oid_to_string converts from OID to string + class.

Example 7.16. Create OID with YAZ DB

We can create an OID for the Bib-1 attribute set on the ODR stream odr with: 

        Odr_oid *bib1 =
	yaz_string_to_oid_odr(yaz_oid_std(), CLASS_ATTSET, "Bib-1", odr);

This is more complex than using odr_getoidbystr. You would only use yaz_string_to_oid_odr when the string (here Bib-1) is supplied by a user or configuration.


2.2. Standard OIDs

All the object identifiers in the standard OID database as returned by yaz_oid_std can be referenced directly in a program as a constant OID. Each constant OID is prefixed with yaz_oid_ - followed by OID class (lowercase) - then by OID name (normalized and lowercase).

See Appendix A, List of Object Identifiers for list of all object identifiers built into YAZ. These are declared in yaz/oid_std.h but are included by yaz/oid_db.h as well.

Example 7.17. Use a built-in OID

We can allocate our own OID filled with the constant OID for Bib-1 with: 

       Odr_oid *bib1 = odr_oiddup(o, yaz_oid_attset_bib1);


Prev Up Next
Chapter 7. Supporting Tools Home 3. Nibble Memory
yaz-5.37.0/doc/zoom.options.html0000644000175000017500000000511215130444232015145 0ustar00adamadam8. Options
8. Options
Prev Chapter 3. ZOOM Next

8. Options

Most ZOOM objects provide a way to specify options to change behavior. From an implementation point of view, a set of options is just like an associative array / hash. 

     ZOOM_options ZOOM_options_create(void);

     ZOOM_options ZOOM_options_create_with_parent(ZOOM_options parent);

     void ZOOM_options_destroy(ZOOM_options opt);
   
     const char *ZOOM_options_get(ZOOM_options opt, const char *name);

     void ZOOM_options_set(ZOOM_options opt, const char *name,
                           const char *v);
   
     typedef const char *(*ZOOM_options_callback)
                            (void *handle, const char *name);

     ZOOM_options_callback
             ZOOM_options_set_callback(ZOOM_options opt,
                                       ZOOM_options_callback c,
                                       void *handle);
Prev Up Next
7. Extended Services Home 9. Query conversions
yaz-5.37.0/doc/server.backendfunctions.html0000644000175000017500000005170415130444232017324 0ustar00adamadam5. The Backend Functions
5. The Backend Functions
Prev Chapter 4. Generic server Next

5. The Backend Functions

For each service of the protocol, the backend interface declares one or two functions. You are required to provide implementations of the functions representing the services that you wish to implement.

5.1. Init

bend_initresult (*bend_init)(bend_initrequest *r);

This handler is called once for each new connection request, after a new process/thread has been created, and an Initialize Request has been received from the client. The pointer to the bend_init handler is passed in the call to statserv_start.

This handler is also called when operating in SRU mode - when a connection has been made (even though SRU does not offer this service).

Unlike previous versions of YAZ, the bend_init also serves as a handler that defines the Z39.50 services that the backend intends to support. Pointers to all service handlers, including search - and fetch must be specified here in this handler.

The request - and result structures are defined as 

typedef struct bend_initrequest
{
    /** \brief user/name/password to be read */
    Z_IdAuthentication *auth;
    /** \brief encoding stream (for results) */
    ODR stream;
    /** \brief printing stream */
    ODR print;
    /** \brief decoding stream (use stream for results) */
    ODR decode;
    /** \brief reference ID */
    Z_ReferenceId *referenceId;
    /** \brief peer address of client */
    char *peer_name;

    /** \brief character set and language negotiation

    see include/yaz/z-charneg.h
    */
    Z_CharSetandLanguageNegotiation *charneg_request;

    /** \brief character negotiation response */
    Z_External *charneg_response;

    /** \brief character set (encoding) for query terms

    This is NULL by default. It should be set to the native character
    set that the backend assumes for query terms */
    char *query_charset;

    /** \brief whether query_charset also applies to records

    Is 0 (No) by default. Set to 1 (yes) if records is in the same
    character set as queries. If in doubt, use 0 (No).
    */
    int records_in_same_charset;

    char *implementation_id;
    char *implementation_name;
    char *implementation_version;

    /** \brief Z39.50 sort handler */
    int (*bend_sort)(void *handle, bend_sort_rr *rr);
    /** \brief SRU/Z39.50 search handler */
    int (*bend_search)(void *handle, bend_search_rr *rr);
    /** \brief SRU/Z39.50 fetch handler */
    int (*bend_fetch)(void *handle, bend_fetch_rr *rr);
    /** \brief SRU/Z39.50 present handler */
    int (*bend_present)(void *handle, bend_present_rr *rr);
    /** \brief Z39.50 extended services handler */
    int (*bend_esrequest) (void *handle, bend_esrequest_rr *rr);
    /** \brief Z39.50 delete result set handler */
    int (*bend_delete)(void *handle, bend_delete_rr *rr);
    /** \brief Z39.50 scan handler */
    int (*bend_scan)(void *handle, bend_scan_rr *rr);
    /** \brief Z39.50 segment facility handler */
    int (*bend_segment)(void *handle, bend_segment_rr *rr);
    /** \brief SRU explain handler */
    int (*bend_explain)(void *handle, bend_explain_rr *rr);
    /** \brief SRU scan handler */
    int (*bend_srw_scan)(void *handle, bend_scan_rr *rr);
    /** \brief SRU record update handler */
    int (*bend_srw_update)(void *handle, bend_update_rr *rr);

    /** \brief whether named result sets are supported (0=disable, 1=enable) */
    int named_result_sets;
} bend_initrequest;

typedef struct bend_initresult
{
    int errcode;               /* 0==OK */
    char *errstring;           /* system error string or NULL */
    void *handle;              /* private handle to the backend module */
} bend_initresult;

In general, the server frontend expects that the bend_*result pointer that you return is valid at least until the next call to a bend_* function. This applies to all of the functions described herein. The parameter structure passed to you in the call belongs to the server frontend, and you should not make assumptions about its contents after the current function call has completed. In other words, if you want to retain any of the contents of a request structure, you should copy them.

The errcode should be zero if the initialization of the backend went well. Any other value will be interpreted as an error. The errstring isn't used in the current version, but one option would be to stick it in the initResponse as a VisibleString. The handle is the most important parameter. It should be set to some value that uniquely identifies the current session to the backend implementation. It is used by the frontend server in any future calls to a backend function. The typical use is to set it to point to a dynamically allocated state structure that is private to your backend module.

The auth member holds the authentication information part of the Z39.50 Initialize Request. Interpret this if your server requires authentication.

The members peer_name, implementation_id, implementation_name and implementation_version holds DNS of client, ID of implementor, name of client (Z39.50) implementation - and version.

The bend_ - members are set to NULL when bend_init is called. Modify the pointers by setting them to point to backend functions.

5.2. Search and Retrieve

We now describe the handlers that are required to support search - and retrieve. You must support two functions - one for search - and one for fetch (retrieval of one record). If desirable you can provide a third handler which is called when a present request is received which allows you to optimize retrieval of multiple-records. 

int (*bend_search) (void *handle, bend_search_rr *rr);

typedef struct {
    char *setname;             /* name to give to this set */
    int replace_set;           /* replace set, if it already exists */
    int num_bases;             /* number of databases in list */
    char **basenames;          /* databases to search */
    Z_ReferenceId *referenceId;/* reference ID */
    Z_Query *query;            /* query structure */
    ODR stream;                /* encode stream */
    ODR decode;                /* decode stream */
    ODR print;                 /* print stream */

    bend_request request;
    bend_association association;
    int *fd;
    int hits;                  /* number of hits */
    int errcode;               /* 0==OK */
    char *errstring;           /* system error string or NULL */
    Z_OtherInformation *search_info; /* additional search info */
    char *srw_sortKeys;        /* holds SRU/SRW sortKeys info */
    char *srw_setname;         /* holds SRU/SRW generated resultsetID */
    int *srw_setnameIdleTime;  /* holds SRU/SRW life-time */
    int estimated_hit_count;   /* if hit count is estimated */
    int partial_resultset;     /* if result set is partial */
} bend_search_rr;

The bend_search handler is a fairly close approximation of a protocol Z39.50 Search Request - and Response PDUs. The setname is the resultSetName from the protocol. You are required to establish a mapping between the set name and whatever your backend database likes to use. Similarly, the replace_set is a boolean value corresponding to the resultSetIndicator field in the protocol. num_bases/basenames is a length of/array of character pointers to the database names provided by the client. The query is the full query structure as defined in the protocol ASN.1 specification. It can be either of the possible query types, and it's up to you to determine if you can handle the provided query type. Rather than reproduce the C interface here, we'll refer you to the structure definitions in the file include/yaz/z-core.h. If you want to look at the attributeSetId OID of the RPN query, you can either match it against your own internal tables, or you can use the OID tools.

The structure contains a number of hits, and an errcode/errstring pair. If an error occurs during the search, or if you're unhappy with the request, you should set the errcode to a value from the BIB-1 diagnostic set. The value will then be returned to the user in a nonsurrogate diagnostic record in the response. The errstring, if provided, will go in the addinfo field. Look at the protocol definition for the defined error codes, and the suggested uses of the addinfo field.

The bend_search handler is also called when the frontend server receives a SRU SearchRetrieveRequest. For SRU, a CQL query is usually provided by the client. The CQL query is available as part of Z_Query structure (note that CQL is now part of Z39.50 via an external). To support CQL in existing implementations that only do Type-1, we refer to the CQL-to-PQF tool described here.

To maintain backwards compatibility, the frontend server of yaz always assume that error codes are BIB-1 diagnostics. For SRU operation, a Bib-1 diagnostic code is mapped to SRU diagnostic. 

int (*bend_fetch) (void *handle, bend_fetch_rr *rr);

typedef struct bend_fetch_rr {
    char *setname;             /* set name */
    int number;                /* record number */
    Z_ReferenceId *referenceId;/* reference ID */
    Odr_oid *request_format;   /* format, transfer syntax (OID) */
    Z_RecordComposition *comp; /* Formatting instructions */
    ODR stream;                /* encoding stream - memory source if req */
    ODR print;                 /* printing stream */

    char *basename;            /* name of database that provided record */
    int len;                   /* length of record or -1 if structured */
    char *record;              /* record */
    int last_in_set;           /* is it?  */
    Odr_oid *output_format;    /* response format/syntax (OID) */
    int errcode;               /* 0==success */
    char *errstring;           /* system error string or NULL */
    int surrogate_flag;        /* surrogate diagnostic */
    char *schema;              /* string record schema input/output */
} bend_fetch_rr;

The frontend server calls the bend_fetch handler when it needs database records to fulfill a Z39.50 Search Request, a Z39.50 Present Request or a SRU SearchRetrieveRequest. The setname is simply the name of the result set that holds the reference to the desired record. The number is the offset into the set (with 1 being the first record in the set). The format field is the record format requested by the client (See Section 2, “Object Identifiers”). A value of NULL for format indicates that the client did not request a specific format. The stream argument is an ODR stream which should be used for allocating space for structured data records. The stream will be reset when all records have been assembled, and the response package has been transmitted. For unstructured data, the backend is responsible for maintaining a static or dynamic buffer for the record between calls.

If a SRU SearchRetrieveRequest is received by the frontend server, the referenceId is NULL and the format (transfer syntax) is the OID for XML. The schema for SRU is stored in both the Z_RecordComposition structure and schema (simple string).

In the structure, the basename is the name of the database that holds the record. len is the length of the record returned, in bytes, and record is a pointer to the record. last_in_set should be nonzero only if the record returned is the last one in the given result set. errcode and errstring, if given, will be interpreted as a global error pertaining to the set, and will be returned in a non-surrogate-diagnostic. If you wish to return the error as a surrogate-diagnostic (local error) you can do this by setting surrogate_flag to 1 also.

If the len field has the value -1, then record is assumed to point to a constructed data type. The format field will be used to determine which encoder should be used to serialize the data.

Note

If your backend generates structured records, it should use odr_malloc() on the provided stream for allocating data: This allows the frontend server to keep track of the record sizes.

The format field is mapped to an object identifier in the direct reference of the resulting EXTERNAL representation of the record.

Note

The current version of YAZ only supports the direct reference mode. 

int (*bend_present) (void *handle, bend_present_rr *rr);

typedef struct {
    char *setname;             /* set name */
    int start;
    int number;                /* record number */
    Odr_oid *format;           /* format, transfer syntax (OID) */
    Z_ReferenceId *referenceId;/* reference ID */
    Z_RecordComposition *comp; /* Formatting instructions */
    ODR stream;                /* encoding stream - memory source if required */
    ODR print;                 /* printing stream */
    bend_request request;
    bend_association association;

    int hits;                  /* number of hits */
    int errcode;               /* 0==OK */
    char *errstring;           /* system error string or NULL */
} bend_present_rr;

The bend_present handler is called when the server receives a Z39.50 Present Request. The setname, start and number is the name of the result set - start position - and number of records to be retrieved respectively. format and comp is the preferred transfer syntax and element specifications of the present request.

Note that this is handler serves as a supplement for bend_fetch and need not to be defined in order to support search - and retrieve.

5.3. Delete

For back-ends that supports delete of a result set, only one handler must be defined. 

int (*bend_delete)(void *handle, bend_delete_rr *rr);

typedef struct bend_delete_rr {
    int function;
    int num_setnames;
    char **setnames;
    Z_ReferenceId *referenceId;
    int delete_status;      /* status for the whole operation */
    int *statuses;          /* status each set - indexed as setnames */
    ODR stream;
    ODR print;
} bend_delete_rr;

Note

The delete set function definition is rather primitive, mostly because we have had no practical need for it as of yet. If someone wants to provide a full delete service, we'd be happy to add the extra parameters that are required. Are there clients out there that will actually delete sets they no longer need?

5.4. Scan

For servers that wish to offer the scan service one handler must be defined. 

int (*bend_scan)(void *handle, bend_scan_rr *rr);

typedef enum {
    BEND_SCAN_SUCCESS,  /* ok */
    BEND_SCAN_PARTIAL   /* not all entries could be found */
} bend_scan_status;

typedef struct bend_scan_rr {
    int num_bases;      /* number of elements in databaselist */
    char **basenames;   /* databases to search */
    Odr_oid *attributeset;
    Z_ReferenceId *referenceId; /* reference ID */
    Z_AttributesPlusTerm *term;
    ODR stream;         /* encoding stream - memory source if required */
    ODR print;          /* printing stream */

    int *step_size;     /* step size */
    int term_position;  /* desired index of term in result list/returned */
    int num_entries;    /* number of entries requested/returned */

    /* scan term entries. The called handler does not have
       to allocate this. Size of entries is num_entries (see above) */
    struct scan_entry *entries;
    bend_scan_status status;
    int errcode;
    char *errstring;
    char *scanClause;   /* CQL scan clause */
    char *setname;      /* Scan in result set (NULL if omitted) */
} bend_scan_rr;

This backend server handles both Z39.50 scan and SRU scan. In order for a handler to distinguish between SRU (CQL) scan Z39.50 Scan, it must check for a non-NULL value of scanClause.

Note

If designed today, it would be a choice using a union or similar, but that would break binary compatibility with existing servers.

Prev Up Next
4. Your main() Routine Home 6. Application Invocation
yaz-5.37.0/doc/Makefile.in0000644000175000017500000007504615130444201013657 0ustar00adamadam# Makefile.in generated by automake 1.18.1 from Makefile.am. # @configure_input@ # Copyright (C) 1994-2025 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY, to the extent permitted by law; without # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. @SET_MAKE@ VPATH = @srcdir@ am__is_gnu_make = { \ if test -z '$(MAKELEVEL)'; then \ false; \ elif test -n '$(MAKE_HOST)'; then \ true; \ elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \ true; \ else \ false; \ fi; \ } am__make_running_with_option = \ case $${target_option-} in \ ?) ;; \ *) echo "am__make_running_with_option: internal error: invalid" \ "target option '$${target_option-}' specified" >&2; \ exit 1;; \ esac; \ has_opt=no; \ sane_makeflags=$$MAKEFLAGS; \ if $(am__is_gnu_make); then \ sane_makeflags=$$MFLAGS; \ else \ case $$MAKEFLAGS in \ *\\[\ \ ]*) \ bs=\\; \ sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \ | sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \ esac; \ fi; \ skip_next=no; \ strip_trailopt () \ { \ flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \ }; \ for flg in $$sane_makeflags; do \ test $$skip_next = yes && { skip_next=no; continue; }; \ case $$flg in \ *=*|--*) continue;; \ -*I) strip_trailopt 'I'; skip_next=yes;; \ -*I?*) strip_trailopt 'I';; \ -*O) strip_trailopt 'O'; skip_next=yes;; \ -*O?*) strip_trailopt 'O';; \ -*l) strip_trailopt 'l'; skip_next=yes;; \ -*l?*) strip_trailopt 'l';; \ -[dEDm]) skip_next=yes;; \ -[JT]) skip_next=yes;; \ esac; \ case $$flg in \ *$$target_option*) has_opt=yes; break;; \ esac; \ done; \ test $$has_opt = yes am__make_dryrun = (target_option=n; $(am__make_running_with_option)) am__make_keepgoing = (target_option=k; $(am__make_running_with_option)) am__rm_f = rm -f $(am__rm_f_notfound) am__rm_rf = rm -rf $(am__rm_f_notfound) pkgdatadir = $(datadir)/@PACKAGE@ pkgincludedir = $(includedir)/@PACKAGE@ pkglibdir = $(libdir)/@PACKAGE@ pkglibexecdir = $(libexecdir)/@PACKAGE@ am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd install_sh_DATA = $(install_sh) -c -m 644 install_sh_PROGRAM = $(install_sh) -c install_sh_SCRIPT = $(install_sh) -c INSTALL_HEADER = $(INSTALL_DATA) transform = $(program_transform_name) NORMAL_INSTALL = : PRE_INSTALL = : POST_INSTALL = : NORMAL_UNINSTALL = : PRE_UNINSTALL = : POST_UNINSTALL = : build_triplet = @build@ host_triplet = @host@ subdir = doc ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/m4/ac_check_icu.m4 \ $(top_srcdir)/m4/acx_pthread.m4 $(top_srcdir)/m4/libtool.m4 \ $(top_srcdir)/m4/ltoptions.m4 $(top_srcdir)/m4/ltsugar.m4 \ $(top_srcdir)/m4/ltversion.m4 $(top_srcdir)/m4/lt~obsolete.m4 \ $(top_srcdir)/m4/yaz.m4 $(top_srcdir)/m4/yaz_libxml2.m4 \ $(top_srcdir)/configure.ac am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON) mkinstalldirs = $(install_sh) -d CONFIG_HEADER = $(top_builddir)/src/config.h CONFIG_CLEAN_FILES = local0.ent CONFIG_CLEAN_VPATH_FILES = AM_V_P = $(am__v_P_@AM_V@) am__v_P_ = $(am__v_P_@AM_DEFAULT_V@) am__v_P_0 = false am__v_P_1 = : AM_V_GEN = $(am__v_GEN_@AM_V@) am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@) am__v_GEN_0 = @echo " GEN " $@; am__v_GEN_1 = AM_V_at = $(am__v_at_@AM_V@) am__v_at_ = $(am__v_at_@AM_DEFAULT_V@) am__v_at_0 = @ am__v_at_1 = SOURCES = DIST_SOURCES = RECURSIVE_TARGETS = all-recursive check-recursive cscopelist-recursive \ ctags-recursive dvi-recursive html-recursive info-recursive \ install-data-recursive install-dvi-recursive \ install-exec-recursive install-html-recursive \ install-info-recursive install-pdf-recursive \ install-ps-recursive install-recursive installcheck-recursive \ installdirs-recursive pdf-recursive ps-recursive \ tags-recursive uninstall-recursive am__can_run_installinfo = \ case $$AM_UPDATE_INFO_DIR in \ n|no|NO) false;; \ *) (install-info --version) >/dev/null 2>&1;; \ esac am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; am__vpath_adj = case $$p in \ $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \ *) f=$$p;; \ esac; am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`; am__install_max = 40 am__nobase_strip_setup = \ srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'` am__nobase_strip = \ for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||" am__nobase_list = $(am__nobase_strip_setup); \ for p in $$list; do echo "$$p $$p"; done | \ sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \ $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \ if (++n[$$2] == $(am__install_max)) \ { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \ END { for (dir in files) print dir, files[dir] }' am__base_list = \ sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \ sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g' am__uninstall_files_from_dir = { \ { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \ || { echo " ( cd '$$dir' && rm -f" $$files ")"; \ $(am__cd) "$$dir" && echo $$files | $(am__xargs_n) 40 $(am__rm_f); }; \ } man1dir = $(mandir)/man1 am__installdirs = "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man7dir)" \ "$(DESTDIR)$(man8dir)" "$(DESTDIR)$(docdir)" man7dir = $(mandir)/man7 man8dir = $(mandir)/man8 NROFF = nroff MANS = $(man_MANS) DATA = $(doc_DATA) RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive \ distclean-recursive maintainer-clean-recursive am__recursive_targets = \ $(RECURSIVE_TARGETS) \ $(RECURSIVE_CLEAN_TARGETS) \ $(am__extra_recursive_targets) AM_RECURSIVE_TARGETS = $(am__recursive_targets:-recursive=) TAGS CTAGS \ distdir distdir-am am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP) # Read a list of newline-separated strings from the standard input, # and print each of them once, without duplicates. Input order is # *not* preserved. am__uniquify_input = $(AWK) '\ BEGIN { nonempty = 0; } \ { items[$$0] = 1; nonempty = 1; } \ END { if (nonempty) { for (i in items) print i; }; } \ ' # Make sure the list of sources is unique. This is necessary because, # e.g., the same source file might be shared among _SOURCES variables # for different programs/libraries. am__define_uniq_tagged_files = \ list='$(am__tagged_files)'; \ unique=`for i in $$list; do \ if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ done | $(am__uniquify_input)` DIST_SUBDIRS = $(SUBDIRS) am__DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/local0.ent.in DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) am__relativize = \ dir0=`pwd`; \ sed_first='s,^\([^/]*\)/.*$$,\1,'; \ sed_rest='s,^[^/]*/*,,'; \ sed_last='s,^.*/\([^/]*\)$$,\1,'; \ sed_butlast='s,/*[^/]*$$,,'; \ while test -n "$$dir1"; do \ first=`echo "$$dir1" | sed -e "$$sed_first"`; \ if test "$$first" != "."; then \ if test "$$first" = ".."; then \ dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \ dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \ else \ first2=`echo "$$dir2" | sed -e "$$sed_first"`; \ if test "$$first2" = "$$first"; then \ dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \ else \ dir2="../$$dir2"; \ fi; \ dir0="$$dir0"/"$$first"; \ fi; \ fi; \ dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \ done; \ reldir="$$dir2" ACLOCAL = @ACLOCAL@ AMTAR = @AMTAR@ AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@ AR = @AR@ AUTOCONF = @AUTOCONF@ AUTOHEADER = @AUTOHEADER@ AUTOMAKE = @AUTOMAKE@ AWK = @AWK@ CC = @CC@ CCDEPMODE = @CCDEPMODE@ CFLAGS = @CFLAGS@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CSCOPE = @CSCOPE@ CTAGS = @CTAGS@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ DLLTOOL = @DLLTOOL@ DSSSL_DIR = @DSSSL_DIR@ DSYMUTIL = @DSYMUTIL@ DTD_DIR = @DTD_DIR@ DUMPBIN = @DUMPBIN@ ECHO_C = @ECHO_C@ ECHO_N = @ECHO_N@ ECHO_T = @ECHO_T@ EGREP = @EGREP@ ETAGS = @ETAGS@ EXEEXT = @EXEEXT@ FGREP = @FGREP@ FILECMD = @FILECMD@ GREP = @GREP@ HIREDIS_LIBS = @HIREDIS_LIBS@ HTML_COMPILE = @HTML_COMPILE@ ICU_CFLAGS = @ICU_CFLAGS@ ICU_CONFIG = @ICU_CONFIG@ ICU_CPPFLAGS = @ICU_CPPFLAGS@ ICU_LIBS = @ICU_LIBS@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ LD = @LD@ LDFLAGS = @LDFLAGS@ LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ LIPO = @LIPO@ LN_S = @LN_S@ LTLIBOBJS = @LTLIBOBJS@ LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@ MAKEINFO = @MAKEINFO@ MANIFEST_TOOL = @MANIFEST_TOOL@ MAN_COMPILE = @MAN_COMPILE@ MEMCACHED_LIBS = @MEMCACHED_LIBS@ MKDIR_P = @MKDIR_P@ NM = @NM@ NMEDIT = @NMEDIT@ OBJDUMP = @OBJDUMP@ OBJEXT = @OBJEXT@ OTOOL = @OTOOL@ OTOOL64 = @OTOOL64@ PACKAGE = @PACKAGE@ PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@ PACKAGE_NAME = @PACKAGE_NAME@ PACKAGE_STRING = @PACKAGE_STRING@ PACKAGE_TARNAME = @PACKAGE_TARNAME@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ PDF_COMPILE = @PDF_COMPILE@ PKG_CONFIG = @PKG_CONFIG@ PTHREAD_CC = @PTHREAD_CC@ PTHREAD_CFLAGS = @PTHREAD_CFLAGS@ PTHREAD_LIBS = @PTHREAD_LIBS@ RANLIB = @RANLIB@ READLINE_LIBS = @READLINE_LIBS@ SED = @SED@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ SSL_CFLAGS = @SSL_CFLAGS@ SSL_LIBS = @SSL_LIBS@ STRIP = @STRIP@ TCLSH = @TCLSH@ TCPD_LIBS = @TCPD_LIBS@ TKL_COMPILE = @TKL_COMPILE@ VERSION = @VERSION@ VERSION_HEX = @VERSION_HEX@ VERSION_SHA1 = @VERSION_SHA1@ WIN_FILEVERSION = @WIN_FILEVERSION@ XML2_CFLAGS = @XML2_CFLAGS@ XSLTPROC_COMPILE = @XSLTPROC_COMPILE@ XSL_DIR = @XSL_DIR@ YACC = @YACC@ YAZ_CONFIG_CFLAGS = @YAZ_CONFIG_CFLAGS@ YAZ_CONF_CFLAGS = @YAZ_CONF_CFLAGS@ abs_builddir = @abs_builddir@ abs_srcdir = @abs_srcdir@ abs_top_builddir = @abs_top_builddir@ abs_top_srcdir = @abs_top_srcdir@ ac_ct_AR = @ac_ct_AR@ ac_ct_CC = @ac_ct_CC@ ac_ct_DUMPBIN = @ac_ct_DUMPBIN@ acx_pthread_config = @acx_pthread_config@ am__include = @am__include@ am__leading_dot = @am__leading_dot@ am__quote = @am__quote@ am__rm_f_notfound = @am__rm_f_notfound@ am__tar = @am__tar@ am__untar = @am__untar@ am__xargs_n = @am__xargs_n@ bindir = @bindir@ build = @build@ build_alias = @build_alias@ build_cpu = @build_cpu@ build_os = @build_os@ build_vendor = @build_vendor@ builddir = @builddir@ datadir = @datadir@ datarootdir = @datarootdir@ docdir = @docdir@ dvidir = @dvidir@ exec_prefix = @exec_prefix@ host = @host@ host_alias = @host_alias@ host_cpu = @host_cpu@ host_os = @host_os@ host_vendor = @host_vendor@ htmldir = @htmldir@ includedir = @includedir@ infodir = @infodir@ install_sh = @install_sh@ libdir = @libdir@ libexecdir = @libexecdir@ localedir = @localedir@ localstatedir = @localstatedir@ mandir = @mandir@ mkdir_p = @mkdir_p@ oldincludedir = @oldincludedir@ pdfdir = @pdfdir@ pkgconfigpath = @pkgconfigpath@ prefix = @prefix@ program_transform_name = @program_transform_name@ psdir = @psdir@ runstatedir = @runstatedir@ sbindir = @sbindir@ sharedstatedir = @sharedstatedir@ srcdir = @srcdir@ sysconfdir = @sysconfdir@ target_alias = @target_alias@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ SUBDIRS = common XMLFILES = book.xml \ gfs-options.xml gfs-virtual.xml gfs-synopsis.xml \ std-oid-table.xml bib1-diag-table.xml srw-diag-table.xml \ manref.xml local.ent HTMLFILES = index.html MANFILES = yaz-client.1 yaz-ztest.8 \ yaz-config.1 yaz.7 zoomsh.1 yaz-asncomp.1 \ yaz-marcdump.1 yaz-iconv.1 yaz-log.7 \ yaz-illclient.1 yaz-icu.1 yaz-url.1 bib1-attr.7 \ yaz-json-parse.1 yaz-record-conv.1 REFFILES = yaz-client-man.xml yaz-ztest-man.xml yaz-config-man.xml \ yaz-man.xml zoomsh-man.xml yaz-asncomp-man.xml \ yaz-marcdump-man.xml yaz-iconv-man.xml yaz-log-man.xml \ yaz-illclient-man.xml yaz-icu-man.xml yaz-url-man.xml \ bib1-attr-man.xml yaz-json-parse-man.xml yaz-record-conv-man.xml SUPPORTFILES = entities.ent apilayer.obj doc_DATA = $(HTMLFILES) apilayer.png man_MANS = $(MANFILES) EXTRA_DIST = $(XMLFILES) $(SUPPORTFILES) $(man_MANS) $(REFFILES) \ $(doc_DATA) all: all-recursive .SUFFIXES: $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps) @for dep in $?; do \ case '$(am__configure_deps)' in \ *$$dep*) \ ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \ && { if test -f $@; then exit 0; else break; fi; }; \ exit 1;; \ esac; \ done; \ echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu doc/Makefile'; \ $(am__cd) $(top_srcdir) && \ $(AUTOMAKE) --gnu doc/Makefile Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status @case '$?' in \ *config.status*) \ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \ *) \ echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \ cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \ esac; $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(top_srcdir)/configure: $(am__configure_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(ACLOCAL_M4): $(am__aclocal_m4_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(am__aclocal_m4_deps): local0.ent: $(top_builddir)/config.status $(srcdir)/local0.ent.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ mostlyclean-libtool: -rm -f *.lo clean-libtool: -rm -rf .libs _libs install-man1: $(man_MANS) @$(NORMAL_INSTALL) @list1=''; \ list2='$(man_MANS)'; \ test -n "$(man1dir)" \ && test -n "`echo $$list1$$list2`" \ || exit 0; \ echo " $(MKDIR_P) '$(DESTDIR)$(man1dir)'"; \ $(MKDIR_P) "$(DESTDIR)$(man1dir)" || exit 1; \ { for i in $$list1; do echo "$$i"; done; \ if test -n "$$list2"; then \ for i in $$list2; do echo "$$i"; done \ | sed -n '/\.1[a-z]*$$/p'; \ fi; \ } | while read p; do \ if test -f $$p; then d=; else d="$(srcdir)/"; fi; \ echo "$$d$$p"; echo "$$p"; \ done | \ sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \ -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \ sed 'N;N;s,\n, ,g' | { \ list=; while read file base inst; do \ if test "$$base" = "$$inst"; then list="$$list $$file"; else \ echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \ $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \ fi; \ done; \ for i in $$list; do echo "$$i"; done | $(am__base_list) | \ while read files; do \ test -z "$$files" || { \ echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \ $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \ done; } uninstall-man1: @$(NORMAL_UNINSTALL) @list=''; test -n "$(man1dir)" || exit 0; \ files=`{ for i in $$list; do echo "$$i"; done; \ l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \ sed -n '/\.1[a-z]*$$/p'; \ } | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \ -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \ dir='$(DESTDIR)$(man1dir)'; $(am__uninstall_files_from_dir) install-man7: $(man_MANS) @$(NORMAL_INSTALL) @list1=''; \ list2='$(man_MANS)'; \ test -n "$(man7dir)" \ && test -n "`echo $$list1$$list2`" \ || exit 0; \ echo " $(MKDIR_P) '$(DESTDIR)$(man7dir)'"; \ $(MKDIR_P) "$(DESTDIR)$(man7dir)" || exit 1; \ { for i in $$list1; do echo "$$i"; done; \ if test -n "$$list2"; then \ for i in $$list2; do echo "$$i"; done \ | sed -n '/\.7[a-z]*$$/p'; \ fi; \ } | while read p; do \ if test -f $$p; then d=; else d="$(srcdir)/"; fi; \ echo "$$d$$p"; echo "$$p"; \ done | \ sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^7][0-9a-z]*$$,7,;x' \ -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \ sed 'N;N;s,\n, ,g' | { \ list=; while read file base inst; do \ if test "$$base" = "$$inst"; then list="$$list $$file"; else \ echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man7dir)/$$inst'"; \ $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man7dir)/$$inst" || exit $$?; \ fi; \ done; \ for i in $$list; do echo "$$i"; done | $(am__base_list) | \ while read files; do \ test -z "$$files" || { \ echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man7dir)'"; \ $(INSTALL_DATA) $$files "$(DESTDIR)$(man7dir)" || exit $$?; }; \ done; } uninstall-man7: @$(NORMAL_UNINSTALL) @list=''; test -n "$(man7dir)" || exit 0; \ files=`{ for i in $$list; do echo "$$i"; done; \ l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \ sed -n '/\.7[a-z]*$$/p'; \ } | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^7][0-9a-z]*$$,7,;x' \ -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \ dir='$(DESTDIR)$(man7dir)'; $(am__uninstall_files_from_dir) install-man8: $(man_MANS) @$(NORMAL_INSTALL) @list1=''; \ list2='$(man_MANS)'; \ test -n "$(man8dir)" \ && test -n "`echo $$list1$$list2`" \ || exit 0; \ echo " $(MKDIR_P) '$(DESTDIR)$(man8dir)'"; \ $(MKDIR_P) "$(DESTDIR)$(man8dir)" || exit 1; \ { for i in $$list1; do echo "$$i"; done; \ if test -n "$$list2"; then \ for i in $$list2; do echo "$$i"; done \ | sed -n '/\.8[a-z]*$$/p'; \ fi; \ } | while read p; do \ if test -f $$p; then d=; else d="$(srcdir)/"; fi; \ echo "$$d$$p"; echo "$$p"; \ done | \ sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \ -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \ sed 'N;N;s,\n, ,g' | { \ list=; while read file base inst; do \ if test "$$base" = "$$inst"; then list="$$list $$file"; else \ echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \ $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \ fi; \ done; \ for i in $$list; do echo "$$i"; done | $(am__base_list) | \ while read files; do \ test -z "$$files" || { \ echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \ $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \ done; } uninstall-man8: @$(NORMAL_UNINSTALL) @list=''; test -n "$(man8dir)" || exit 0; \ files=`{ for i in $$list; do echo "$$i"; done; \ l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \ sed -n '/\.8[a-z]*$$/p'; \ } | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \ -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \ dir='$(DESTDIR)$(man8dir)'; $(am__uninstall_files_from_dir) install-docDATA: $(doc_DATA) @$(NORMAL_INSTALL) @list='$(doc_DATA)'; test -n "$(docdir)" || list=; \ if test -n "$$list"; then \ echo " $(MKDIR_P) '$(DESTDIR)$(docdir)'"; \ $(MKDIR_P) "$(DESTDIR)$(docdir)" || exit 1; \ fi; \ for p in $$list; do \ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ echo "$$d$$p"; \ done | $(am__base_list) | \ while read files; do \ echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(docdir)'"; \ $(INSTALL_DATA) $$files "$(DESTDIR)$(docdir)" || exit $$?; \ done uninstall-docDATA: @$(NORMAL_UNINSTALL) @list='$(doc_DATA)'; test -n "$(docdir)" || list=; \ files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \ dir='$(DESTDIR)$(docdir)'; $(am__uninstall_files_from_dir) # This directory's subdirectories are mostly independent; you can cd # into them and run 'make' without going through this Makefile. # To change the values of 'make' variables: instead of editing Makefiles, # (1) if the variable is set in 'config.status', edit 'config.status' # (which will cause the Makefiles to be regenerated when you run 'make'); # (2) otherwise, pass the desired values on the 'make' command line. $(am__recursive_targets): @fail=; \ if $(am__make_keepgoing); then \ failcom='fail=yes'; \ else \ failcom='exit 1'; \ fi; \ dot_seen=no; \ target=`echo $@ | sed s/-recursive//`; \ case "$@" in \ distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \ *) list='$(SUBDIRS)' ;; \ esac; \ for subdir in $$list; do \ echo "Making $$target in $$subdir"; \ if test "$$subdir" = "."; then \ dot_seen=yes; \ local_target="$$target-am"; \ else \ local_target="$$target"; \ fi; \ ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \ || eval $$failcom; \ done; \ if test "$$dot_seen" = "no"; then \ $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \ fi; test -z "$$fail" ID: $(am__tagged_files) $(am__define_uniq_tagged_files); mkid -fID $$unique tags: tags-recursive TAGS: tags tags-am: $(TAGS_DEPENDENCIES) $(am__tagged_files) set x; \ here=`pwd`; \ if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \ include_option=--etags-include; \ empty_fix=.; \ else \ include_option=--include; \ empty_fix=; \ fi; \ list='$(SUBDIRS)'; for subdir in $$list; do \ if test "$$subdir" = .; then :; else \ test ! -f $$subdir/TAGS || \ set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \ fi; \ done; \ $(am__define_uniq_tagged_files); \ shift; \ if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \ test -n "$$unique" || unique=$$empty_fix; \ if test $$# -gt 0; then \ $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \ "$$@" $$unique; \ else \ $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \ $$unique; \ fi; \ fi ctags: ctags-recursive CTAGS: ctags ctags-am: $(TAGS_DEPENDENCIES) $(am__tagged_files) $(am__define_uniq_tagged_files); \ test -z "$(CTAGS_ARGS)$$unique" \ || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \ $$unique GTAGS: here=`$(am__cd) $(top_builddir) && pwd` \ && $(am__cd) $(top_srcdir) \ && gtags -i $(GTAGS_ARGS) "$$here" cscopelist: cscopelist-recursive cscopelist-am: $(am__tagged_files) list='$(am__tagged_files)'; \ case "$(srcdir)" in \ [\\/]* | ?:[\\/]*) sdir="$(srcdir)" ;; \ *) sdir=$(subdir)/$(srcdir) ;; \ esac; \ for i in $$list; do \ if test -f "$$i"; then \ echo "$(subdir)/$$i"; \ else \ echo "$$sdir/$$i"; \ fi; \ done >> $(top_builddir)/cscope.files distclean-tags: -rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags distdir: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) distdir-am distdir-am: $(DISTFILES) @srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ list='$(DISTFILES)'; \ dist_files=`for file in $$list; do echo $$file; done | \ sed -e "s|^$$srcdirstrip/||;t" \ -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \ case $$dist_files in \ */*) $(MKDIR_P) `echo "$$dist_files" | \ sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \ sort -u` ;; \ esac; \ for file in $$dist_files; do \ if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \ if test -d $$d/$$file; then \ dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \ if test -d "$(distdir)/$$file"; then \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \ cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \ else \ test -f "$(distdir)/$$file" \ || cp -p $$d/$$file "$(distdir)/$$file" \ || exit 1; \ fi; \ done @list='$(DIST_SUBDIRS)'; for subdir in $$list; do \ if test "$$subdir" = .; then :; else \ $(am__make_dryrun) \ || test -d "$(distdir)/$$subdir" \ || $(MKDIR_P) "$(distdir)/$$subdir" \ || exit 1; \ dir1=$$subdir; dir2="$(distdir)/$$subdir"; \ $(am__relativize); \ new_distdir=$$reldir; \ dir1=$$subdir; dir2="$(top_distdir)"; \ $(am__relativize); \ new_top_distdir=$$reldir; \ echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \ echo " am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \ ($(am__cd) $$subdir && \ $(MAKE) $(AM_MAKEFLAGS) \ top_distdir="$$new_top_distdir" \ distdir="$$new_distdir" \ am__remove_distdir=: \ am__skip_length_check=: \ am__skip_mode_fix=: \ distdir) \ || exit 1; \ fi; \ done $(MAKE) $(AM_MAKEFLAGS) \ top_distdir="$(top_distdir)" distdir="$(distdir)" \ dist-hook check-am: all-am check: check-recursive all-am: Makefile $(MANS) $(DATA) installdirs: installdirs-recursive installdirs-am: for dir in "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man7dir)" "$(DESTDIR)$(man8dir)" "$(DESTDIR)$(docdir)"; do \ test -z "$$dir" || $(MKDIR_P) "$$dir"; \ done install: install-recursive install-exec: install-exec-recursive install-data: install-data-recursive uninstall: uninstall-recursive install-am: all-am @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am installcheck: installcheck-recursive install-strip: if test -z '$(STRIP)'; then \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ install; \ else \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \ fi mostlyclean-generic: clean-generic: distclean-generic: -$(am__rm_f) $(CONFIG_CLEAN_FILES) -test . = "$(srcdir)" || $(am__rm_f) $(CONFIG_CLEAN_VPATH_FILES) maintainer-clean-generic: @echo "This command is intended for maintainers to use" @echo "it deletes files that may require special tools to rebuild." clean: clean-recursive clean-am: clean-generic clean-libtool mostlyclean-am distclean: distclean-recursive -rm -f Makefile distclean-am: clean-am distclean-generic distclean-local \ distclean-tags dvi: dvi-recursive dvi-am: html: html-recursive html-am: info: info-recursive info-am: install-data-am: install-docDATA install-man @$(NORMAL_INSTALL) $(MAKE) $(AM_MAKEFLAGS) install-data-hook install-dvi: install-dvi-recursive install-dvi-am: install-exec-am: install-html: install-html-recursive install-html-am: install-info: install-info-recursive install-info-am: install-man: install-man1 install-man7 install-man8 install-pdf: install-pdf-recursive install-pdf-am: install-ps: install-ps-recursive install-ps-am: installcheck-am: maintainer-clean: maintainer-clean-recursive -rm -f Makefile maintainer-clean-am: distclean-am maintainer-clean-generic mostlyclean: mostlyclean-recursive mostlyclean-am: mostlyclean-generic mostlyclean-libtool pdf: pdf-recursive pdf-am: ps: ps-recursive ps-am: uninstall-am: uninstall-docDATA uninstall-man @$(NORMAL_INSTALL) $(MAKE) $(AM_MAKEFLAGS) uninstall-hook uninstall-man: uninstall-man1 uninstall-man7 uninstall-man8 .MAKE: $(am__recursive_targets) install-am install-data-am \ install-strip uninstall-am .PHONY: $(am__recursive_targets) CTAGS GTAGS TAGS all all-am check \ check-am clean clean-generic clean-libtool cscopelist-am ctags \ ctags-am dist-hook distclean distclean-generic \ distclean-libtool distclean-local distclean-tags distdir dvi \ dvi-am html html-am info info-am install install-am \ install-data install-data-am install-data-hook install-docDATA \ install-dvi install-dvi-am install-exec install-exec-am \ install-html install-html-am install-info install-info-am \ install-man install-man1 install-man7 install-man8 install-pdf \ install-pdf-am install-ps install-ps-am install-strip \ installcheck installcheck-am installdirs installdirs-am \ maintainer-clean maintainer-clean-generic mostlyclean \ mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \ tags tags-am uninstall uninstall-am uninstall-docDATA \ uninstall-hook uninstall-man uninstall-man1 uninstall-man7 \ uninstall-man8 .PRECIOUS: Makefile std-oid-table.xml: $(srcdir)/../src/oid.csv $(TCLSH) $(top_srcdir)/src/oidtoc.tcl $(top_srcdir)/src/oid.csv std-oid-table.xml bib1-diag-table.xml: $(srcdir)/../src/bib1.csv $(TCLSH) $(srcdir)/../src/csvtodiag.tcl $(srcdir)/../src/bib1.csv bib1-diag-table.xml bib1-diag-table srw-diag-table.xml: $(srcdir)/../src/srw.csv $(TCLSH) $(srcdir)/../src/csvtodiag.tcl $(srcdir)/../src/srw.csv srw-diag-table.xml srw-diag-table yaz-client.1: $(srcdir)/yaz-client-man.xml $(MAN_COMPILE) $(srcdir)/yaz-client-man.xml yaz-ztest.8: yaz-ztest-man.xml gfs-options.xml gfs-synopsis.xml gfs-virtual.xml $(MAN_COMPILE) $(srcdir)/yaz-ztest-man.xml yaz-config.1: yaz-config-man.xml $(MAN_COMPILE) $(srcdir)/yaz-config-man.xml yaz.7: yaz-man.xml $(MAN_COMPILE) $(srcdir)/yaz-man.xml bib1-attr.7: bib1-attr-man.xml $(MAN_COMPILE) $(srcdir)/bib1-attr-man.xml zoomsh.1: zoomsh-man.xml $(MAN_COMPILE) $(srcdir)/zoomsh-man.xml yaz-asncomp.1: yaz-asncomp-man.xml $(MAN_COMPILE) $(srcdir)/yaz-asncomp-man.xml yaz-marcdump.1: yaz-marcdump-man.xml $(MAN_COMPILE) $(srcdir)/yaz-marcdump-man.xml yaz-iconv.1: yaz-iconv-man.xml $(MAN_COMPILE) $(srcdir)/yaz-iconv-man.xml yaz-illclient.1: yaz-illclient-man.xml $(MAN_COMPILE) $(srcdir)/yaz-illclient-man.xml yaz-log.7: yaz-log-man.xml $(MAN_COMPILE) $(srcdir)/yaz-log-man.xml yaz-icu.1: yaz-icu-man.xml $(MAN_COMPILE) $(srcdir)/yaz-icu-man.xml yaz-url.1: yaz-url-man.xml $(MAN_COMPILE) $(srcdir)/yaz-url-man.xml yaz-json-parse.1: yaz-json-parse-man.xml $(MAN_COMPILE) $(srcdir)/yaz-json-parse-man.xml yaz-record-conv.1: yaz-record-conv-man.xml $(MAN_COMPILE) $(srcdir)/yaz-record-conv-man.xml $(HTMLFILES): $(XMLFILES) rm -f *.html $(HTML_COMPILE) $(srcdir)/book.xml $(MANFILES): local.ent yaz.pdf: $(XMLFILES) $(PDF_COMPILE) $(srcdir)/book.xml && mv book.pdf yaz.pdf yazj.pdf: jade -E14 -D $(srcdir) -d common/print.dsl -t tex $(srcdir)/common/xml.dcl $(srcdir)/book.xml rm -f yazj.pdf cp book.tex yazj.tex pdfjadetex yazj.tex pdfjadetex yazj.tex >/dev/null pdfjadetex yazj.tex >/dev/null manref.xml: $(REFFILES) $(srcdir)/common/stripref.xsl local.ent rm -f manref.xml for i in $(REFFILES); do \ xsltproc $(srcdir)/common/stripref.xsl $(srcdir)/$$i | sed 1d >>manref.xml; \ done apilayer.png: tgif -print -xbm apilayer.obj xbmtopbm apilayer.png dist-hook: if test -f index.html; then d=.; else d="$(srcdir)"; fi; \ for p in $$d/*.html; do \ cp $$p $(distdir); \ done doc-clean: rm -f manref.xml *.html *.[0-9] *.pdf toc.hhc htmlhelp.hhp install-data-hook: if test -f index.html; then d=.; else d="$(srcdir)"; fi; \ for p in $$d/*.html; do \ $(INSTALL_DATA) $$p $(DESTDIR)$(docdir); \ done uninstall-hook: rm -r $(DESTDIR)$(docdir) distclean-local: doc-clean # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: # Tell GNU make to disable its built-in pattern rules. %:: %,v %:: RCS/%,v %:: RCS/% %:: s.% %:: SCCS/s.% yaz-5.37.0/doc/yaz-illclient.html0000644000175000017500000000727615130444232015264 0ustar00adamadamyaz-illclient
yaz-illclient
Prev Reference Next

Name

yaz-illclient — ILL client

Synopsis

yaz-illclient [-f filename] [-v loglevel] [-D name=value...] [-o] [-u user] [-p password] [-V] [server-addr]

DESCRIPTION

yaz-illclient is a client which sends an ISO ILL request to a remote server and decodes the response from it. Exactly one server address ( server-addr ) must be specified.

OPTIONS

-f filename]

Specify filename.

-v loglevel]

Specify the log level.

-D name=value]

Defines name & value pair.

-o

Enable OCLC authentication.

-u user]

Specify user.

-p password]

Specify password.

-V

Show yaz-illclient version.

EXAMPLES

None yet.

FILES

None yet.

SEE ALSO

yaz(7)

Prev Up Next
yaz-log Home yaz-icu
yaz-5.37.0/doc/yaz-json-parse.10000644000175000017500000000377615130444227014567 0ustar00adamadam'\" t .\" Title: yaz-json-parse .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-JSON\-PARSE" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-json-parse \- YAZ JSON parser .SH "SYNOPSIS" .HP \w'\fByaz\-json\-parse\fR\ 'u \fByaz\-json\-parse\fR [\-p] .SH "DESCRIPTION" .PP \fByaz\-json\-parse\fR is a utility which demonstrates the JSON API of YAZ\&. (yaz/json\&.h)\&. .PP The program attempts to parse a JSON from standard input (stdin)\&. It will return exit code 1 if parsing fails and the parsing error message will be printed to standard error (stderr)\&. The program returns exit code 0 if parsing succeeds, and returns no output unless \-p is given (see below)\&. .SH "OPTIONS" .PP \-p .RS 4 Makes the JSON parser echo the JSON result string to standard output, if parsing from stdin was successful\&. If \-p is given twice, then the output is a multi\-line output with indentation (pretty print)\&. .RE .SH "SEE ALSO" .PP \fByaz\fR(7) .SH "AUTHORS" .PP \fBIndex Data\fR yaz-5.37.0/doc/server.invocation.html0000644000175000017500000003217615130444232016157 0ustar00adamadam6. Application Invocation
6. Application Invocation
Prev Chapter 4. Generic server Next

6. Application Invocation

The finished application has the following invocation syntax (by way of statserv_main()):

application [-install] [-installa] [-remove] [-a file] [-v level] [-l file] [-u uid] [-c config] [-f vconfig] [-C fname] [-t minutes] [-k kilobytes] [-K] [-d daemon] [-w dir] [-p pidfile] [-r kilobytes] [-ziDSTV1] [listener-spec...]

The options are:

-a file

Specify a file for dumping PDUs (for diagnostic purposes). The special name - (dash) sends output to stderr.

-S

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.

-1

Like -S but after one session the server exits. This mode is for debugging only.

-T

Operate the server in threaded mode. The server creates a thread for each connection rather than fork a process. Only available on UNIX systems that offer POSIX threads.

-s

Use the SR protocol (obsolete).

-z

Use the Z39.50 protocol (default). This option and -s 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.

-l file

The logfile.

-c config

A user option that serves as a specifier for some sort of configuration, usually a filename. The argument to this option is transferred to member configname of the statserv_options_block.

-f vconfig

This specifies an XML file that describes one or more YAZ frontend virtual servers.

-C fname

Sets SSL certificate file name for server (PEM).

-v level

The log level. Use a comma-separated list of members of the set {fatal,debug,warn,log,malloc,all,none}.

-u uid

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.

-w dir

The server changes to this directory before listening to incoming connections. This option is useful when the server is operating from the inetd daemon (see -i).

-p pidfile

Specifies that the server should write its Process ID to the file given by pidfile. A typical location would be /var/run/yaz-ztest.pid.

-i

Use this to make the the server run from the inetd server (UNIX only).

-D

Use this to make the server put itself in the background and run as a daemon. If neither -i nor -D is given, the server starts in the foreground.

-install

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.

-installa

Use this to install the server as an NT service and mark it as "auto-start. Control the server by going to the Services in the Control Panel.

-remove

Use this to remove the server from the NT services (Windows NT/2000/XP only).

-t minutes

Idle session timeout, in minutes.

-k size

Maximum record size/message size, in kilobytes.

-K

Forces no-keepalive for HTTP sessions. By default GFS will keep sessions alive for HTTP 1.1 sessions (as defined by the standard). Using this option will force GFS to close the connection for each operation.

-r size

Maximum size of log file before rotation occurs, in kilobytes. Default size is 1048576 k (=1 GB).

-d daemon

Set name of daemon to be used in hosts access file. See hosts_access(5) and tcpd(8).

-m time-format

Sets the format of time-stamps in the log-file. Specify a string in the input format to strftime().

-V

Display YAZ version and exit.

A listener specification consists of a transport mode followed by a colon (:) followed by a listener address. The transport mode is either tcp, unix: or ssl.

For TCP and SSL, an address has the form 

    hostname | IP-number [: portnumber]

The port number defaults to 210 (standard Z39.50 port).

For UNIX, the address is the filename of socket.

For TCP/IP and SSL, the special hostnames @, maps to IN6ADDR_ANY_INIT with IPV4 binding as well (bindv6only=0), The special hostname @4 binds to INADDR_ANY (IPV4 only listener). The special hostname @6 binds to IN6ADDR_ANY_INIT with bindv6only=1 (IPV6 only listener).

Example 4.1. Running the GFS on Unix

Assuming the server application appname is started as root, the following will make it listen on port 210. The server will change identity to nobody and write its log to /var/log/app.log. 

      application -l /var/log/app.log -u nobody tcp:@:210

The server will accept Z39.50 requests and offer SRU service on port 210.


Example 4.2. Setting up Apache as SRU Frontend

If you use Apache as your public web server and want to offer HTTP port 80 access to the YAZ server on 210, you can use the ProxyPass directive. If you have virtual host srw.mydomain you can use the following directives in Apache's httpd.conf: 

      <VirtualHost *>
       ErrorLog /home/srw/logs/error_log
       TransferLog /home/srw/logs/access_log
       ProxyPass / http://srw.mydomain:210/
      </VirtualHost>

The above is for the Apache 1.3 series.


Example 4.3. Running a server with local access only

A server that is only being accessed from the local host should listen on UNIX file socket rather than an Internet socket. To listen on /tmp/mysocket start the server as follows: 

      application unix:/tmp/mysocket


Prev Up Next
5. The Backend Functions Home 7. GFS Configuration and Virtual Hosts
yaz-5.37.0/doc/apilayer.obj0000644000175000017500000001572615123757344014134 0ustar00adamadam%TGIF 4.2.5-QPL state(1,37,100.000,0,20,1,16,1,0,0,0,0,0,3,1,1,0,'Helvetica',0,138240,0,0,1,5,0,1,1,1,0,16,0,0,1,1,1,0,1485,1050,0,0,2880,0). % % @(#)$Header$ % %W% % unit("1 pixel/pixel"). color_info(67,65535,0,[ "Black", 0, 0, 0, 0, 0, 0, 1, "White", 65535, 65535, 65535, 65535, 65535, 65535, 1, "#000080", 0, 0, 32896, 0, 0, 32768, 1, "#008000", 0, 32896, 0, 0, 32768, 0, 1, "#008080", 0, 32896, 32896, 0, 32768, 32768, 1, "#800000", 32896, 0, 0, 32768, 0, 0, 1, "#800080", 32896, 0, 32896, 32768, 0, 32768, 1, "#ff8000", 65535, 32896, 0, 65280, 32768, 0, 1, "#808080", 32896, 32896, 32896, 32768, 32768, 32768, 1, "#c0c0c0", 49344, 49344, 49344, 49152, 49152, 49152, 1, "#0000ff", 0, 0, 65535, 0, 0, 65280, 1, "#00ff00", 0, 65535, 0, 0, 65280, 0, 1, "#00ffff", 0, 65535, 65535, 0, 65280, 65280, 1, "#ff0000", 65535, 0, 0, 65280, 0, 0, 1, "#ff00ff", 65535, 0, 65535, 65280, 0, 65280, 1, "#ffff00", 65535, 65535, 0, 65280, 65280, 0, 1, "#4c4c4c", 19532, 19532, 19532, 19456, 19456, 19456, 1, "#b3b3b3", 46003, 46003, 46003, 45824, 45824, 45824, 1, "#e6e6e6", 59110, 59110, 59110, 58880, 58880, 58880, 1, "#dc2300", 56540, 8995, 0, 56320, 8960, 0, 1, "#ff3333", 65535, 13107, 13107, 65280, 13056, 13056, 1, "#b84747", 47288, 18247, 18247, 47104, 18176, 18176, 1, "#99284c", 39321, 10280, 19532, 39168, 10240, 19456, 1, "#94476b", 38036, 18247, 27499, 37888, 18176, 27392, 1, "#9966cc", 39321, 26214, 52428, 39168, 26112, 52224, 1, "#6b2394", 27499, 8995, 38036, 27392, 8960, 37888, 1, "#5e11a6", 24158, 4369, 42662, 24064, 4352, 42496, 1, "#4700b8", 18247, 0, 47288, 18176, 0, 47104, 1, "#2323dc", 8995, 8995, 56540, 8960, 8960, 56320, 1, "#0099ff", 0, 39321, 65535, 0, 39168, 65280, 1, "#99ccff", 39321, 52428, 65535, 39168, 52224, 65280, 1, "#00dcff", 0, 56540, 65535, 0, 56320, 65280, 1, "#23b8dc", 8995, 47288, 56540, 8960, 47104, 56320, 1, "#33a3a3", 13107, 41891, 41891, 13056, 41728, 41728, 1, "#355e00", 13621, 24158, 0, 13568, 24064, 0, 1, "#7da647", 32125, 42662, 18247, 32000, 42496, 18176, 1, "#00ae00", 0, 44718, 0, 0, 44544, 0, 1, "#3deb3d", 15677, 60395, 15677, 15616, 60160, 15616, 1, "#ffff99", 65535, 65535, 39321, 65280, 65280, 39168, 1, "#e6e64c", 59110, 59110, 19532, 58880, 58880, 19456, 1, "#b3b300", 46003, 46003, 0, 45824, 45824, 0, 1, "#666600", 26214, 26214, 0, 26112, 26112, 0, 1, "#4c1900", 19532, 6425, 0, 19456, 6400, 0, 1, "#663300", 26214, 13107, 0, 26112, 13056, 0, 1, "#804c19", 32896, 19532, 6425, 32768, 19456, 6400, 1, "#996633", 39321, 26214, 13107, 39168, 26112, 13056, 1, "#cc6633", 52428, 26214, 13107, 52224, 26112, 13056, 1, "#ff6633", 65535, 26214, 13107, 65280, 26112, 13056, 1, "#ff9966", 65535, 39321, 26214, 65280, 39168, 26112, 1, "#ffcc99", 65535, 52428, 39321, 65280, 52224, 39168, 1, "magenta", 65535, 0, 65535, 65535, 0, 65535, 1, "red", 65535, 0, 0, 65535, 0, 0, 1, "green", 0, 65535, 0, 0, 65535, 0, 1, "blue", 0, 0, 65535, 0, 0, 65535, 1, "yellow", 65535, 65535, 0, 65535, 65535, 0, 1, "pink", 65535, 49344, 52171, 65535, 49344, 52171, 1, "cyan", 0, 65535, 65535, 0, 65535, 65535, 1, "CadetBlue", 24415, 40606, 41120, 24415, 40606, 41120, 1, "DarkSlateGray", 12079, 20303, 20303, 12079, 20303, 20303, 1, "#00000000c000", 0, 0, 49344, 0, 0, 49152, 1, "#820782070000", 33410, 33410, 0, 33287, 33287, 0, 1, "#3cf3fbee34d2", 15420, 64507, 13364, 15603, 64494, 13522, 1, "#3cf3fbed34d3", 15420, 64507, 13364, 15603, 64493, 13523, 1, "#ffffa6990000", 65535, 42662, 0, 65535, 42649, 0, 1, "#ffff0000fffe", 65535, 0, 65535, 65535, 0, 65534, 1, "#fffe0000fffe", 65535, 0, 65535, 65534, 0, 65534, 1, "#fffe00000000", 65535, 0, 0, 65534, 0, 0, 1 ]). script_frac("0.6"). fg_bg_colors('Black','white'). dont_reencode("FFDingbests:ZapfDingbats"). objshadow_info('#c0c0c0',2,2). rotate_pivot(0,0,0,0). spline_tightness(1). page(1,"",1,''). text('Black',95,51,2,0,1,155,34,6,14,3,0,0,0,0,2,155,34,0,0,"",0,0,0,0,65,'',[ minilines(155,34,0,0,0,0,0,[ mini_line(155,14,3,0,0,0,[ str_block(0,155,14,3,0,-1,0,0,0,[ str_seg('Black','Helvetica',0,80640,155,14,3,0,-1,0,0,0,0,0, "Client/Server Application")]) ]), mini_line(0,14,3,0,0,0,[ str_block(0,0,14,3,0,0,0,0,0,[ str_seg('Black','Helvetica',0,80640,0,14,3,0,0,0,0,0,0,0, "")]) ]) ])]). text('Black',120,121,2,0,1,44,34,21,14,3,0,0,0,0,2,44,34,0,0,"",0,0,0,0,135,'',[ minilines(44,34,0,0,0,0,0,[ mini_line(44,14,3,0,0,0,[ str_block(0,44,14,3,0,-1,0,0,0,[ str_seg('Black','Helvetica',0,80640,44,14,3,0,-1,0,0,0,0,0, "Z39.50")]) ]), mini_line(39,14,3,0,0,0,[ str_block(0,39,14,3,0,-3,0,0,0,[ str_seg('Black','Helvetica',0,80640,39,14,3,0,-3,0,0,0,0,0, "ASN.1")]) ]) ])]). text('Black',190,186,1,0,1,37,17,25,14,3,0,0,0,0,2,37,17,0,0,"",0,0,0,0,200,'',[ minilines(37,17,0,0,0,0,0,[ mini_line(37,14,3,0,0,0,[ str_block(0,37,14,3,0,-1,0,0,0,[ str_seg('Black','Helvetica',0,80640,37,14,3,0,-1,0,0,0,0,0, "HTTP")]) ]) ])]). text('Black',240,266,1,0,1,26,17,53,14,3,0,0,0,0,2,26,17,0,0,"",0,0,0,0,280,'',[ minilines(26,17,0,0,0,0,0,[ mini_line(26,14,3,0,0,0,[ str_block(0,26,14,3,0,0,0,0,0,[ str_seg('Black','Helvetica',0,80640,26,14,3,0,0,0,0,0,0,0, "SSL")]) ]) ])]). box('Black','',35,230,305,255,0,1,1,197,0,0,0,0,0,'1',0,[ ]). box('Black','',175,180,305,215,0,1,1,198,0,0,0,0,0,'1',0,[ ]). box('Black','',175,115,240,165,0,1,1,200,0,0,0,0,0,'1',0,[ ]). box('Black','',100,115,170,165,0,1,1,203,0,0,0,0,0,'1',0,[ ]). box('Black','',205,255,305,290,0,1,1,214,0,0,0,0,0,'1',0,[ ]). text('Black',95,231,1,0,1,79,17,224,14,3,0,0,0,0,2,79,17,0,0,"",0,0,0,0,245,'',[ minilines(79,17,0,0,0,0,0,[ mini_line(79,14,3,0,0,0,[ str_block(0,79,14,3,0,0,0,0,0,[ str_seg('Black','Helvetica',0,80640,79,14,3,0,0,0,0,0,0,0, "COMSTACK")]) ]) ])]). text('Black',80,186,1,0,1,73,17,254,14,3,0,0,0,0,2,73,17,0,0,"",0,0,0,0,200,'',[ minilines(73,17,0,0,0,0,0,[ mini_line(73,14,3,0,0,0,[ str_block(0,73,14,3,0,-1,0,0,0,[ str_seg('Black','Helvetica',0,80640,73,14,3,0,-1,0,0,0,0,0, "ODR (BER)")]) ]) ])]). box('Black','',35,180,170,215,0,1,1,266,0,0,0,0,0,'1',0,[ ]). box('Black','',35,45,305,90,0,1,1,268,0,0,0,0,0,'1',0,[ ]). box('Black','',240,115,305,165,0,1,1,292,5,0,0,0,0,'1',0,[ ]). text('Black',255,126,1,0,1,25,17,293,14,3,0,0,0,0,2,25,17,0,0,"",0,0,0,0,140,'',[ minilines(25,17,0,0,0,0,0,[ mini_line(25,14,3,0,0,0,[ str_block(0,25,14,3,0,0,0,0,0,[ str_seg('Black','Helvetica',0,80640,25,14,3,0,0,0,0,0,0,0, "Solr")]) ]) ])]). text('Black',50,121,2,0,1,39,34,303,14,3,0,0,0,0,2,39,34,0,0,"",0,0,0,0,135,'',[ minilines(39,34,0,0,0,0,0,[ mini_line(20,14,3,0,0,0,[ str_block(0,20,14,3,0,0,0,0,0,[ str_seg('Black','Helvetica',0,80640,20,14,3,0,0,0,0,0,0,0, "ILL")]) ]), mini_line(39,14,3,0,0,0,[ str_block(0,39,14,3,0,-3,0,0,0,[ str_seg('Black','Helvetica',0,80640,39,14,3,0,-3,0,0,0,0,0, "ASN.1")]) ]) ])]). box('Black','',35,115,100,165,0,1,1,305,0,0,0,0,0,'1',0,[ ]). box('Black','',240,115,305,165,0,1,1,306,0,0,0,0,0,'1',0,[ ]). text('Black',190,126,1,0,1,29,17,323,14,3,0,0,0,0,2,29,17,0,0,"",0,0,0,0,140,'',[ minilines(29,17,0,0,0,0,0,[ mini_line(29,14,3,0,0,0,[ str_block(0,29,14,3,0,-1,0,0,0,[ str_seg('Black','Helvetica',0,80640,29,14,3,0,-1,0,0,0,0,0, "SRU")]) ]) ])]). yaz-5.37.0/doc/odr.debugging.html0000644000175000017500000000433115130444232015207 0ustar00adamadam4. Debugging
4. Debugging
Prev Chapter 8. The ODR Module Next

4. Debugging

The protocol modules are suffering somewhat from a lack of diagnostic tools at the moment. Specifically ways to pretty-print PDUs that aren't recognized by the system. We'll include something to this end in a not-too-distant release. In the meantime, what we do when we get packages we don't understand is to compile the ODR module with ODR_DEBUG defined. This causes the module to dump tracing information as it processes data units. With this output and the protocol specification (Z39.50), it is generally fairly easy to see what goes wrong.

Prev Up Next
3. Programming with ODR Home Chapter 9. The COMSTACK Module
yaz-5.37.0/doc/odr.html0000644000175000017500000001367415130444232013267 0ustar00adamadamChapter 8. The ODR Module
Chapter 8. The ODR Module
Prev   Next

Chapter 8. The ODR Module

Table of Contents

1. Introduction
2. Using ODR
2.1. ODR Streams
2.2. Memory Management
2.3. Encoding and Decoding Data
2.4. Printing
2.5. Diagnostics
2.6. Summary and Synopsis
3. Programming with ODR
3.1. The Primitive ASN.1 Types
3.1.1. INTEGER
3.1.2. BOOLEAN
3.1.3. REAL
3.1.4. NULL
3.1.5. OCTET STRING
3.1.6. BIT STRING
3.1.7. OBJECT IDENTIFIER
3.2. Tagging Primitive Types
3.3. Constructed Types
3.4. Tagging Constructed Types
3.4.1. Implicit Tagging
3.4.2. Explicit Tagging
3.5. SEQUENCE OF
3.6. CHOICE Types
4. Debugging

1. Introduction

ODR is the BER-encoding/decoding subsystem of YAZ. Care has been taken to isolate ODR from the rest of the package - specifically from the transport interface. ODR may be used in any context where basic ASN.1/BER representations are used.

If you are only interested in writing a Z39.50 implementation based on the PDUs that are already provided with YAZ, you only need to concern yourself with the section on managing ODR streams (Section 2, “Using ODR”). Only if you need to implement ASN.1 beyond that which has been provided, should you worry about the second half of the documentation (Section 3, “Programming with ODR”). If you use one of the higher-level interfaces, you can skip this section entirely.

This is important, so we'll repeat it for emphasis: You do not need to read Section 3, “Programming with ODR” to implement Z39.50 with YAZ.

If you need a part of the protocol that isn't already in YAZ, you should contact the authors before going to work on it yourself: We might already be working on it. Conversely, if you implement a useful part of the protocol before us, we'd be happy to include it in a future release.

Prev   Next
8. Facets Home 2. Using ODR
yaz-5.37.0/doc/comstack.html0000644000175000017500000001071015130444232014273 0ustar00adamadamChapter 9. The COMSTACK Module
Chapter 9. The COMSTACK Module
Prev   Next

Chapter 9. The COMSTACK Module

Table of Contents

1. Synopsis (blocking mode)
2. Introduction
3. Common Functions
3.1. Managing Endpoints
3.2. Data Exchange
4. Client Side
5. Server Side
6. Addresses
7. SSL
8. Diagnostics
9. Summary and Synopsis

1. Synopsis (blocking mode)

    COMSTACK stack;
    char *buf = 0;
    int size = 0, length_incoming;
    char server_address_str[] = "localhost:9999";
    void *server_address_ip;
    int status;

    char *protocol_package = "GET / HTTP/1.0\r\n\r\n";
    int protocol_package_length = strlen(protocol_package);

    stack = cs_create(tcpip_type, 1, PROTO_HTTP);
    if (!stack) {
        perror("cs_create");  /* use perror() here since we have no stack yet */
        return -1;
    }

    server_address_ip = cs_straddr(stack, server_address_str);
    if (!server_address_ip) {
        fprintf(stderr, "cs_straddr: address could not be resolved\n");
        return -1;
    }

    status = cs_connect(stack, server_address_ip);
    if (status) {
        fprintf(stderr, "cs_connect: %s\n", cs_strerror(stack));
        return -1;
    }

    status = cs_rcvconnect(stack);
    if (status) {
        fprintf(stderr, "cs_rcvconnect: %s\n", cs_strerror(stack));
        return -1;
    }

    status = cs_put(stack, protocol_package, protocol_package_length);
    if (status) {
        fprintf(stderr, "cs_put: %s\n", cs_strerror(stack));
        return -1;
    }

    /* Now get a response */
    length_incoming = cs_get(stack, &buf, &size);
    if (!length_incoming) {
        fprintf(stderr, "Connection closed\n");
        return -1;
    } else if (length_incoming < 0) {
        fprintf(stderr, "cs_get: %s\n", cs_strerror(stack));
        return -1;
    }

    /* Print result */
    fwrite(buf, length_incoming, 1, stdout);

    /* clean up */
    cs_close(stack);
    if (buf)
        xfree(buf);
    return 0;
Prev   Next
4. Debugging Home 2. Introduction
yaz-5.37.0/doc/yaz-client.html0000644000175000017500000011273415130444232014557 0ustar00adamadamyaz-client
yaz-client
Prev Reference Next

Name

yaz-client — Z39.50/SRU client for implementors

Synopsis

yaz-client [-a apdulog] [-b berdump] [-c cclfile] [-d dump] [-f cmdfile] [-k size] [-m marclog] [-p proxy-addr] [-q cqlfile] [-t dispcharset] [-u auth] [-v loglevel] [-V] [-x] [server-addr]

DESCRIPTION

yaz-client is a Z39.50/SRU client (origin) with a simple command line interface that allows you to test behavior and performance of Z39.50 targets and SRU servers.

From YAZ version 4.1.0 yaz-client may also operate as a Solr Web Service client.

If the server-addr is specified, the client creates a connection to the Z39.50/SRU target at the address given.

When yaz-client is started it tries to read commands from one of the following files:

  • Command file if it is given by option -f.

  • .yazclientrc in current working directory.

  • .yazclientrc in the user's home directory. The value of the $HOME environment variable is used to determine the home directory. Normally, $HOME is only set on POSIX systems such as Linux, FreeBSD, Solaris.

OPTIONS

-a filename

If specified, logging of protocol packages will be appended to the file given. If filename is specified as -, the output is written to stdout.

-b filename

If specified, YAZ will dump BER data in readable notation to the file specified. If filename is specified as - the output is written to stdout.

-c filename

If specified, CCL configuration will be read from the file given.

-d dump

If specified, YAZ will dump BER data for all PDUs sent and received to individual files, named dump.DDD.raw, where DDD is 001, 002, 003, ...

-f cmdfile

Reads commands from cmdfile. When this option is used, YAZ client does not read .yazclientrc from current directory or home directory.

-k size

Sets preferred messages and maximum record size for Initialize Request in kilobytes. Default value is 65536 (64 MB).

-m filename

If specified, retrieved records will be appended to the file given.

-p proxy-addr

If specified, the client will use the proxy at the address given. YAZ client will connect to a proxy on the address and port given. The actual target will be specified as part of the InitRequest to inform the proxy about the actual target.

-q filename

If specified, CQL configuration will be read from the file given.

-t displaycharset

If displaycharset is given, it specifies name of the character set of the output (on the terminal on which YAZ client is running).

-u auth

If specified, the auth string will be used for authentication.

-v level
Sets the LOG level to level. Level is a sequence of tokens separated by comma. Each token is a integer or a named LOG item - one of fatal, debug, warn, log, malloc, all, none.
-V

Prints YAZ version.

-x

Makes the YAZ client print hex dumps of packages sent and received on standard output.

COMMANDS

The YAZ client accepts the following commands.

open zurl

Opens a connection to a server. The syntax for zurl is the same as described above for connecting from the command line.

Syntax:

[(tcp|ssl|unix|http)':']host [:port][/base]

quit

Quits YAZ client

find query

Sends a Search Request using the query given. By default the query is assumed to be PQF. See command querytype for more information.

delete setname

Deletes result set with name setname on the server.

base base1 base2 ...

Sets the name(s) of the database(s) to search. One or more databases may be specified, separated by blanks. This command overrides the database given in zurl.

show [start[+number [+resultset]]]

Fetches records by sending a Present Request from the start position given by start and a number of records given by number, from the result set resultset. If start is not given, then the client will fetch from the position of the last retrieved record plus 1. If number is not given, then one record will be fetched at a time. If resultset is not given, the most recently retrieved result set is used.

scan term

Scans database index for a term. The syntax resembles the syntax for find. If you want to scan for the word water you could write 

      scan water

but if you want to scan only in, say the title field, you would write 

      scan @attr 1=4 water
setscan set term
Scans database index for a term within a result set. This is similar to the scan command but has a result set as its first argument.
scanpos pos
Sets preferred position for scan. This value is used in the next scan. By default, position is 1.
scansize size
Sets number of entries to be returned by scan. Default number of entries is 20.
scanstep step
Set step-size for scan. This value is used in the next scan sent to the target. By default step-size is 0.
sort sortspecs

Sorts a result set. The sort command takes a sequence of space-separated sort specifications, with each sort specification consisting of two space-separated words (so that the whole specification list is made up of an even number of words). The first word of each specification holds a field (sort criterion) and the second holds flags. If the sort criterion includes = it is assumed that the SortKey is of type sortAttributes using Bib-1: in this case the integer before = is the attribute type and the integer following = is the attribute value. If no = character is in the criterion, it is treated as a sortfield of type InternationalString. The flags word of each sort specification must consist of s for case sensitive or i for case insensitive, and < for ascending order or > for descending order.

Example using sort criterion with attributes use=local-number and structure=numeric and ascending flag: 1=12,4=109 <

Another example with "Title" sort field and descending flag: Title >

sort+

Same as sort but stores the sorted result set in a new result set.

authentication [auth1 [auth2 [auth3]]]

Configures authentication strings to be sent to server. Zero, 1, 2 or 3 arguments may follow the auth command.

If no (0) arguments are given, no authentication string is sent.

If one argument is given, the Z39.50 v2 OpenStyle authentication is used. A common convention for the auth1 string is that the username and password is separated by a slash, e.g. myusername/mysecret.

If two or more arguments is given Z39.50 v3 authentication is used, in which cased the first argument is used, second argument is group and third argument is password. If only two arguments are given the group is assumed to be empty.

As for other commands in yaz-client, the arguments are separated by whitespace. A backslash character can be used to include a character verbatim. For example, auth myuser a\ b is a two argument auth command where user is myuser and password is a b.

The authentication string is first sent to the server when the open command is issued and the Z39.50 Initialize Request is sent, so this command must be used before open in order to be effective.

sru method version

Selects Web Service method and version. Must be one of post, get, soap (default) or solr. Version should be either 1.1, 1.2 or 2.0 for SRU. Other versions are allowed - for testing purposes (version negotiation with SRU server). The version is currently not used for Solr Web Services

list_all

This command displays status and values for many settings.

lslb n

Sets the limit for when no records should be returned together with the search result. See the Z39.50 standard on set bounds for more details.

ssub n

Sets the limit for when all records should be returned with the search result. See the Z39.50 standard on set bounds for more details.

mspn n

Sets the number of records that should be returned if the number of records in the result set is between the values of lslb and ssub. See the Z39.50 standard on set bounds for more details.

status

Displays the values of lslb, ssub and mspn.

setname

Switches named result sets on and off. Default is on.

cancel

Sends a Trigger Resource Control Request to the target.

facets spec

Specifies requested facets to be used in search. The notation is specified in Section 8, “Facets”.

format oid

Sets the preferred transfer syntax for retrieved records. yaz-client supports all the record syntaxes that currently are registered. See Z39.50 Record Syntax Identifiers for more details. Commonly used records syntaxes include usmarc, sutrs and xml.

elements e

Sets the element set name for the records. Many targets support element sets B (for brief) and F (for full).

close

Sends a Z39.50 Close APDU and closes connection with the peer

querytype type

Sets the query type as used by command find. The following is supported: prefix for Prefix Query Notation (Type-1 Query); ccl for CCL search (Type-2 Query), cql for CQL (Type-104 search with CQL OID), ccl2rpn for CCL to RPN conversion (Type-1 Query), cql2rpn for CQL to RPN conversion (Type-1 Query).

attributeset set

Sets attribute set OID for prefix queries (RPN, Type-1).

refid id

Sets reference ID for Z39.50 Request(s).

itemorder type no

Sends an Item Order Request using the ILL External. type is either 1 or 2 which corresponds to ILL-Profile 1 and 2 respectively. The no is the Result Set position of the record to be ordered.

update action recid doc

Sends Item Update Request. The action argument must be the action type: one of insert, replace, delete and update. The second argument, recid, is the record identifier (any string). Third argument which is optional is the record document for the request. If doc is preceded with "<", then the following characters are treated as a filename with the records to be updated. Otherwise doc is treated as a document itself. The doc may also be quoted in double quotes. If doc is omitted, the last received record (as part of present response or piggybacked search response) is used for the update.

source filename

Executes list of commands from file filename, just like 'source' on most UNIX shells. A single dot (.) can be used as an alternative.

! args

Executes command args in subshell using the system call.

push_command command

The push_command takes another command as its argument. That command is then added to the history information (so you can retrieve it later). The command itself is not executed. This command only works if you have GNU readline/history enabled.

set_apdufile filename

Sets that APDU should be logged to file filename. Another way to achieve APDU log is by using command-line option -a.

set_auto_reconnect flag

Specifies whether YAZ client automatically reconnects if the target closes connection (Z39.50 only).

flag must be either on or off.

set_auto_wait flag

Specifies whether YAZ client should wait for response protocol packages after a request. By default YAZ client waits (on) for response packages immediately after a command (find, show) has been issued. If off is used, YAZ client does not attempt to receive packages automatically. These will have to be manually received when command wait_response is used.

flag must be either on or off.

set_marcdump filename

Specifies that all retrieved records should be appended to file filename. This command does the same thing as option -m.

schema schemaid

Specifies schema for retrieval. Schema may be specified as an OID for Z39.50. For SRU, schema is a simple string URI.

charset negotiationcharset [displaycharset] [[marccharset]]

Specifies character set (encoding) for Z39.50 negotiation / SRU encoding and/or character set for output (terminal).

negotiationcharset is the name of the character set to be negotiated by the server. The special name - for negotiationcharset specifies no character set to be negotiated.

If displaycharset is given, it specifies name of the character set of the output (on the terminal on which YAZ client is running). To disable conversion of characters to the output encoding, the special name - (dash) can be used. If the special name auto is given, YAZ client will convert strings to the encoding of the terminal as returned by nl_langinfo call.

If marccharset is given, it specifies name of the character set of retrieved MARC records from server. See also marccharset command.

Note

Since character set negotiation takes effect in the Z39.50 Initialize Request you should issue this command before command open is used.

Note

MARC records are not covered by Z39.50 character set negotiation, so that's why there is a separate character that must be known in order to do meaningful conversion(s).

negcharset charset

Specifies character set for negotiation (Z39.50). The argument is the same as second argument for command charset.

displaycharset charset

Specifies character set for output (display). The argument is the same as second argument for command charset.

marccharset charset

Specifies character set for retrieved MARC records so that YAZ client can display them in a character suitable for your display. See charset command. If auto is given, YAZ will assume that MARC21/USMARC is using MARC8/UTF8 and ISO-8859-1 for all other MARC variants. The charset argument is the same as third argument for command charset.

querycharset charset

Specifies character set for query terms for Z39.50 RPN queries and Z39.50 Scan Requests (termListAndStartPoint). This is a pure client-side conversion which converts from displayCharset to queryCharset.

set_cclfile filename

Specifies that CCL fields should be read from file file filename. This command does the same thing as option -c.

set_cqlfile filename

Specifies that CQL fields should be read from file file filename. This command does the same thing as option -q.

register_oid name class OID

This command allows you to register your own object identifier - so that instead of entering a long dot-notation you can use a short name instead. The name is your name for the OID, class is the class, and OID is the raw OID in dot notation. Class is one of: appctx, absyn, attet, transyn, diagset, recsyn, resform, accform, extserv, userinfo, elemspec, varset, schema, tagset, general. If you're in doubt use the general class.

register_tab command string

This command registers a TAB completion string for the command given.

sleep seconds

This command makes YAZ client sleep (be idle) for the number of seconds given.

wait_response [ number]

This command makes YAZ client wait for a number of response packages from target. If number is omitted, 1 is assumed.

This command is rarely used and is only useful if command set_auto_wait is set to off.

xmles OID doc

Sends XML Extended Services request using the OID and doc given.

zversion ver

This command sets Z39.50 version for negotiation. Should be used before open. By default 3 (version 3) is used.

options op1 op2..

This command sets Z39.50 options for negotiation. Should be used before open.

The following options are supported: search, present, delSet, resourceReport, triggerResourceCtrl, resourceCtrl, accessCtrl, scan, sort, extendedServices, level_1Segmentation, level_2Segmentation, concurrentOperations, namedResultSets, encapsulation, resultCount, negotiationModel, duplicationDetection, queryType104, pQESCorrection, stringSchema.

EXAMPLE

The simplest example of a Prefix Query would be something like 

    f knuth

or 

    f "donald knuth"

In those queries, no attributes were specified. This leaves it up to the server what fields to search but most servers will search in all fields. Some servers do not support this feature though, and require that some attributes are defined. To add one attribute you could do: 

    f @attr 1=4 computer

where we search in the title field, since the use(1) is title(4). If we want to search in the author field and in the title field, and in the title field using right truncation it could look something like this: 

    f @and @attr 1=1003 knuth @attr 1=4 @attr 5=1 computer

Finally using a mix of Bib-1 and GILS attributes could look something like this: 

    f @attrset Bib-1 @and @attr GILS 1=2008 Washington @attr 1=21 weather

FILES

yaz-<version>/client/client.c

$HOME/.yazclientrc

$HOME/.yazclient.history

SEE ALSO

yaz(7) bib1-attr(7)

Prev Up Next
Reference Home yaz-ztest
yaz-5.37.0/doc/yaz-iconv.html0000644000175000017500000001454415130444232014417 0ustar00adamadamyaz-iconv
yaz-iconv
Prev Reference Next

Name

yaz-iconv — YAZ Character set conversion utility

Synopsis

yaz-iconv [-f from] [-t to] [-v] [file...]

DESCRIPTION

yaz-iconv converts data in the character set specified by from to output in the character set as specified by to.

This yaz-iconv utility is similar to the iconv found on many POSIX systems (Glibc, Solaris, etc).

If no file is specified, yaz-iconv reads from standard input.

OPTIONS

-ffrom]

Specify the character set from of the input file. Should be used in conjunction with option -t.

-tto]

Specify the character set of of the output. Should be used in conjunction with option -f.

-v

Print more information about the conversion process.

ENCODINGS

The yaz-iconv command and the API as defined in yaz/yaz-iconv.h is a wrapper for the library system call iconv. But YAZ' iconv utility also implements conversions on its own. The table below lists characters sets (or encodings) that are supported by YAZ. Each character set is marked with either encode or decode. If an encoding is encode-enabled, YAZ may convert to the designated encoding. If an encoding is decode-enabled, YAZ may convert from the designated encoding.

marc8 (encode, decode)

The MARC8 encoding as defined by the Library of Congress. Most MARC21/USMARC records use this encoding.

marc8s (encode, decode)

Like MARC8 but conversion prefers non-combined characters in the Latin-1 plane over combined characters.

marc8lossy (encode)

Lossy encoding of MARC-8.

marc8lossless (encode)

Lossless encoding of MARC8.

utf8 (encode, decode)

The most commonly used UNICODE encoding on the Internet.

iso8859-1 (encode, decode)

ISO-8859-1, AKA Latin-1.

iso5426 (decode)

ISO 5426. Some MARC records (UNIMARC) use this encoding.

iso5428:1984 (encode, decode)

ISO 5428:1984.

advancegreek (encode, decode)

An encoding for Greek in use by some vendors (Advance).

danmarc (decode)

Danmarc (in danish) is an encoding based on UNICODE which is used for DanMARC2 records.

EXAMPLES

The following command converts from ISO-8859-1 (Latin-1) to UTF-8. 

    yaz-iconv -f ISO-8859-1 -t UTF-8 <input.lst >output.lst

FILES

prefix/bin/yaz-iconv

prefix/include/yaz/yaz-iconv.h

SEE ALSO

yaz(7) iconv(1)

Prev Up Next
yaz-marcdump Home yaz-log
yaz-5.37.0/doc/yaz-illclient-man.xml0000644000175000017500000000625515123757344015702 0ustar00adamadam %local; %entities; %idcommon; ]> YAZ &version; Index Data yaz-illclient 1 Commands yaz-illclient ILL client yaz-illclient name=value server-addr DESCRIPTION yaz-illclient is a client which sends an ISO ILL request to a remote server and decodes the response from it. Exactly one server address ( server-addr ) must be specified. OPTIONS -f filename] Specify filename. -v loglevel] Specify the log level. -D name=value] Defines name & value pair. -o Enable OCLC authentication. -u user] Specify user. -p password] Specify password. -V Show yaz-illclient version. EXAMPLES None yet. FILES None yet. SEE ALSO yaz(7) yaz-5.37.0/doc/yaz-marcdump.10000644000175000017500000001447515130444226014313 0ustar00adamadam'\" t .\" Title: yaz-marcdump .\" Author: Index Data .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 01/10/2026 .\" Manual: Commands .\" Source: YAZ 5.37.0 .\" Language: English .\" .TH "YAZ\-MARCDUMP" "1" "01/10/2026" "YAZ 5.37.0" "Commands" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" yaz-marcdump \- MARC record dump utility .SH "SYNOPSIS" .HP \w'\fByaz\-marcdump\fR\ 'u \fByaz\-marcdump\fR [\fB\-i\ \fR\fB\fIformat\fR\fR] [\fB\-o\ \fR\fB\fIformat\fR\fR] [\fB\-f\ \fR\fB\fIfrom\fR\fR] [\fB\-t\ \fR\fB\fIto\fR\fR] [\fB\-l\ \fR\fB\fIspec\fR\fR] [\fB\-c\ \fR\fB\fIcfile\fR\fR] [\fB\-s\ \fR\fB\fIprefix\fR\fR] [\fB\-C\ \fR\fB\fIsize\fR\fR] [\fB\-O\ \fR\fB\fIoffset\fR\fR] [\fB\-L\ \fR\fB\fIlimit\fR\fR] [\fB\-n\fR] [\fB\-p\fR] [\fB\-r\fR] [\fB\-v\fR] [\fB\-V\fR] [file...] .SH "DESCRIPTION" .PP \fByaz\-marcdump\fR reads MARC records from one or more files\&. It parses each record and supports output in line\-format, ISO2709, \m[blue]\fBMARCXML\fR\m[]\&\s-2\u[1]\d\s+2, \m[blue]\fBMARC\-in\-JSON\fR\m[]\&\s-2\u[2]\d\s+2, \m[blue]\fBMarcXchange\fR\m[]\&\s-2\u[3]\d\s+2 as well as Hex output\&. .PP This utility parses records ISO2709(raw MARC), line format, MARC\-in\-JSON format as well as XML if that is structured as MARCXML/MarcXchange\&. .PP MARC\-in\-JSON encoding/decoding is supported in YAZ 5\&.0\&.5 and later\&. .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBNote\fR .ps -1 .br .PP As of YAZ 2\&.1\&.18, OAI\-MARC is no longer supported\&. OAI\-MARC is deprecated\&. Use MARCXML instead\&. .sp .5v .RE .PP By default, each record is written to standard output in a line format with newline for each field, $x for each sub\-field x\&. The output format may be changed with option \-o, .PP \fByaz\-marcdump\fR can also be requested to perform character set conversion of each record\&. .SH "OPTIONS" .PP \-i \fIformat\fR .RS 4 Specifies input format\&. Must be one of marcxml, marc (ISO2709), marcxchange (ISO25577), line (line mode MARC), turbomarc (Turbo MARC), or json (MARC\-in\-JSON)\&. .RE .PP \-o \fIformat\fR .RS 4 Specifies output format\&. Must be one of marcxml, marc (ISO2709), marcxchange (ISO25577), line (line mode MARC), turbomarc (Turbo MARC), or json (MARC\-in\-JSON)\&. .RE .PP \-f \fIfrom\fR .RS 4 Specify the character set of the input MARC record\&. Should be used in conjunction with option \-t\&. Refer to the yaz\-iconv man page for supported character sets\&. .RE .PP \-t \fIto\fR .RS 4 Specify the character set of the output\&. Should be used in conjunction with option \-f\&. Refer to the yaz\-iconv man page for supported character sets\&. .RE .PP \-l \fIleaderspec\fR .RS 4 Specify a simple modification string for MARC leader\&. The \fIleaderspec\fR is a list of pos=value pairs, where pos is an integer offset (0 \- 23) for leader\&. Value is either a quoted string or an integer (character value in decimal)\&. Pairs are comma separated\&. For example, to set leader at offset 9 to a, use 9=\*(Aqa\*(Aq\&. .RE .PP \-s \fIprefix\fR .RS 4 Writes a chunk of records to a separate file with prefix given, i\&.e\&. splits a record batch into files with only at most "chunk" ISO2709 records per file\&. By default chunk is 1 (one record per file)\&. See option \-C\&. .RE .PP \-C \fIchunksize\fR .RS 4 Specifies chunk size; to be used conjunction with option \-s\&. .RE .PP \-O \fIoffset\fR .RS 4 Integer offset for at what position records whould be written\&. 0=first record, 1=second, \&.\&. With \-L option, this allows a specific range of records to be processed\&. .RE .PP \-L \fIlimit\fR .RS 4 Integer limit for how many records should at most be written\&. With \-O option, this allows a specific range of records to be processed\&. .RE .PP \-p .RS 4 Makes yaz\-marcdump print record number and input file offset of each record read\&. .RE .PP \-n .RS 4 MARC output is omitted so that MARC input is only checked\&. .RE .PP \-r .RS 4 Writes to stderr a summary about number of records read by yaz\-marcdump\&. .RE .PP \-v .RS 4 Writes more information about the parsing process\&. Useful if you have ill\-formatted ISO2709 records as input\&. .RE .PP \-V .RS 4 Prints YAZ version\&. .RE .SH "EXAMPLES" .PP The following command converts MARC21/USMARC in MARC\-8 encoding to MARC21/USMARC in UTF\-8 encoding\&. Leader offset 9 is set to \*(Aqa\*(Aq\&. Both input and output records are ISO2709 encoded\&. .sp .if n \{\ .RS 4 .\} .nf yaz\-marcdump \-f MARC\-8 \-t UTF\-8 \-o marc \-l 9=97 marc21\&.raw >marc21\&.utf8\&.raw .fi .if n \{\ .RE .\} .PP The same records may be converted to MARCXML instead in UTF\-8: .sp .if n \{\ .RS 4 .\} .nf yaz\-marcdump \-f MARC\-8 \-t UTF\-8 \-o marcxml marc21\&.raw >marcxml\&.xml .fi .if n \{\ .RE .\} .PP Turbo MARC is a compact XML notation with same semantics as MARCXML, but which allows for faster processing via XSLT\&. In order to generate Turbo MARC records encoded in UTF\-8 from MARC21 (ISO), one could use: .sp .if n \{\ .RS 4 .\} .nf yaz\-marcdump \-f MARC8 \-t UTF8 \-o turbomarc \-i marc marc21\&.raw >out\&.xml .fi .if n \{\ .RE .\} .sp .SH "FILES" .PP \fIprefix\fR/bin/yaz\-marcdump .PP \fIprefix\fR/include/yaz/marcdisp\&.h .SH "SEE ALSO" .PP \fByaz\fR(7) .PP \fByaz-iconv\fR(1) .SH "AUTHORS" .PP \fBIndex Data\fR .SH "NOTES" .IP " 1." 4 MARCXML .RS 4 \%https://loc.gov/standards/marcxml/ .RE .IP " 2." 4 MARC-in-JSON .RS 4 \%https://rossfsinger.com/blog/2010/09/a-proposal-to-serialize-marc-in-json/ .RE .IP " 3." 4 MarcXchange .RS 4 \%https://loc.gov/standards/iso25577/ .RE yaz-5.37.0/doc/bib1-diagnostics.html0000644000175000017500000003566315130444232015627 0ustar00adamadamAppendix B. Bib-1 diagnostics
Appendix B. Bib-1 diagnostics
Prev   Next

Appendix B. Bib-1 diagnostics

List of Bib-1 diagnostics that are known to YAZ.

CodeText
1 Permanent system error
2 Temporary system error
3 Unsupported search
4 Terms only exclusion (stop) words
5 Too many argument words
6 Too many boolean operators
7 Too many truncated words
8 Too many incomplete subfields
9 Truncated words too short
10 Invalid format for record number (search term)
11 Too many characters in search statement
12 Too many records retrieved
13 Present request out of range
14 System error in presenting records
15 Record no authorized to be sent intersystem
16 Record exceeds Preferred-message-size
17 Record exceeds Maximum-record-size
18 Result set not supported as a search term
19 Only single result set as search term supported
20 Only ANDing of a single result set as search term supported
21 Result set exists and replace indicator off
22 Result set naming not supported
23 Combination of specified databases not supported
24 Element set names not supported
25 Specified element set name not valid for specified database
26 Only a single element set name supported
27 Result set no longer exists - unilaterally deleted by target
28 Result set is in use
29 One of the specified databases is locked
30 Specified result set does not exist
31 Resources exhausted - no results available
32 Resources exhausted - unpredictable partial results available
33 Resources exhausted - valid subset of results available
100 Unspecified error
101 Access-control failure
102 Security challenge required but could not be issued - request terminated
103 Security challenge required but could not be issued - record not included
104 Security challenge failed - record not included
105 Terminated by negative continue response
106 No abstract syntaxes agreed to for this record
107 Query type not supported
108 Malformed query
109 Database unavailable
110 Operator unsupported
111 Too many databases specified
112 Too many result sets created
113 Unsupported attribute type
114 Unsupported Use attribute
115 Unsupported value for Use attribute
116 Use attribute required but not supplied
117 Unsupported Relation attribute
118 Unsupported Structure attribute
119 Unsupported Position attribute
120 Unsupported Truncation attribute
121 Unsupported Attribute Set
122 Unsupported Completeness attribute
123 Unsupported attribute combination
124 Unsupported coded value for term
125 Malformed search term
126 Illegal term value for attribute
127 Unparsable format for un-normalized value
128 Illegal result set name
129 Proximity search of sets not supported
130 Illegal result set in proximity search
131 Unsupported proximity relation
132 Unsupported proximity unit code
201 Proximity not supported with this attribute combination
202 Unsupported distance for proximity
203 Ordered flag not supported for proximity
205 Only zero step size supported for Scan
206 Specified step size not supported for Scan
207 Cannot sort according to sequence
208 No result set name supplied on Sort
209 Generic sort not supported (database-specific sort only supported)
210 Database specific sort not supported
211 Too many sort keys
212 Duplicate sort keys
213 Unsupported missing data action
214 Illegal sort relation
215 Illegal case value
216 Illegal missing data action
217 Segmentation: Cannot guarantee records will fit in specified segments
218 ES: Package name already in use
219 ES: no such package, on modify/delete
220 ES: quota exceeded
221 ES: extended service type not supported
222 ES: permission denied on ES - id not authorized
223 ES: permission denied on ES - cannot modify or delete
224 ES: immediate execution failed
225 ES: immediate execution not supported for this service
226 ES: immediate execution not supported for these parameters
227 No data available in requested record syntax
228 Scan: malformed scan
229 Term type not supported
230 Sort: too many input results
231 Sort: incompatible record formats
232 Scan: term list not supported
233 Scan: unsupported value of position-in-response
234 Too many index terms processed
235 Database does not exist
236 Access to specified database denied
237 Sort: illegal sort
238 Record not available in requested syntax
239 Record syntax not supported
240 Scan: Resources exhausted looking for satisfying terms
241 Scan: Beginning or end of term list
242 Segmentation: max-segment-size too small to segment record
243 Present: additional-ranges parameter not supported
244 Present: comp-spec parameter not supported
245 Type-1 query: restriction ('resultAttr') operand not supported
246 Type-1 query: 'complex' attributeValue not supported
247 Type-1 query: 'attributeSet' as part of AttributeElement not supported
1001 Malformed APDU
1002 ES: EXTERNAL form of Item Order request not supported
1003 ES: Result set item form of Item Order request not supported
1004 ES: Extended services not supported unless access control is in effect
1005 Response records in Search response not supported
1006 Response records in Search response not possible for specified database (or database combination)
1007 No Explain server. Addinfo: pointers to servers that have a surrogate Explain database for this server
1008 ES: missing mandatory parameter for specified function. Addinfo: parameter
1009 ES: Item Order, unsupported OID in itemRequest. Addinfo: OID
1010 Init/AC: Bad Userid
1011 Init/AC: Bad Userid and/or Password
1012 Init/AC: No searches remaining (pre-purchased searches exhausted)
1013 Init/AC: Incorrect interface type (specified id valid only when used with a particular access method or client)
1014 Init/AC: Authentication System error
1015 Init/AC: Maximum number of simultaneous sessions for Userid
1016 Init/AC: Blocked network address
1017 Init/AC: No databases available for specified userId
1018 Init/AC: System temporarily out of resources
1019 Init/AC: System not available due to maintenance
1020 Init/AC: System temporarily unavailable (Addinfo: when it's expected back up)
1021 Init/AC: Account has expired
1022 Init/AC: Password has expired so a new one must be supplied
1023 Init/AC: Password has been changed by an administrator so a new one must be supplied
1024 Unsupported Attribute
1025 Service not supported for this database
1026 Record cannot be opened because it is locked
1027 SQL error
1028 Record deleted
1029 Scan: too many terms requested. Addinfo: max terms supported
1040 ES: Invalid function
1041 ES: Error in retention time
1042 ES: Permissions data not understood
1043 ES: Invalid OID for task specific parameters
1044 ES: Invalid action
1045 ES: Unknown schema
1046 ES: Too many records in package
1047 ES: Invalid wait action
1048 ES: Cannot create task package -- exceeds maximum permissible size
1049 ES: Cannot return task package -- exceeds maximum permissible size
1050 ES: Extended services request too large
1051 Scan: Attribute set id required -- not supplied
1052 ES: Cannot process task package record -- exceeds maximum permissible record size for ES
1053 ES: Cannot return task package record -- exceeds maximum permissible record size for ES response
1054 Init: Required negotiation record not included
1055 Init: negotiation option required
1056 Attribute not supported for database
1057 ES: Unsupported value of task package parameter
1058 Duplicate Detection: Cannot dedup on requested record portion
1059 Duplicate Detection: Requested detection criterion not supported
1060 Duplicate Detection: Requested level of match not supported
1061 Duplicate Detection: Requested regular expression not supported
1062 Duplicate Detection: Cannot do clustering
1063 Duplicate Detection: Retention criterion not supported
1064 Duplicate Detection: Requested number (or percentage) of entries
1065 Duplicate Detection: Requested sort criterion not supported
1066 CompSpec: Unknown schema, or schema not supported.
1067 Encapsulation: Encapsulated sequence of PDUs not supported
1068 Encapsulation: Base operation (and encapsulated PDUs) not executed based on pre-screening analysis
1069 No syntaxes available for this request
1070 user not authorized to receive record(s) in requested syntax
1071 preferredRecordSyntax not supplied
1072 Query term includes characters that do not translate into the target character set
1073 Database records do not contain data associated with access point
1074 Proxy failure
Prev   Next
Appendix A. List of Object Identifiers Home Appendix C. SRU diagnostics
yaz-5.37.0/doc/Makefile.am0000644000175000017500000000723115123757344013656 0ustar00adamadam## This file is part of the YAZ toolkit. ## Copyright (C) Index Data SUBDIRS = common XMLFILES = book.xml \ gfs-options.xml gfs-virtual.xml gfs-synopsis.xml \ std-oid-table.xml bib1-diag-table.xml srw-diag-table.xml \ manref.xml local.ent HTMLFILES = index.html MANFILES=yaz-client.1 yaz-ztest.8 \ yaz-config.1 yaz.7 zoomsh.1 yaz-asncomp.1 \ yaz-marcdump.1 yaz-iconv.1 yaz-log.7 \ yaz-illclient.1 yaz-icu.1 yaz-url.1 bib1-attr.7 \ yaz-json-parse.1 yaz-record-conv.1 REFFILES=yaz-client-man.xml yaz-ztest-man.xml yaz-config-man.xml \ yaz-man.xml zoomsh-man.xml yaz-asncomp-man.xml \ yaz-marcdump-man.xml yaz-iconv-man.xml yaz-log-man.xml \ yaz-illclient-man.xml yaz-icu-man.xml yaz-url-man.xml \ bib1-attr-man.xml yaz-json-parse-man.xml yaz-record-conv-man.xml SUPPORTFILES=entities.ent apilayer.obj doc_DATA = $(HTMLFILES) apilayer.png man_MANS = $(MANFILES) EXTRA_DIST = $(XMLFILES) $(SUPPORTFILES) $(man_MANS) $(REFFILES) \ $(doc_DATA) std-oid-table.xml: $(srcdir)/../src/oid.csv $(TCLSH) $(top_srcdir)/src/oidtoc.tcl $(top_srcdir)/src/oid.csv std-oid-table.xml bib1-diag-table.xml: $(srcdir)/../src/bib1.csv $(TCLSH) $(srcdir)/../src/csvtodiag.tcl $(srcdir)/../src/bib1.csv bib1-diag-table.xml bib1-diag-table srw-diag-table.xml: $(srcdir)/../src/srw.csv $(TCLSH) $(srcdir)/../src/csvtodiag.tcl $(srcdir)/../src/srw.csv srw-diag-table.xml srw-diag-table yaz-client.1: $(srcdir)/yaz-client-man.xml $(MAN_COMPILE) $(srcdir)/yaz-client-man.xml yaz-ztest.8: yaz-ztest-man.xml gfs-options.xml gfs-synopsis.xml gfs-virtual.xml $(MAN_COMPILE) $(srcdir)/yaz-ztest-man.xml yaz-config.1: yaz-config-man.xml $(MAN_COMPILE) $(srcdir)/yaz-config-man.xml yaz.7: yaz-man.xml $(MAN_COMPILE) $(srcdir)/yaz-man.xml bib1-attr.7: bib1-attr-man.xml $(MAN_COMPILE) $(srcdir)/bib1-attr-man.xml zoomsh.1: zoomsh-man.xml $(MAN_COMPILE) $(srcdir)/zoomsh-man.xml yaz-asncomp.1: yaz-asncomp-man.xml $(MAN_COMPILE) $(srcdir)/yaz-asncomp-man.xml yaz-marcdump.1: yaz-marcdump-man.xml $(MAN_COMPILE) $(srcdir)/yaz-marcdump-man.xml yaz-iconv.1: yaz-iconv-man.xml $(MAN_COMPILE) $(srcdir)/yaz-iconv-man.xml yaz-illclient.1: yaz-illclient-man.xml $(MAN_COMPILE) $(srcdir)/yaz-illclient-man.xml yaz-log.7: yaz-log-man.xml $(MAN_COMPILE) $(srcdir)/yaz-log-man.xml yaz-icu.1: yaz-icu-man.xml $(MAN_COMPILE) $(srcdir)/yaz-icu-man.xml yaz-url.1: yaz-url-man.xml $(MAN_COMPILE) $(srcdir)/yaz-url-man.xml yaz-json-parse.1: yaz-json-parse-man.xml $(MAN_COMPILE) $(srcdir)/yaz-json-parse-man.xml yaz-record-conv.1: yaz-record-conv-man.xml $(MAN_COMPILE) $(srcdir)/yaz-record-conv-man.xml $(HTMLFILES): $(XMLFILES) rm -f *.html $(HTML_COMPILE) $(srcdir)/book.xml $(MANFILES): local.ent yaz.pdf: $(XMLFILES) $(PDF_COMPILE) $(srcdir)/book.xml && mv book.pdf yaz.pdf yazj.pdf: jade -E14 -D $(srcdir) -d common/print.dsl -t tex $(srcdir)/common/xml.dcl $(srcdir)/book.xml rm -f yazj.pdf cp book.tex yazj.tex pdfjadetex yazj.tex pdfjadetex yazj.tex >/dev/null pdfjadetex yazj.tex >/dev/null manref.xml: $(REFFILES) $(srcdir)/common/stripref.xsl local.ent rm -f manref.xml for i in $(REFFILES); do \ xsltproc $(srcdir)/common/stripref.xsl $(srcdir)/$$i | sed 1d >>manref.xml; \ done apilayer.png: tgif -print -xbm apilayer.obj xbmtopbm apilayer.png dist-hook: if test -f index.html; then d=.; else d="$(srcdir)"; fi; \ for p in $$d/*.html; do \ cp $$p $(distdir); \ done doc-clean: rm -f manref.xml *.html *.[0-9] *.pdf toc.hhc htmlhelp.hhp install-data-hook: if test -f index.html; then d=.; else d="$(srcdir)"; fi; \ for p in $$d/*.html; do \ $(INSTALL_DATA) $$p $(DESTDIR)$(docdir); \ done uninstall-hook: rm -r $(DESTDIR)$(docdir) distclean-local: doc-clean yaz-5.37.0/configure.ac0000644000175000017500000003266715123757344013356 0ustar00adamadamdnl This file is part of the YAZ toolkit. dnl Copyright (C) Index Data dnl See the file LICENSE for details. AC_PREREQ([2.69]) AC_INIT([yaz],[m4_esyscmd([. ./IDMETA; printf $VERSION])],[info@indexdata.com]) AC_CONFIG_HEADERS([src/config.h]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_AUX_DIR([config]) AM_INIT_AUTOMAKE([1.9 subdir-objects]) dnl AC_DEFINE([_POSIX_C_SOURCE],[200809L],[Enable POSIX]) AC_SUBST([READLINE_LIBS]) AC_SUBST([YAZ_CONF_CFLAGS]) dnl ------ Checking programs AC_PROG_CC AC_PROG_CPP AC_CHECK_PROGS([YACC], ['bison -y']) test -z "$YACC" -a ! -f src/cql.c && AC_MSG_ERROR([GNU Bison not found]) test -z "$YACC" && AC_MSG_WARN([GNU Bison not found]) AC_CHECK_PROGS([TCLSH], [tclsh tclsh8.5 tclsh8.4 tclsh8.3 tclsh8.2], [tclsh]) AC_PROG_INSTALL LT_INIT AM_PROG_CC_C_O AC_PATH_TOOL([PKG_CONFIG],[pkg-config],[NONE]) dnl YAZ_DOC dnl dnl AC_C_BIGENDIAN AC_CHECK_HEADERS([dirent.h fnmatch.h wchar.h locale.h langinfo.h pwd.h \ unistd.h sys/select.h sys/socket.h sys/stat.h sys/time.h \ sys/times.h sys/types.h sys/un.h sys/wait.h sys/prctl.h \ netdb.h arpa/inet.h netinet/tcp.h netinet/in_systm.h \ execinfo.h],[],[],[]) AC_CHECK_HEADERS([net/if.h netinet/in.h netinet/if_ether.h],[],[],[ #if HAVE_SYS_TYPES_H #include #endif #if HAVE_SYS_SOCKET_H #include #endif #if HAVE_NET_IF_H #include #endif #if HAVE_NETINET_IN_H #include #endif ]) dnl ----- Types AC_CHECK_TYPES([long long]) dnl dnl ----- Sockets checkBoth=0 AC_CHECK_FUNC([connect]) if test "$ac_cv_func_connect" = "no"; then AC_CHECK_LIB([socket], [main], [LIBS="$LIBS -lsocket"], [checkBoth=1]) fi if test "$checkBoth" = "1"; then oldLibs=$LIBS LIBS="$LIBS -lsocket -lnsl" AC_CHECK_FUNC([accept], , [LIBS=$oldLibs]) fi AC_CHECK_FUNC([gethostbyname], , [AC_CHECK_LIB([nsl], [main], [LIBS="$LIBS -lnsl"])]) dnl dnl ------ redis hiredis=default AC_SUBST([HIREDIS_LIBS]) AC_ARG_WITH([redis], [ --with-redis hiredis library], [hiredis=$withval]) if test "$hiredis" != "no" -a "$PKG_CONFIG" != "NONE"; then AC_CHECK_LIB([hiredis],[redisCommandArgv],[HIREDIS_LIBS=-lhiredis]) AC_MSG_CHECKING([for redis]) if $PKG_CONFIG --cflags hiredis >/dev/null 2>&1 ; then if $PKG_CONFIG --atleast-version 0.10 hiredis; then AC_MSG_RESULT([yes]) CFLAGS="$CFLAGS `$PKG_CONFIG --cflags hiredis`" HIREDIS_LIBS="`$PKG_CONFIG --libs hiredis`" AC_DEFINE([HAVE_HIREDIS],[1],[Define to 1 if hiredis is enabled]) else AC_MSG_RESULT([no. Version 0.10 required]) if test "$hiredis" != "default"; then AC_MSG_ERROR([hiredis libraries missing]) fi fi else if test "$ac_cv_lib_hiredis_redisCommandArgv" = "yes"; then AC_DEFINE([HAVE_HIREDIS],[1]) AC_MSG_RESULT([yes]) else AC_MSG_RESULT([no]) if test "$hiredis" != "default"; then AC_MSG_ERROR([hiredis libraries missing]) fi fi fi fi dnl ------ memcached memcached=default AC_SUBST([MEMCACHED_LIBS]) AC_ARG_WITH([memcached], [ --with-memcached Memcached library], [memcached=$withval]) if test "$memcached" != "no" -a "$PKG_CONFIG" != "NONE"; then AC_MSG_CHECKING([for libmemcached]) if $PKG_CONFIG --cflags libmemcached >/dev/null 2>&1 ; then if $PKG_CONFIG --atleast-version 0.40 libmemcached; then AC_MSG_RESULT([yes]) CFLAGS="$CFLAGS `$PKG_CONFIG --cflags libmemcached`" MEMCACHED_LIBS="`$PKG_CONFIG --libs libmemcached`" AC_DEFINE([HAVE_LIBMEMCACHED],[1],[Define to 1 if memcached is enabled]) else AC_MSG_RESULT([no. Version 0.40 required]) if test "$memcached" != "default"; then AC_MSG_ERROR([libmemcached libraries missing]) fi fi else AC_MSG_RESULT([no]) if test "$memcached" != "default"; then AC_MSG_ERROR([libmemcached libraries missing]) fi fi fi dnl dnl dnl dnl ------ GNU TLS AC_SUBST([SSL_CFLAGS]) AC_SUBST([SSL_LIBS]) gnutls=default AC_ARG_WITH([gnutls], [ --with-gnutls[=PREFIX] GNU TLS library in PREFIX], [gnutls=$withval]) if test "$gnutls" != "no"; then gnutlsver=no if test "$gnutls" != "yes" -a "$gnutls" != "default"; then if test -x $gnutls/bin/pkg-config; then if $gnutls/bin/pkg-config --exists gnutls; then SSL_CFLAGS=`$gnutls/bin/pkg-config --cflags gnutls` SSL_LIBS="`$gnutls/bin/pkg-config --libs gnutls`" gnutlsver=`$gnutls/bin/pkg-config --modversion gnutls` fi fi else if test "$PKG_CONFIG" != "NONE"; then if $PKG_CONFIG --exists gnutls; then SSL_CFLAGS=`$PKG_CONFIG --cflags gnutls` SSL_LIBS="`$PKG_CONFIG --libs gnutls`" gnutlsver=`$PKG_CONFIG --modversion gnutls` fi fi fi AC_MSG_CHECKING([for GNU TLS]) if test "$gnutlsver" != "no"; then AC_DEFINE([HAVE_GNUTLS_H],[1],[Define to 1 if GNUTLS is present]) AC_MSG_RESULT([$gnutlsver]) else SSL_CFLAGS="" AC_MSG_RESULT([None]) if test "$gnutls" != "default"; then AC_MSG_ERROR([GNU TLS development libraries missing]) fi fi fi dnl dnl ------ GNU Readline READLINE_SHARED_LIBADD="" AC_CHECK_LIB([ncurses],[tgetent],[READLINE_SHARED_LIBADD="-lncurses"], AC_CHECK_LIB([termcap],[tgetent],[READLINE_SHARED_LIBADD="-ltermcap"]) ) READLINE_LIBS="" AC_CHECK_LIB([readline],[readline], [READLINE_LIBS="$READLINE_LIBS -lreadline $READLINE_SHARED_LIBADD"],,[$READLINE_SHARED_LIBADD]) AC_CHECK_LIB([history],[add_history], [READLINE_LIBS="$READLINE_LIBS -lhistory"]) if test "$ac_cv_lib_readline_readline" = "yes"; then AC_CHECK_HEADERS([readline/readline.h readline/history.h]) xLIBS=$LIBS LIBS="$LIBS $READLINE_LIBS" AC_LINK_IFELSE([AC_LANG_PROGRAM([[ #include #include ]], [[ rl_attempted_completion_over = 0; ]])],[AC_DEFINE([HAVE_READLINE_COMPLETION_OVER],[1],[Define to 1 if rl_attempted_completion_over is defined])],[]) AC_LINK_IFELSE([AC_LANG_PROGRAM([[ #include #include ]], [[ rl_completion_matches (0, 0); ]])], [AC_DEFINE([HAVE_READLINE_RL_COMPLETION_MATCHES],1,[Define to 1 if rl_completion_matches is defined])],[]) LIBS=$xLIBS fi dnl ------ iconv AC_ARG_WITH([iconv],[ --with-iconv[=PREFIX] iconv library in PREFIX]) if test "$with_iconv" != "no"; then AC_MSG_CHECKING([for iconv]) oldLIBS="$LIBS" oldCPPFLAGS="${CPPFLAGS}" if test "$with_iconv" != "yes" -a "$with_iconv" != ""; then LIBS="$LIBS -L${with_iconv}/lib" CPPFLAGS="${CPPFLAGS} -I${with_iconv}/include" fi AC_LINK_IFELSE([AC_LANG_PROGRAM([[ #include ]], [[ iconv_t t = iconv_open("", ""); ]])],[ AC_DEFINE([HAVE_ICONV_H],1,[Define to 1 if iconv.h is present]) AC_MSG_RESULT([yes]) ],[ LIBS="$LIBS -liconv" AC_LINK_IFELSE([AC_LANG_PROGRAM([[ #include ]],[[ iconv_t t = iconv_open("", ""); ]])],[ AC_DEFINE([HAVE_ICONV_H],1) AC_MSG_RESULT([yes]) ],[ LIBS="$oldLIBS" CPPFLAGS="$oldCPPFLAGS" AC_MSG_RESULT([no]) ]) ]) fi dnl ------ various functions AC_CHECK_FUNCS([getaddrinfo vsnprintf gettimeofday poll strerror_r localtime_r nanosleep fopen64 open_memstream malloc_info]) if test "$ac_cv_func_getaddrinfo" = "no"; then AC_MSG_ERROR([getaddrinfo required]) fi case $host in *-*-darwin*) trypoll="no"; ;; *) trypoll="yes"; ;; esac if test "$ac_cv_func_poll" = "yes" -a "$trypoll" = "yes"; then AC_CHECK_HEADERS([sys/poll.h]) fi dnl ------ socklen_t dnl We check for socklen_t by making prototypes with the dnl various types. First socklen_t, then size_t, finally int. dnl If the prototype succeeds, we are probably safe. dnl That works if accept is not preprocessor defined (such sa AIX) AC_MSG_CHECKING([for socklen_t]) AC_CACHE_VAL(ac_cv_check_socklen_t,[ac_cv_check_socklen_t='' AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ #include #include #ifdef __cplusplus extern "C" { #endif #define try 1 #ifdef AIX #if AIX >= 51 #define try 0 #endif #endif #if try extern int accept(int, struct sockaddr *, socklen_t *); #endif #ifdef __cplusplus } #endif ]], [[]])],[ac_cv_check_socklen_t=socklen_t],[ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ #include #include #ifdef __cplusplus extern "C" { #endif #define try 1 #ifdef AIX #if AIX >= 42 #define try 0 #endif #endif #if try extern int accept(int, struct sockaddr *, size_t t *); #endif #ifdef __cplusplus } #endif ]],[[]])],[ac_cv_check_socklen_t=size_t],[ac_cv_check_socklen_t=int]) ]) ]) AC_MSG_RESULT([$ac_cv_check_socklen_t]) AC_DEFINE_UNQUOTED([YAZ_SOCKLEN_T],[$ac_cv_check_socklen_t],[socklen_t type]) dnl dnl ------ tcpd AC_ARG_ENABLE([tcpd], [ --enable-tcpd[=PREFIX] enable TCP wrapper for server if available]) if test "$enable_tcpd" -a "$enable_tcpd" != "no"; then oldLibs=$LIBS oldCPPFLAGS=$CPPFLAGS if test "$enable_tcpd" != "yes"; then LIBS="$LIBS -L$enable_tcpd/lib" CPPFLAGS="$CPPFLAGS -I$enable_tcpd/include" fi AC_MSG_CHECKING([for working tcpd.h]) LIBS="$LIBS -lwrap" AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include #include int allow_severity = LOG_INFO; int deny_severity = LOG_WARNING;]], [[struct request_info request_info; int i; i = hosts_access(&request_info);]])],[tcpd_ok=1],[tcpd_ok=0]) LIBS=$oldLibs if test "$tcpd_ok" = "0"; then AC_MSG_RESULT([no]) AC_MSG_ERROR([tcpd development libraries missing]) CPPFLAGS=$oldCPPFLAGS else TCPD_LIBS="-lwrap" AC_MSG_RESULT([yes]) AC_DEFINE([HAVE_TCPD_H], 1, [Define to 1 if tcp wrap library is present]) fi fi AC_SUBST([TCPD_LIBS]) dnl AC_SUBST([YAZ_CONFIG_CFLAGS]) dnl dnl ------ POSIX Threads HAVETHREADS=0 AC_ARG_ENABLE([threads], [ --disable-threads disable POSIX threads],[enable_threads=$enableval],[enable_threads=yes]) if test "$enable_threads" = "yes" -a "$HAVETHREADS" = "0"; then ACX_PTHREAD([ OCFLAGS=$CFLAGS CFLAGS="$CFLAGS $PTHREAD_CFLAGS" dnl unfortunately empty thread lib spec is problematic because dnl 'yaz-config --cflags' is not always passed to linker in dnl applications using YAZ (such as Zebra). if test "x$PTHREAD_LIBS" = "x"; then OLIBS=$LIBS for lib in -lpthread -lpthreads -lc_r; do LIBS="$lib $OLIBS" AC_LINK_IFELSE([AC_LANG_PROGRAM([[ #include ]], [[ pthread_t id; pthread_join(id, 0); ]])], [ PTHREAD_LIBS=$lib; break ],[]) done LIBS=$OLIBS fi LIBS="$LIBS $PTHREAD_LIBS" AC_DEFINE([YAZ_POSIX_THREADS], [1], [Define to 1 if POSIX threads is present]) YAZ_CONFIG_CFLAGS="$YAZ_CONFIG_CFLAGS -DYAZ_POSIX_THREADS=1" ]) fi dnl ----- libXSLT/libEXLT/libXML2 AC_SUBST([XML2_CFLAGS]) xml_enabled=false YAZ_LIBXML2([ AC_DEFINE([YAZ_HAVE_XML2], [1], [Define to 1 if Libxml2 is present]) YAZ_CONFIG_CFLAGS="$YAZ_CONFIG_CFLAGS -DYAZ_HAVE_XML2=1" xml_enabled=true ]) if test "$xml_enabled" = "true"; then YAZ_LIBXSLT([ AC_DEFINE([YAZ_HAVE_XSLT], [1], [Define to 1 if Libxslt is present]) YAZ_CONFIG_CFLAGS="$YAZ_CONFIG_CFLAGS -DYAZ_HAVE_XSLT=1" ]) YAZ_LIBEXSLT([ AC_DEFINE([YAZ_HAVE_EXSLT], [1], [Define to 1 if EXSLT is present]) YAZ_CONFIG_CFLAGS="$YAZ_CONFIG_CFLAGS -DYAZ_HAVE_EXSLT=1" ]) fi YAZ_CONFIG_CFLAGS="$YAZ_CONFIG_CFLAGS $XML2_CFLAGS" if test "$XML2_LIBS"; then LIBS="$XML2_LIBS $LIBS" fi dnl dnl AC_CHECK_ICU([3.4],[ if test "$xml_enabled" = "true"; then ICU_CPPFLAGS="$ICU_CPPFLAGS -DYAZ_HAVE_ICU=1" else ICU_CPPFLAGS="" AC_MSG_WARN([ICU support disabled because XML support is unavailable]) fi ]) dnl ------ versioning dnl WIN_FILEVERSION=`echo $PACKAGE_VERSION | $AWK 'BEGIN { FS = "."; } { m = $4; printf("%d,%d,%d,%d", $1, $2, $3 == "" ? "0" : $3, $4 == "" ? "1" : $4);}'` AC_SUBST([WIN_FILEVERSION]) VERSION_HEX=`echo $PACKAGE_VERSION | $AWK 'BEGIN { FS = "."; } { printf("%x", ($1 * 256 + $2) * 256 + $3);}'` AC_SUBST([VERSION_HEX]) if test -d ${srcdir}/.git; then VERSION_SHA1=`git show --pretty=format:%H|head -1` else VERSION_SHA1=`head -1 ${srcdir}/ChangeLog|awk '{print $2}'` fi AC_SUBST([VERSION_SHA1]) dnl dnl ------ Makefiles dnl AC_CONFIG_FILES([ Makefile src/Makefile test/Makefile util/Makefile client/Makefile ztest/Makefile zoom/Makefile doc/Makefile doc/local0.ent doc/common/Makefile doc/common/print.dsl etc/Makefile yaz-config yaz.pc yaz-icu.pc yaz-server.pc Doxyfile win/version.nsi src/yaz/yaz-version.h ]) AC_CONFIG_COMMANDS([default],[ sed -e 's%echo_source=yes%echo_source=no%g; s%src_root=.*$%%g; s%build_root=.*%%g' \ < yaz-config > src/yaz-config && chmod +x yaz-config src/yaz-config diff doc/local.ent doc/local0.ent >/dev/null 2>/dev/null \ || cp doc/local0.ent doc/local.ent ],[]) AC_OUTPUT echo \ "------------------------------------------------------------------------ Configuration: YAZ Package: ${PACKAGE} YAZ Version: ${VERSION} Bugreport: ${PACKAGE_BUGREPORT} Source code location: ${srcdir} C Preprocessor: ${CPP} C Preprocessor flags: ${CPPFLAGS} C Compiler: ${CC} C Compiler flags: ${CFLAGS} Linker flags: ${LDFLAGS} Linked libs: ${LIBS} Host System Type: ${host} Install path: ${prefix} Automake: ${AUTOMAKE} Archiver: ${AR} Ranlib: ${RANLIB} ------------------------------------------------------------------------" dnl Local Variables: dnl mode:shell-script dnl sh-indentation: 2 dnl sh-basic-offset: 4 dnl End: yaz-5.37.0/zoom/0000755000175000017500000000000015130444224012022 5ustar00adamadamyaz-5.37.0/zoom/zoom-benchmark.c0000644000175000017500000002707515123757344015131 0ustar00adamadam/* This file is part of the YAZ toolkit. * Copyright (C) Index Data * See the file LICENSE for details. */ #if HAVE_CONFIG_H #include #endif #include #include #include #include #include #include #include /* naming events */ static char* zoom_events[ZOOM_EVENT_MAX+1]; /* re-sorting event numbers to progress numbers */ static int zoom_progress[ZOOM_EVENT_MAX+1]; /* commando line parameters */ static struct parameters_t { char host[1024]; char query[1024]; int progress[4096]; int concurrent; int repeat; int timeout; char proxy[1024]; int piggypack; int gnuplot; } parameters; struct event_line_t { int connection; long time_sec; long time_usec; int progress; int event; char zoom_event[128]; int error; char errmsg[128]; }; void print_event_line(struct event_line_t *pel) { printf ("%d\t%ld.%06ld\t%d\t%d\t%s\t%d\t%s\n", pel->connection, pel->time_sec, pel->time_usec, pel->progress, pel->event, pel->zoom_event, pel->error, pel->errmsg); } void update_events(int *elc, struct event_line_t *els, int repeat, int conn, long sec, long usec, int prog, int event, const char * eventmsg, int error, const char * errmsg){ int ielc = repeat*parameters.concurrent + conn; int iels = repeat*parameters.concurrent*10 + conn*10 + elc[ielc]; els[iels].connection = conn; els[iels].time_sec = sec; els[iels].time_usec = usec; els[iels].progress = prog; els[iels].event = event; if (eventmsg) strcpy(els[iels].zoom_event, eventmsg); else strcpy(els[iels].zoom_event, "---"); els[iels].error = error; strcpy(els[iels].errmsg, errmsg); /* print_event_line(&els[iels]); */ elc[ielc] += 1; } void print_events(int *elc, struct event_line_t *els, int connections){ int i; int j; int k; int ielc; int iels; for (k=0; k < parameters.repeat; k++){ for (i=0; i < connections; i++){ ielc = k * parameters.concurrent + i; for (j=0; j < elc[ielc]; j++){ iels = k * parameters.concurrent * 10 + i * 10 + j; print_event_line(&els[iels]); } printf("\n"); } printf("\n"); } } void init_statics(void) { int i; char nullstring[1] = ""; /* naming events */ zoom_events[ZOOM_EVENT_NONE] = "ZOOM_EVENT_NONE"; zoom_events[ZOOM_EVENT_CONNECT] = "ZOOM_EVENT_CONNECT"; zoom_events[ZOOM_EVENT_SEND_DATA] = "ZOOM_EVENT_SEND_DATA"; zoom_events[ZOOM_EVENT_RECV_DATA] = "ZOOM_EVENT_RECV_DATA"; zoom_events[ZOOM_EVENT_TIMEOUT] = "ZOOM_EVENT_TIMEOUT"; zoom_events[ZOOM_EVENT_UNKNOWN] = "ZOOM_EVENT_UNKNOWN"; zoom_events[ZOOM_EVENT_SEND_APDU] = "ZOOM_EVENT_SEND_APDU"; zoom_events[ZOOM_EVENT_RECV_APDU] = "ZOOM_EVENT_RECV_APDU"; zoom_events[ZOOM_EVENT_RECV_RECORD] = "ZOOM_EVENT_RECV_RECORD"; zoom_events[ZOOM_EVENT_RECV_SEARCH] = "ZOOM_EVENT_RECV_SEARCH"; zoom_events[ZOOM_EVENT_END] = "ZOOM_EVENT_END"; /* re-sorting event numbers to progress numbers */ zoom_progress[ZOOM_EVENT_NONE] = 0; zoom_progress[ZOOM_EVENT_CONNECT] = 1; zoom_progress[ZOOM_EVENT_SEND_DATA] = 3; zoom_progress[ZOOM_EVENT_RECV_DATA] = 4; zoom_progress[ZOOM_EVENT_TIMEOUT] = 9; zoom_progress[ZOOM_EVENT_UNKNOWN] = 10; zoom_progress[ZOOM_EVENT_SEND_APDU] = 2; zoom_progress[ZOOM_EVENT_RECV_APDU] = 5; zoom_progress[ZOOM_EVENT_RECV_RECORD] = 7; zoom_progress[ZOOM_EVENT_RECV_SEARCH] = 6; zoom_progress[ZOOM_EVENT_END] = 8; /* parameters */ parameters.concurrent = 1; parameters.timeout = 0; parameters.repeat = 1; strcpy(parameters.proxy, nullstring); parameters.gnuplot = 0; parameters.piggypack = 0; /* progress initializing */ for (i = 0; i < 4096; i++){ parameters.progress[i] = 0; } } struct time_type { struct timeval now; struct timeval then; long sec; long usec; }; void time_init(struct time_type *ptime) { gettimeofday(&(ptime->now), 0); gettimeofday(&(ptime->then), 0); ptime->sec = 0; ptime->usec = 0; } void time_stamp(struct time_type *ptime) { gettimeofday(&(ptime->now), 0); ptime->sec = ptime->now.tv_sec - ptime->then.tv_sec; ptime->usec = ptime->now.tv_usec - ptime->then.tv_usec; if (ptime->usec < 0){ ptime->sec--; ptime->usec += 1000000; } } long time_sec(struct time_type *ptime) { return ptime->sec; } long time_usec(struct time_type *ptime) { return ptime->usec; } void print_option_error(void) { fprintf(stderr, "zoom-benchmark: Call error\n"); fprintf(stderr, "zoom-benchmark -h host:port -q pqf-query " "[-c no_concurrent (max 4096)] " "[-n no_repeat] " "[-b (piggypack)] " "[-g (gnuplot outfile)] " "[-p proxy] \n"); /* "[-t timeout] \n"); */ exit(1); } void read_params(int argc, char **argv, struct parameters_t *p_parameters){ char *arg; int ret; while ((ret = options("h:q:c:t:p:bgn:", argv, argc, &arg)) != -2) { switch (ret) { case 'h': strcpy(p_parameters->host, arg); break; case 'q': strcpy(p_parameters->query, arg); break; case 'p': strcpy(p_parameters->proxy, arg); break; case 'c': p_parameters->concurrent = atoi(arg); break; #if 0 case 't': p_parameters->timeout = atoi(arg); break; #endif case 'b': p_parameters->piggypack = 1; break; case 'g': p_parameters->gnuplot = 1; break; case 'n': p_parameters->repeat = atoi(arg); break; case 0: print_option_error(); break; default: print_option_error(); } } if(0){ printf("zoom-benchmark\n"); printf(" host: %s \n", p_parameters->host); printf(" query: %s \n", p_parameters->query); printf(" concurrent: %d \n", p_parameters->concurrent); printf(" repeat: %d \n", p_parameters->repeat); #if 0 printf(" timeout: %d \n", p_parameters->timeout); #endif printf(" proxy: %s \n", p_parameters->proxy); printf(" piggypack: %d \n\n", p_parameters->piggypack); printf(" gnuplot: %d \n\n", p_parameters->gnuplot); } if (! strlen(p_parameters->host)) print_option_error(); if (! strlen(p_parameters->query)) print_option_error(); if (! (p_parameters->concurrent > 0)) print_option_error(); if (! (p_parameters->repeat > 0)) print_option_error(); if (! (p_parameters->timeout >= 0)) print_option_error(); if (! ( p_parameters->concurrent <= 4096)) print_option_error(); } void print_table_header(void) { if (parameters.gnuplot) printf("#"); printf ("target\tsecond.usec\tprogress\tevent\teventname\t"); printf("error\terrorname\n"); } int main(int argc, char **argv) { struct time_type time; ZOOM_connection *z; ZOOM_resultset *r; int *elc; struct event_line_t *els; ZOOM_options o; int i; int k; init_statics(); read_params(argc, argv, ¶meters); z = (ZOOM_connection *) xmalloc(sizeof(*z) * parameters.concurrent); r = (ZOOM_resultset *) xmalloc(sizeof(*r) * parameters.concurrent); elc = (int *) xmalloc(sizeof(*elc) * parameters.concurrent * parameters.repeat); els = (struct event_line_t *) xmalloc( sizeof(*els) * parameters.concurrent * parameters.repeat * 10); o = ZOOM_options_create(); /* async mode */ ZOOM_options_set (o, "async", "1"); /* get first record of result set (using piggypack) */ if (parameters.piggypack) ZOOM_options_set (o, "count", "1"); /* set proxy */ if (strlen(parameters.proxy)) ZOOM_options_set (o, "proxy", parameters.proxy); /* preferred record syntax */ if (0){ ZOOM_options_set (o, "preferredRecordSyntax", "usmarc"); ZOOM_options_set (o, "elementSetName", "F"); } time_init(&time); /* repeat loop */ for (k = 0; k < parameters.repeat; k++){ /* progress zeroing */ for (i = 0; i < 4096; i++){ parameters.progress[i] = k * 5 -1; } /* connect to all concurrent connections*/ for ( i = 0; i < parameters.concurrent; i++){ /* set event count to zero */ elc[k * parameters.concurrent + i] = 0; /* create connection - pass options (they are the same for all) */ z[i] = ZOOM_connection_create(o); /* connect and init */ ZOOM_connection_connect(z[i], parameters.host, 0); } /* search all */ for (i = 0; i < parameters.concurrent; i++) r[i] = ZOOM_connection_search_pqf (z[i], parameters.query); /* network I/O. pass number of connections and array of connections */ while ((i = ZOOM_event (parameters.concurrent, z))){ int event = ZOOM_connection_last_event(z[i-1]); const char *errmsg; const char *addinfo; int error = 0; if (event == ZOOM_EVENT_SEND_DATA || event == ZOOM_EVENT_RECV_DATA) continue; time_stamp(&time); error = ZOOM_connection_error(z[i-1] , &errmsg, &addinfo); if (error) parameters.progress[i] = zoom_progress[ZOOM_EVENT_UNKNOWN]; else if (event == ZOOM_EVENT_CONNECT) parameters.progress[i] = zoom_progress[event]; else parameters.progress[i] += 1; update_events(elc, els, k, i-1, time_sec(&time), time_usec(&time), parameters.progress[i], event, zoom_events[event], error, errmsg); } /* destroy connections */ for (i = 0; i #include #include #include #include #include #include #include int main(int argc, char **argv) { ZOOM_connection z; ZOOM_options o = ZOOM_options_create (); const char *errmsg, *addinfo; if (argc != 4) { fprintf (stderr, "usage:\nzoom-ka sleepinterval target query\n"); exit(1); } /* async mode */ ZOOM_options_set (o, "async", "1"); z = ZOOM_connection_create(o); while(1) { int i, error; ZOOM_resultset rset; ZOOM_connection_connect (z, argv[2], 0); rset = ZOOM_connection_search_pqf(z, argv[3]); while ((i = ZOOM_event(1, &z))) { printf ("no = %d event = %d\n", i-1, ZOOM_connection_last_event(z)); } if ((error = ZOOM_connection_error(z, &errmsg, &addinfo))) { fprintf(stderr, "%s error: %s (%d) %s\n", ZOOM_connection_option_get(z, "host"), errmsg, error, addinfo); } ZOOM_resultset_destroy(rset); sleep(atoi(argv[1])); } ZOOM_connection_destroy (z); ZOOM_options_destroy(o); } /* * Local variables: * c-basic-offset: 4 * c-file-style: "Stroustrup" * indent-tabs-mode: nil * End: * vim: shiftwidth=4 tabstop=8 expandtab */ yaz-5.37.0/zoom/zoomsh.c0000644000175000017500000007132115130443476013521 0ustar00adamadam/* This file is part of the YAZ toolkit. * Copyright (C) Index Data * See the file LICENSE for details. */ /** \file zoomsh.c \brief ZOOM C command line tool (shell) */ #if HAVE_CONFIG_H #include #endif #if HAVE_UNISTD_H #include #endif #include #include #include #include #include #include #include #include #if HAVE_READLINE_READLINE_H #include #endif #if HAVE_READLINE_HISTORY_H #include #endif #include #include struct zoom_sh { WRBUF strategy; WRBUF criteria; ZOOM_options options; struct zoom_db *list; }; struct zoom_db { ZOOM_connection con; ZOOM_resultset res; struct zoom_db *next; }; #define MAX_CON 100 static void process_events(struct zoom_sh *sh) { ZOOM_connection *c; int i, number; struct zoom_db *db; for (number = 0, db = sh->list; db; db = db->next) if (db->con) number++; c = xmalloc(sizeof(*c) * number); for (i = 0, db = sh->list; db; db = db->next) if (db->con) c[i++] = db->con; yaz_log(YLOG_DEBUG, "process_events"); while ((i = ZOOM_event(number, c)) != 0) { int peek = ZOOM_connection_peek_event(c[i-1]); int event = ZOOM_connection_last_event(c[i-1]); yaz_log(YLOG_DEBUG, "no = %d peek = %d event = %d %s", i-1, peek, event, ZOOM_get_event_str(event)); } xfree(c); } static int next_token_chars(const char **cpp, const char **t_start, const char *tok_chars) { int len = 0; const char *cp = *cpp; while (*cp == ' ') cp++; if (*cp == '"') { cp++; *t_start = cp; while (*cp && *cp != '"') { cp++; len++; } if (*cp) cp++; } else { *t_start = cp; while (*cp && !strchr(tok_chars, *cp)) { cp++; len++; } if (len == 0) len = -1; } *cpp = cp; return len; /* return -1 if no token was read .. */ } static int next_token(const char **cpp, const char **t_start) { return next_token_chars(cpp, t_start, "\r\n "); } static WRBUF next_token_new_wrbuf(const char **cpp) { WRBUF w = 0; const char *start; int len = next_token(cpp, &start); if (len < 0) return 0; w = wrbuf_alloc(); if (len > 0) wrbuf_write(w, start, len); return w; } static int is_command(const char *cmd_str, const char *this_str, int this_len) { int cmd_len = strlen(cmd_str); if (cmd_len != this_len) return 0; if (memcmp(cmd_str, this_str, cmd_len)) return 0; return 1; } static int cmd_fset(struct zoom_sh *sh, const char **args) { WRBUF key, fname = 0; FILE *inf = 0; int ret = -1; long fsize = 0; char *b = 0; if (!(key = next_token_new_wrbuf(args))) { printf("missing argument for set\n"); return 1; } fname = next_token_new_wrbuf(args); if (!fname) { printf("Missing arg for fset %s\n", wrbuf_cstr(key)); } else if ((inf = fopen(wrbuf_cstr(fname), "rb")) == 0) { printf("Could not open %s\n", wrbuf_cstr(fname)); } else if (fseek(inf, 0L, SEEK_END) == -1 || (fsize = ftell(inf)) == -1L) { printf("Couldn't seek in %s\n", wrbuf_cstr(fname)); } else if (fseek(inf, 0L, SEEK_SET) == -1) { printf("Couldn't seek in %s\n", wrbuf_cstr(fname)); } else if ((b = malloc(fsize + 1)) == 0) { printf("Couldn't allocate %ld bytes for %s\n", fsize, wrbuf_cstr(fname)); } else if (fsize > 0 && fread(b, 1, fsize, inf) != fsize) { printf("Couldn't read %ld bytes for %s\n", fsize, wrbuf_cstr(fname)); } else { ZOOM_options_setl(sh->options, wrbuf_cstr(key), b, fsize); ret = 0; } if (inf) fclose(inf); if (fname) wrbuf_destroy(fname); wrbuf_destroy(key); free(b); return ret; } static int cmd_set(struct zoom_sh *sh, const char **args) { WRBUF key; const char *val_buf; int val_len; if (!(key = next_token_new_wrbuf(args))) { printf("missing argument for set\n"); return 1; } val_len = next_token_chars(args, &val_buf, ""); if (val_len != -1) ZOOM_options_setl(sh->options, wrbuf_cstr(key), val_buf, val_len); else ZOOM_options_set(sh->options, wrbuf_cstr(key), 0); wrbuf_destroy(key); return 0; } static int cmd_get(struct zoom_sh *sh, const char **args) { WRBUF key; if (!(key = next_token_new_wrbuf(args))) { printf("missing argument for get\n"); return 1; } else { const char *val = ZOOM_options_get(sh->options, wrbuf_cstr(key)); printf("%s = %s\n", wrbuf_cstr(key), val ? val : ""); wrbuf_destroy(key); } return 0; } static int cmd_shell(struct zoom_sh *sh, const char **args) { int ret = system(*args); if (ret) printf("system command returned %d\n", ret); return 0; } static int cmd_rget(struct zoom_sh *sh, const char **args) { WRBUF key; if (!(key = next_token_new_wrbuf(args))) { printf("missing argument for get\n"); return 1; } else { struct zoom_db *db = sh->list; for (; db; db = db->next) { if (db->res) { const char *val = ZOOM_resultset_option_get(db->res, wrbuf_cstr(key)); printf("%s = %s\n", wrbuf_cstr(key), val ? val : ""); } } wrbuf_destroy(key); } return 0; } static int cmd_close(struct zoom_sh *sh, const char **args) { struct zoom_db **dbp; WRBUF host; host = next_token_new_wrbuf(args); for (dbp = &sh->list; *dbp; ) { const char *h; struct zoom_db *db = *dbp; if (!db->con || !host || ((h = ZOOM_connection_option_get(db->con, "host")) && !strcmp(h, wrbuf_cstr(host)))) { *dbp = (*dbp)->next; ZOOM_connection_destroy(db->con); ZOOM_resultset_destroy(db->res); xfree(db); } else dbp = &(*dbp)->next; } if (host) wrbuf_destroy(host); return 0; } static void display_records(ZOOM_connection c, ZOOM_resultset r, size_t start, size_t count, const char *type) { size_t i; for (i = 0; i < count; i++) { size_t pos = i + start; ZOOM_record rec = ZOOM_resultset_record(r, pos); const char *db = ZOOM_record_get(rec, "database", 0); if (ZOOM_record_error(rec, 0, 0, 0)) { const char *msg; const char *addinfo; const char *diagset; int error = ZOOM_record_error(rec, &msg, &addinfo, &diagset); printf("%lld %s: %s (%s:%d) %s\n", (long long) pos, (db ? db : "unknown"), msg, diagset, error, addinfo ? addinfo : "none"); } else { int len; const char *render = ZOOM_record_get(rec, type, &len); const char *syntax = ZOOM_record_get(rec, "syntax", 0); const char *schema = ZOOM_record_get(rec, "schema", 0); /* if rec is non-null, we got a record for display */ if (rec) { printf("%lld database=%s syntax=%s schema=%s\n", (long long) pos, (db ? db : "unknown"), syntax, schema ? schema : "unknown"); if (render) { if (fwrite(render, 1, len, stdout) != (size_t) len) { printf("write to stdout failed\n"); } } printf("\n"); } } } } static int cmd_show(struct zoom_sh *sh, const char **args) { size_t start = 0, count = 1; const char *type = "render"; WRBUF render_str = 0; int ret = 0; struct zoom_db *db; { WRBUF tmp; if ((tmp = next_token_new_wrbuf(args))) { start = atoi(wrbuf_cstr(tmp)); wrbuf_destroy(tmp); } if ((tmp = next_token_new_wrbuf(args))) { count = atoi(wrbuf_cstr(tmp)); wrbuf_destroy(tmp); } render_str = next_token_new_wrbuf(args); } if (render_str) type = wrbuf_cstr(render_str); for (db = sh->list; db; db = db->next) if (db->res) ZOOM_resultset_records(db->res, 0, start, count); process_events(sh); for (db = sh->list; db; db = db->next) { int error; const char *errmsg, *addinfo, *dset; /* display errors if any */ if (!db->con) continue; if ((error = ZOOM_connection_error_x(db->con, &errmsg, &addinfo, &dset))) { printf("%s error: %s (%s:%d) %s\n", ZOOM_connection_option_get(db->con, "host"), errmsg, dset, error, addinfo); ret = 1; } else if (db->res) { /* OK, no major errors. Display records... */ display_records(db->con, db->res, start, count, type); } } if (render_str) wrbuf_destroy(render_str); return ret; } static void display_facets(ZOOM_facet_field *facets, int count) { int i; printf("Facets: \n"); for (i = 0; i < count; i++) { int j; const char *facet_name = ZOOM_facet_field_name(facets[i]); printf(" %s: \n", facet_name); for (j = 0; j < ZOOM_facet_field_term_count(facets[i]); j++) { int freq = 0; const char *term = ZOOM_facet_field_get_term(facets[i], j, &freq); printf(" %s(%d) \n", term, freq); } } } static int cmd_facets(struct zoom_sh *sh, const char **args) { struct zoom_db *db; int ret = 0; process_events(sh); for (db = sh->list; db; db = db->next) { int error; const char *errmsg, *addinfo, *dset; /* display errors if any */ if (!db->con) continue; if ((error = ZOOM_connection_error_x(db->con, &errmsg, &addinfo, &dset))) { printf("%s error: %s (%s:%d) %s\n", ZOOM_connection_option_get(db->con, "host"), errmsg, dset, error, addinfo); ret = 1; } else if (db->res) { int num_facets = ZOOM_resultset_facets_size(db->res); if (num_facets) { ZOOM_facet_field *facets = ZOOM_resultset_facets(db->res); display_facets(facets, num_facets); } } } return ret; } static int cmd_suggestions(struct zoom_sh *sh, const char **args) { struct zoom_db *db; int ret = 0; process_events(sh); for (db = sh->list; db; db = db->next) { int error; const char *errmsg, *addinfo, *dset; /* display errors if any */ if (!db->con) continue; if ((error = ZOOM_connection_error_x(db->con, &errmsg, &addinfo, &dset))) { printf("%s error: %s (%s:%d) %s\n", ZOOM_connection_option_get(db->con, "host"), errmsg, dset, error, addinfo); ret = 1; } else if (db->res) { const char *suggestions = ZOOM_resultset_option_get(db->res, "suggestions"); if (suggestions) printf("Suggestions: \n%s\n", suggestions); } } return ret; } static int cmd_ext(struct zoom_sh *sh, const char **args) { int ret = 0; ZOOM_package *p = 0; struct zoom_db *db; int i, number; WRBUF ext_type_str = next_token_new_wrbuf(args); if (!ext_type_str) { printf("es: missing type " "(itemorder, create, drop, commit, update, xmlupdate)\n"); return 1; } for (number = 0, db = sh->list; db; db = db->next) if (db->con) number++; p = xmalloc(sizeof(*p) * number); for (i = 0, db = sh->list; db; db = db->next) if (db->con) { p[i] = ZOOM_connection_package(db->con, 0); ZOOM_package_send(p[i], ext_type_str ? wrbuf_cstr(ext_type_str):0); i++; } process_events(sh); for (i = 0, db = sh->list; db; db = db->next) { int error; const char *errmsg, *addinfo, *dset; /* display errors if any */ if (!db->con) continue; if ((error = ZOOM_connection_error_x(db->con, &errmsg, &addinfo, &dset))) { printf("%s error: %s (%s:%d) %s\n", ZOOM_connection_option_get(db->con, "host"), errmsg, dset, error, addinfo); ret = 1; } else if (p[i]) { const char *v; printf("ok\n"); v = ZOOM_package_option_get(p[i], "targetReference"); if (v) printf("targetReference: %s\n", v); v = ZOOM_package_option_get(p[i], "xmlUpdateDoc"); if (v) printf("xmlUpdateDoc: %s\n", v); v = ZOOM_package_option_get(p[i], "operationStatus"); if (v) printf("operationStatus: %s\n", v); v = ZOOM_package_option_get(p[i], "taskStatus"); if (v) printf("taskStatus: %s\n", v); v = ZOOM_package_option_get(p[i], "esError"); if (v) printf("esError: %s\n", v); v = ZOOM_package_option_get(p[i], "esAddinfo"); if (v) printf("esAddinfo: %s\n", v); } ZOOM_package_destroy(p[i]); i++; } if (ext_type_str) wrbuf_destroy(ext_type_str); xfree(p); return ret; } static int cmd_debug(struct zoom_sh *sh, const char **args) { yaz_log_init_level(YLOG_ALL); return 0; } static void display_search_result(struct zoom_db *db) { const char *v; int num; v = ZOOM_resultset_option_get(db->res, "searchresult.size"); if (v && (num = atoi(v))) { int i; printf("SearchResult-1:"); for (i = 0; i < num; i++) { const char *v; char str[60]; if (i) printf(","); yaz_snprintf(str, sizeof str, "searchresult.%d.id", i); v = ZOOM_resultset_option_get(db->res, str); if (v) printf(" id=%s", v); yaz_snprintf(str, sizeof str, "searchresult.%d.subquery.term", i); v = ZOOM_resultset_option_get(db->res, str); if (v) printf(" term=%s", v); yaz_snprintf(str, sizeof str, "searchresult.%d.count", i); v = ZOOM_resultset_option_get(db->res, str); if (v) printf(" cnt=%s", v); } printf("\n"); } } static int cmd_search(struct zoom_sh *sh, const char **args) { ZOOM_query s; const char *query_str = *args; int ret = 0; struct zoom_db *db; s = ZOOM_query_create(); while (*query_str == ' ') query_str++; if (memcmp(query_str, "cql:", 4) == 0) { ZOOM_query_cql(s, query_str + 4); } else if (ZOOM_query_prefix(s, query_str)) { printf("Bad PQF: %s\n", query_str); ZOOM_query_destroy(s); return 1; } if (sh->strategy && wrbuf_len(sh->strategy) && wrbuf_len(sh->criteria)) { int r = ZOOM_query_sortby2(s, wrbuf_cstr(sh->strategy), wrbuf_cstr(sh->criteria)); if (r) { if (r == -1) printf("Bad sortby strategy: %s\n", wrbuf_cstr(sh->strategy)); else printf("Bad sortby criteria: %s\n", wrbuf_cstr(sh->criteria)); ZOOM_query_destroy(s); return 1; } printf("sortby added\n"); } for (db = sh->list; db; db = db->next) { if (db->con) { ZOOM_resultset_destroy(db->res); db->res = ZOOM_connection_search(db->con, s); } } ZOOM_query_destroy(s); process_events(sh); for (db = sh->list; db; db = db->next) { int error; const char *errmsg, *addinfo, *dset; /* display errors if any */ if (!db->con) continue; if ((error = ZOOM_connection_error_x(db->con, &errmsg, &addinfo, &dset))) { printf("%s error: %s (%s:%d) %s\n", ZOOM_connection_option_get(db->con, "host"), errmsg, dset, error, addinfo); ret = 1; } else if (db->res) { /* OK, no major errors. Look at the result count */ int start = ZOOM_options_get_int(sh->options, "start", 0); int count = ZOOM_options_get_int(sh->options, "count", 0); int facet_num; printf("%s: %lld hits\n", ZOOM_connection_option_get(db->con, "host"), (long long int) ZOOM_resultset_size(db->res)); facet_num = ZOOM_resultset_facets_size(db->res); if (facet_num) { ZOOM_facet_field *facets = ZOOM_resultset_facets(db->res); int facet_idx; for (facet_idx = 0; facet_idx < facet_num; facet_idx++) { const char *name = ZOOM_facet_field_name(facets[facet_idx]); size_t term_idx; size_t term_num = ZOOM_facet_field_term_count(facets[facet_idx]); printf("facet: %s\n", name); for (term_idx = 0; term_idx < term_num; term_idx++ ) { int freq; const char *term = ZOOM_facet_field_get_term(facets[facet_idx], term_idx, &freq); printf("term: %s %d\n", term, freq); } } } display_search_result(db); /* and display */ display_records(db->con, db->res, start, count, "render"); } } return ret; } static int cmd_scan(struct zoom_sh *sh, const char **args) { const char *query_str = *args; ZOOM_query query = ZOOM_query_create(); int i, number; int ret = 0; ZOOM_scanset *s = 0; struct zoom_db *db; while (*query_str == ' ') query_str++; if (memcmp(query_str, "cql:", 4) == 0) { ZOOM_query_cql(query, query_str + 4); } else if (ZOOM_query_prefix(query, query_str)) { printf("Bad PQF: %s\n", query_str); ZOOM_query_destroy(query); return 1; } for (number = 0, db = sh->list; db; db = db->next) if (db->con) number++; s = xmalloc(sizeof(*s) * number); for (i = 0, db = sh->list; db; db = db->next) if (db->con) s[i++] = ZOOM_connection_scan1(db->con, query); ZOOM_query_destroy(query); process_events(sh); for (i = 0, db = sh->list; db; db = db->next) { int error; const char *errmsg, *addinfo, *dset; /* display errors if any */ if (!db->con) continue; if ((error = ZOOM_connection_error_x(db->con, &errmsg, &addinfo, &dset))) { printf("%s error: %s (%s:%d) %s\n", ZOOM_connection_option_get(db->con, "host"), errmsg, dset, error, addinfo); ret = 1; } if (s[i]) { size_t p, sz = ZOOM_scanset_size(s[i]); for (p = 0; p < sz; p++) { size_t occ = 0; size_t len = 0; const char *term = ZOOM_scanset_display_term(s[i], p, &occ, &len); printf("%.*s %lld\n", (int) len, term, (long long int) occ); } ZOOM_scanset_destroy(s[i]); } i++; } xfree(s); return ret; } static int cmd_sortby(struct zoom_sh *sh, const char **args) { WRBUF strategy; const char *criteria; if (!(strategy = next_token_new_wrbuf(args))) { printf("missing argument argument: strategy and criteria\n"); return 1; } criteria = *args; while (*criteria == ' ') criteria++; wrbuf_destroy(sh->strategy); sh->strategy = strategy; wrbuf_rewind(sh->criteria); wrbuf_puts(sh->criteria, criteria); return 0; } static int cmd_sort(struct zoom_sh *sh, const char **args) { const char *sort_spec = *args; int ret = 0; struct zoom_db *db; while (*sort_spec == ' ') sort_spec++; for (db = sh->list; db; db = db->next) if (db->res) ZOOM_resultset_sort(db->res, "yaz", sort_spec); process_events(sh); return ret; } static int cmd_help(struct zoom_sh *sh, const char **args) { printf("connect \n"); printf("search \n"); printf("sortby \n"); printf("show [ [ [\n"); printf("quit\n"); printf("close \n"); printf("ext \n"); printf("set