Run latex
[egate.git] / doc / egate.sgml
1         <!doctype linuxdoc system>
2         
3 <!--    
4   $Id: egate.sgml,v 1.14 2001/02/26 14:32:36 adam Exp $
5 -->
6
7 <article>
8 <title>Email - Z39.50 gateway guide 
9 <author>Europagate, 1996 <htmlurl url="http://europagate.dtv.dk"
10  name="http://europagate.dtv.dk">
11 <date>$Revision: 1.14 $
12 <abstract>
13 This document describes a Email server that provides access to the
14 Z39.50 protocol.
15 </abstract>
16
17 <toc>
18
19 <sect>Introduction
20
21 <p>
22 This document describes an email server (ES) system developed
23 within the <htmlurl url="http://europagate.dtv.dk" name="EUROPAGATE">
24 project. The first part of this document
25 serves as an administrators guide, while the second part is a 
26 follow-up on the Design deliverable (WP4.1) that outlines the
27 deviations from the design. Also, the second part contains
28 a quick overview of the source code.
29
30 <sect>Installation
31
32 <p>
33 An ANSI C compiler is required in order to compile the ES software.
34
35 The ES can use either CNIDR's Zdist package or the YAZ package from
36 Index Data to interface the Z39.50 protocol. So you need to obtain
37 one of these first.
38
39 The zdist package can be found in:
40
41 <htmlurl
42 url="ftp://ftp.cnidr.org/pub/NIDR.tools/zdist/archive/1.02/zdist102b1-1.tar.Z" 
43 name="ftp://ftp.cnidr.org/pub/NIDR.tools/zdist/archive/1.02/zdist102b1-1.tar.Z">
44
45 The zdist package doesn't support result-set references. Also, it has a few
46 bugs. Therefore we've included a patch <tt/zdist.patch/ which fixes
47 some of these bugs.
48 Run patch in the directory above <tt/zdist102b1-1/:
49 <verb>patch <zdist.path</verb>
50 The ES server only depends on <tt>libz3950.a</tt> so you only need
51 to build the zdist software in the directory <tt/libz3950/.
52
53 YAZ can be found at the FTP host:
54
55 <htmlurl url="ftp://ftp.indexdata.dk/pub/yaz/"
56  name="ftp://ftp.indexdata.dk/pub/yaz/">
57
58 The ES also uses GNU's regex package to parse regular expressions. 
59 The ES has been tested with regex-0.12. Some systems, such as Linux,
60 come with the regex package preinstalled.
61
62 Unpack <tt>email-z39-...tar.gz</tt> and edit the top level
63 <tt/Makefile/. Specify where the GNU regex package is located by
64 setting the variables <tt/REGEXOBJ/ and <tt/REGXINC/. 
65
66 Some systems need you to add libraries for socket access. In this
67 case specify the <tt/ELIB/ variable.
68
69 The next section of the <tt/Makefile/ you specify the location of your
70 Z39.50 library - zdist or YAZ.
71
72 The shell variables <tt/CC/ and <tt/CFLAGS/ are used by the
73 <tt/Makefile/ so you may set these in your shell before you start
74 compiling.
75
76 Now, run <tt/make/. 
77
78 <p>
79 If the compilation succeeds, you should install the software in some
80 standard location.
81 Edit the <tt/Makefile/ and set EMAILLIBDIR to the installation
82 directory. Since, the ES is executed by the mail system, and not by a
83 user, this directory shouldn't be globally executable.
84
85 When satisfied, type <tt/make install/.
86
87 Three executables are installed in EMAILLIBDIR:
88 <descrip>
89 <tag/eti/ The email transport interface. This program receives
90 incoming mail, identifies the user, and delivers the mail request
91 to the monitor or kernel (depending on configuration).
92 <tag/monitor/ The monitor
93  is optional component. The main objective
94 of the monitor is to limit the number of simultanous running kernel
95 processes.
96 <tag/kernel/ The kernel process is the core of the ES. It parses
97 the user's requests and interfaces the Z39.50 protocols.
98 </descrip>
99
100 The <tt/sendmail/ or a similar program delivers the mail to the
101 <tt/eti/ program. The <tt/sendmail/ program usually runs as user
102 <tt/mail/ or some other special user name. We strongly suggest that
103 you create a special user and group for the ES software. In this case
104 you should use <tt/chmod/ to and set the 'set user ID on execution'
105 bits on the executable files and give that user read/write/execute
106 permissions in EMAILLIBDIR.
107
108 The mail system needs to know about the ES. Pick some name that serves
109 as the ES user and edit <tt/aliases/ used by your mail system (usually 
110 <tt>usr/lib/aliases</tt>). Now add the following line:
111
112 <tt>es:"|/usr/local/lib/emailgw/eti </tt><em>options</em><tt>"</tt>
113
114 In this example the mail user name is <tt/es/ and the EMAILLIBDIR is
115 <tt>/usr/local/lib/emailgw</tt>.
116
117 The ES system can operate with or without the monitor. When using
118 the monitor the number of simultanous running kernels can be
119 controlled. If the <tt>eti</tt> program is started with 
120 two dashes (<tt>--</tt>) it will operate without the monitor and
121 the options specified after the two dashes are transferred to the
122 kernel.
123
124 <sect1>Running with the monitor
125
126 <p>
127 The monitor must be running at all times in this mode. You should
128 start the monitor in one of your boot scripts (rc). For example this
129 might be put in a boot script:
130
131 <tscreen><verb>
132 (cd /usr/local/lib/emailgw; ./monitor -d -l mon.log -- -d -l kernel.log &)
133 </verb></tscreen>
134
135 Here the monitor is started with the options <tt>-d -l mon.log</tt>
136 and the options after the two dashes are transferred to the 
137 kernel. In this mode, the eti should contact the monitor (and not
138 the kernel), so the following might be put in the aliases file:
139
140 <tscreen><verb>
141 es:"|/usr/local/lib/emailgw/eti -c /usr/local/lib/emailgw"
142 </verb></tscreen>
143
144 The eti sets current directory to the path specified by option <tt>-c</tt>.
145
146 <sect1>Running without the monitor
147
148 <p>
149 In this mode you should never start the monitor. 
150 The eti will contact the kernel directly. The following line could
151 be put in your aliases file:
152
153 <tscreen><verb>
154 es:"|/usr/local/lib/emailgw/eti -c /usr/local/lib/emailgw -- -d -l kernel.log"
155 </verb></tscreen>
156
157 <sect1>eti
158
159 <p>
160 The eti program accepts the following options:
161 <descrip>
162 <tag><tt>-l </tt>log</tag> The log file. If absent stderr is used.
163 <tag><tt>-d</tt></tag> Turns on debugging.
164 <tag><tt>-c </tt>dir</tag> Sets current directory to dir.
165 <tag><tt>-H</tt></tag> Help message.
166 <tag><tt>--</tt></tag> Indicates that the eti program should contact the
167 kernel (and not the monitor. All options after this one are transferred
168 to the kernel
169 </descrip>
170
171 <sect1>monitor
172
173 <p>
174 The monitor program accepts the following command line options:
175 <descrip>
176 <tag><tt>-l </tt>log</tag> The log file. If absent stderr is used.
177 <tag><tt>-d</tt></tag> Turns on debugging.
178 <tag><tt>-H</tt></tag> Help message.
179 <tag><tt>--</tt></tag> Precedes options that are transferred to the kernel
180 </descrip>
181
182 The monitor normally reads the resource <tt>default.res</tt> in
183 current directory. You can change this behaviour by specifying an
184 alternate file on the command line.
185
186 <sect1>kernel
187
188 <p>
189 List of options observed by the kernel:
190 <descrip>
191 <tag><tt>-d</tt></tag> Turns on debugging.
192 <tag><tt>-t </tt>target</tag> Opens connection to target (for testing only).
193 <tag><tt>-g </tt>lang</tag> Set language name.
194 <tag><tt>-o </tt>res</tag> Overriding resource file name. These
195 resources override both <tt>default.res</tt> and all user resources.
196 <tag><tt>-h </tt>host</tag> Override host name (for testing only).
197 <tag><tt>-p </tt>port</tag> Override port no (for testing only).
198 <tag><tt>-l </tt>log</tag> Specify log file.
199 <tag><tt>-H</tt></tag> Help message.
200 </descrip>
201
202 The kernel normally reads the resource <tt>default.res</tt> in
203 current directory. You can change this behaviour by specifying an
204 alternate file on the command line.
205
206 <sect>Managing the system
207
208 <sect1>Summary of files
209 <p>
210
211 To maintain the ES you need to know the files it uses. These are:
212 <descrip>
213 <tag>*.res</tag> Resource files with several settings that control
214  how the system operates, such as definition of targets, messages, etc.
215 <tag>*.bib</tag> Bib-1 attribute mapping files. These files describe
216  the mapping between CCL and the RPN query.
217 <tag>user.db</tag> Database of users. Only the eti process accesses
218  this file.
219 <tag>user.*.r</tag> Resource file for a user &mdash; accessed by the kernel
220  &mdash; only created when the user uses the <tt>def</tt> command.
221 <tag>user.*.p</tag> Persistency file for a user &mdash; accessed by
222  the kernel
223  process. 
224 </descrip>
225
226 The ES system is mostly managed by resource files. The following
227 are example resource files that comes with the ES:
228 <descrip>
229 <tag><tt>default.res</tt></tag> General resource with reasonable defaults. 
230  This file is read by the monitor and the kernel.
231 <tag><tt>loc.res</tt></tag> Resource file for Library of Congress test
232  server.
233 <tag><tt>drewdb.res</tt></tag> Resource file for Data Research's test
234  server.
235 <tag><tt>lang.uk.res</tt></tag> Resource file for english conversation.
236 <tag><tt>lang.dk.res</tt></tag> Resource file for danish conversation.
237 </descrip>
238
239 <sect1>Resources
240
241 <p>
242 Most general resources should be set in the file <tt>default.res</tt>. 
243 Some of the resources may be changed (overridden) by the user, while 
244 others may be overridden by individual target defintions. 
245 The complete scenario is depicted below:
246 <tscreen><verb>
247        +-------------+
248        | default.res |
249        +-------------+
250               |          +--------------+
251               |<---------| "target.res" | 
252               |          +--------------+
253               |
254               |          +--------------+
255               |<---------| user.x.res   |
256               |          +--------------+
257               |
258               |          +--------------+
259               |<---------| "lang.res"   |
260               |          +--------------+
261               |
262               |          +--------------+
263               |<---------| "override"   |
264               |          +--------------+
265             result
266 </verb></tscreen>
267
268 The following describes the general resources:
269 <descrip>
270 <tag>gw.reply.mta</tag> Name of MTA program &mdash; default
271  <tt>/usr/lib/sendmail</tt>.
272 <tag>gw.reply.tmp.prefix</tag> Prefix of temporary files used by the ES.
273 <tag>gw.reply.tmp.dir</tag> Name of directory with temporary files.
274 <tag>gw.marc.log</tag> If this resource is specified, retrieved MARC
275  records will be appended to this file.
276 <tag>gw.timeout</tag> Idle time before the kernel exits. When the
277  kernel exits, the Z39.50 persistency layer will reconnect when
278  necessary.
279 <tag>gw.resultset</tag> If this setting is 1, the Z39.50 client will
280  use named result sets. If 0, the Z39.50 system will always use 
281  <tt/Default/ as result-set name.
282 <tag>gw.persist</tag> If this setting 1, the persistency is enabled;
283  disabled otherwise.
284 <tag>gw.max.process</tag> This settings is the maximum number of
285  simultaneous kernel processes &mdash; only used by the monitor.
286 <tag>gw.ignore.which</tag> Some targets doesn't indicate whether
287  a record is a diagnostic messaage or a database record. If this
288  setting is 1, the ES will always try to interpret the record as a
289  database record in ISO2709 format. If 0, the ES will use the
290  record type.
291 <tag>gw.default.show</tag> Default number of records to retrieve and display
292  when using the show command. This setting may be changed by the user
293  with the <tt>def defaultshow</tt> command.
294 <tag>gw.max.show</tag> This setting specifies the maximum number of
295  records the user may retrieve in one show command &mdash; default 100.
296 <tag>gw.autoshow</tag> Number of records to retrieve in a find
297  command &mdash; default 0. This setting may be changed by the user by
298  the <tt>def autoshow</tt> command.
299 <tag>gw.display.format</tag> Default display format. This setting may
300  be changed by the user by the <tt>def f</tt> command.
301 <tag>gw.language</tag> Current language. This setting may be
302 changed by the user with the <tt>def lang</tt> command. When the 
303  langauge is set to something, say x, then the resource gw.lang.x 
304  should hold a name of a resource file read by the kernel.
305 <tag>gw.lang.<em/x/</tag> Specifies name of resource file for 
306  language <em/x/.
307 <tag>gw.target.<em/name/ </tag> Name of resource file of target
308  <em/name/.
309 <tag>gw.portno</tag> Z39.50 target port number &mdash; default 210.
310 <tag>gw.hostname</tag> Z39.50 target host name.
311 <tag>gw.bibset</tag> Name of file with Bib-1 attribute mapping.
312 <tag>gw.databases</tag> Available databases on target.
313 <tag>gw.description</tag> Description of a target. This message
314  is returned to the user when the connection is established with the
315  target.
316 <tag>gw.account</tag> Z39.50 Authentication string &mdash; default
317  empty (i.e. none).
318 </descrip>
319
320 <sect1>Messages
321
322 <p>
323 There are several resource settings that deal with language 
324 dependencies. These fall into the following categories that
325 depend on the resource name prefixes:
326 <descrip>
327 <tag>gw.msg</tag> Miscellaneous messages.
328 <tag>gw.err</tag> Error messages.
329 <tag>gw.bib1.diag.<em/no/</tag> Diagnostic error message indicated by
330  <em/no/.
331 <tag>gw.help</tag> Help/description of various commands.
332 <tag>ccl.command</tag> CCL command names.
333 <tag>ccl.token</tag> CCL tokens names.
334 </descrip>
335
336 Refer to the sample files, <tt>default.res</tt>, <tt>lang.uk.res</tt>
337 and <tt>lang.dk.res</tt> for all available settings.
338
339 <sect1>Target definitions
340
341 <p>
342 To add a target definition called <em/mytarget/ you need to make a resource 
343 entry in <tt>default.res</tt> called <tt>gw.target.</tt><em>mytarget</em>.
344 The value of this resource is the name of a resource file &mdash; for 
345 example <em>mytarget</em><tt>.res</tt>. The resource file should at least
346 define the resources: <tt/gw.hostname/, <tt/gw.databases/ and 
347 <tt/gw.description/. You might also consider specifying
348 <tt/gw.account/, <tt/gw.bibset/, <tt/gw.resultset/ and <tt/gw.portno/
349 in the target resource file. The user only needs to use the command
350 <tt>target </tt><em>mytarget</em> to use the target. Also, since we
351 already specified database names, the user doesn't need to use the
352 <tt/base/ command.
353
354 <sect1>CCL to RPN mapping
355
356 <p>
357 The mapping between CCL-queries and RPN are stored in files &mdash;
358 normally with the suffix <tt>.bib</tt>. We will refer these
359 files as bibset-files. You might consult the file <tt/default.bib/
360 to see an example of such file.
361
362 The mapping is necessary because targets usually only support a little
363 subset of the Bib-1 attribute set and because the CCL qualifiers
364 (field names) are not standardized. A bibset-file is specified
365 by the <tt/gw.bibset/ resource.
366
367 Column zero of a bib-file line either hold a hash character (<tt/#/)
368 indicating a comment in which case the rest of the line is
369 ignored; or a CCL qualifier.
370
371 The name of the CCL qualifier is up to you. However, the special
372 qualifier name <tt/term/ applies to the case where no qualifier
373 is specified in CCL. The CCL qualifier is
374 followed by one or more mapping specifications. A mapping
375 specification takes the form:
376
377 <em/type/<tt/=/<em/value/<tt/,/<em/value/...
378
379 The type is simply one of the six Bib-1 attribute query types:
380 <descrip>
381 <tag/u/ Use attribute. Value is an integer.
382 <tag/t/ Truncation attribute. Value is an integer; or the
383  value is a combination of:
384   <descrip>
385   <tag/l/ This character indicates that the CCL parser should allow
386   left truncation (2) if indicated by a <tt/?/ on the left side
387   of a term.
388   <tag/r/ This character indicates that the CCL parser should allow
389   right truncation (1) if indicated by a <tt/?/ on the right side
390   of a term.
391   <tag/b/ This character indicates that the CCL parser should allow
392   both left and right (3) truncation indicated by a <tt/?/ on both
393   left and right side of a term.
394   <tag/n/ This character indicates that the CCL parser should announce
395   no truncation (100) if no truncation was specified.
396   </descrip>
397 <tag/p/ Position attribute. Valus is an integer.
398 <tag/s/ Structure attribute. Value is an integer; or the
399  value is <tt/pw/ in which case the CCL parser announces word (2) or
400  phrase (1) depending on the number of adjacent terms.
401 <tag/r/ Relation attribute. Value is an integer; or the value is
402  <tt/o/ in which case, the CCL parser will select <em/less than/, 
403  <em/less than or equal/, ... <em/greater than/ &mdash; depending on
404  the relation specified in CCL.
405 <tag/p/ Position attribute. Value is an integer.
406 </descrip>
407
408 Consider these bibset-lines:
409 <tscreen><verb>
410 term t=l,r,b s=pw
411 au= u=1 t=l,r,b s=pw
412 date u=30 r=o
413 </verb></tscreen>
414 The first line describes the mapping in when no qualifiers are
415 present, as in:
416 <tscreen><verb>
417 find foo bar?
418 </verb></tscreen>
419 In this case the right truncation is enabled and the structure is
420 <em/phrase/.
421
422 The second line is used in this search:
423 <tscreen><verb>
424 find au=andersen
425 </verb></tscreen>
426 where the use attribute is <em/author/ and the structure is <em/word/.
427
428 The third line is used in:
429 <tscreen><verb>
430 find date>1990
431 </verb></tscreen>
432 where the use attribute is <em/date/ and the relation is <em/greater than/.
433
434 <sect>Implementation
435
436 <p>
437 The implementation of the email server includes all the modules described
438 in the design deliverable. 
439
440 The work was roughly carried out as follows:
441 <enum>
442 <item>The logging facilities and resource management utilities were
443  implemented &mdash; virtually all other modules depend on these
444  modules.
445 <item>A minimal ES was implemented &mdash; including a high-level
446  API to the Z39.50 sub-system and a CCL parser with a few
447  commands, such as FIND and SHOW. This version displayed MARC
448  records in a raw format. This version served as base for the URP.
449 <item>The first version of the MARC display formatting tool, FML,
450  was implemented and included in the ES.
451 <item>The ETI program was implemented along with the IPC 
452  (interprocess communication) utilities based on FIFOs. Facilities
453  to keep connections alive (to Z39.50 targets) was implemented.
454  To identify a user, a file-resident symbol table (small database) was 
455  implemented which maps a email username to a unique integer (email userid). 
456 <item>The protocol persistency was implemented and more CCL commands
457  were added.
458 <item>The monitor program was implemented.
459 </enum>
460
461 The following sections cover the most important modules in the ES and
462 deviations from the design.
463
464 <sect1>Z39.50 Interface layer
465
466 <p>
467 The design report specified that the Zdist toolkit from CNIDR would
468 be used in the ES to provide access to the Z39.50 protocol. The package
469 was choosen bacause it is easy to use and, more important, we felt
470 that the API would be reasonably stable and supported.
471
472 Nevertheless it turned out that CNIDR choose to change the API 
473 completely around January 1995 and announced a new version 
474 called zdist102b1-1. 
475
476 <em>Note: As of this date the newest version of Zdist is still
477 zdist102b1-1. CNIDR seems to concentracte on their Isite package
478 which also includes a Zdist package presumably similar to the
479 standalone Zdist package</em>
480
481 During the work with the Zdist package a few bugs were discovered.
482 Fortunately, they could be solved within a few days. We also
483 discovered that the package lacks result-set references.
484
485 In February some of us began the development of a new Z39.50 package 
486 called YAZ &mdash; in retrospect somewhat motivated by the 
487 experiences with existing Z39.50/SR toolkits.
488
489 To support result-set references we chose to incorporate a YAZ 
490 interface in the ES also. And we designed and implemented a 
491 simple high-level Z39.50 origin API that supported both Zdist and YAZ.
492
493 The protocol persistency module was implemented on top of
494 the high-level API and not on top of Zdist. The obvious 
495 advantage is that the persistency module is not tied to one 
496 particular Z39.50/SR package.
497
498 Persistency information stored for each user is simply:
499 <itemize>
500 <item>hostname and port number.
501 <item>authentication string
502 <item>selected database(s)
503 <item>next result set number
504 <item>next result set position
505 <item>result set information
506 </itemize>
507
508 Information about each result set includes:
509 <itemize>
510 <item>name
511 <item>size (number of hits)
512 <item>database(s)
513 <item>query
514 </itemize>
515
516 A persistency file is removed each time a new target is selected.
517 It is our experiences that the persistency files are very small.
518
519 <sect1>CCL
520
521 <p>
522 The CCL was implemented as described in the design. A CCL utility
523 was made as a separate module which implements a tokenization
524 package and a parser which translates from FIND to RPN. The
525 data structure used to represent the RPN query is also used in
526 Z39.50 search API on top of YAZ or Zdist. 
527
528 The CCL parser is quite configurable. Token names can be redefined to
529 one or more names (aliases). Also, the specification of mapping
530 between CCL field names (qualifiers) and Bib-1 attributes can be
531 specified in either the C API or a file.
532
533 Although the Z39.50 system in the ES uses the Bib-1 attribute set, the 
534 CCL parser itself is not tied to Bib-1.
535
536 <sect1>FML
537
538 <p>
539 The FML system is used to handle the presentation of MARC
540 records. There are some deviations to the design report, however.
541 The most important changes are:
542 <itemize>
543 <item>The <tt/expr/ function is not implemented. Instead arithmetic
544 operators <tt/plus/, <tt/minus/, <tt/mult/ and <tt/div/ are
545 implemented. Also relational operators <tt/gt/, <tt/lt/ ... are
546 implemented.
547 <item>The <tt/lindex/ function is called <tt/index/ and it is a binary
548 operator where the left operand is the list and the right operand is
549 the index integer.
550 <item>The MARC extraction routines are not implemented.
551 Instead, a MARC record is transferred as an argument
552 to a formatting-routine (in list notation). The formatting
553 routine then extracts fields from the list by list/string
554 manipulation functions.
555 <item>A new statement, <tt/bin/, is implemented to define
556 binary operators (functions). 
557 </itemize>
558
559 <sect1>IPC
560
561 <p>
562 As described in the design, FIFOs are used to communicate between
563 the ETI, monitor and kernel. The ES can run without the monitor,
564 however. The primary reason for the presence of the monitor was
565 to assure that the kernel releases the resources used by the
566 persistency layer. But, since the persistency layer did turn out to
567 use virtually no disk space at all, there was no point in starting
568 a kernel process to remove its files &mdash; hence this facility 
569 was not implemented. The only purpose of the monitor is to keep the
570 number of running kernels at a maximum level and even that
571 is probably useless since most unices will swap kernel processes
572 out anyway.
573
574 The idle time
575 before a kernel exits and saves its persistency file is not
576 controlled by the monitor. Saving the persistency file and
577 keeping it is usually a good approach &mdash; even when a
578 user doesn't reference/show old result-sets since the user
579 has a notion of <em/current target/ and database.
580
581 <sect1>Source
582
583 <p>
584 In this section a short description of each source module is
585 given. Each module is implemented in a separate sub directory. 
586 Any public headers are located in the <tt/include/ directory.
587
588 <descrip>
589 <tag/res+log/ is an implementation of the logging system
590 and the resource management sub system. Note that the
591 resource module depends on the logging facility. Logging
592 is implemented in <tt>gw-log.c</tt> and <tt/gw-log.h/. The
593 file <tt>gw-log-test.c</tt> is small test program for the
594 logging system. The core of the resource management is implemented
595 in <tt>gw-res.c</tt>. The files <tt>gw-res-bool.c</tt> and
596 <tt>gw-res-int.c</tt> implement two utility routines &mdash
597 on top of the resource management. The header file
598 <tt>gw-resp.h</tt> is a private header file and <tt>gw-res.h</tt>
599 is a public header file.
600
601 <tag/ccl/ implements CCL to RPN mapping and a tokenization 
602  utility for other CCL commands. The mapping function is
603  implemented in <tt>cclfind.c</tt>. Qualifiers are handled in 
604  <tt>cclqual.c</tt> while reading of qualifier mappings from a
605  file is implemented in <tt>cclqfile.c</tt>. Scanning is implemented
606  in <tt>ccltoken.c</tt>. String utilities, which might be changed if
607  other character sets are needed, is implemented in
608  <tt>cclstr.c</tt>. Table of error messages is implemented in
609  <tt>cclerrms.c</tt>.
610
611 <tag/util/ implements various utilities:
612   <descrip>
613   <tag>MARC utility</tag> implemented in <tt>iso2709</tt>...
614   <tag>Database utility</tag> implemented in <tt>gw-db.[ch]</tt>. This
615    utility is used to map a user (email) to an integer.
616   <tag>String queue utility</tag> implemented in <tt>strqueue.[ch]</tt>. This
617    utiltiy is used to queue incoming mail in the ETI, kernel and
618    the monitor.
619   <tag>Pretty printer</tag> implemented in <tt>ttyemit.[ch]</tt>
620    &mdash; used by the URP.
621   <tag>FIFO IPC utiltiy</tag> implemented in <tt>gip*.[ch]</tt> &mdash;
622    used by the ETI, kernel and monitor.    
623   </descrip>
624
625 <tag/fml/ implements FML. The top level functions are implemented
626  in <tt>fml.c</tt>, <tt>fmlcall.c</tt> and <tt>fmlcalls.c</tt>.
627  Scanning is implemented in <tt>fmltoken.c</tt>.
628  Memory management is implemented in <tt>fmlmem.c</tt>. 
629  Arithmetic operators are implemented in <tt>fmlarit.c</tt>. 
630  String manipulation functions are implemented in <tt>fmlstr.c</tt>.
631  Relational operators are implemented in <tt>fmlrel.c</tt>.
632  List maniuplations are performed in <tt>fmllist.c</tt>.
633  FML symbol table management is implemented in <tt>fmlsym.c</tt>.
634  Conversion from ISO2709 to list notation is implemented in
635  <tt>fmlmarc.c</tt>.
636
637 <tag/zlayer-zdist/ implements the high-level Z39.50 API on top
638   of Zdist. This task is implemented in <tt>zaccess.c</tt>. The
639  public header file is called <tt>zaccess.h</tt>.
640
641 <tag/zlayer-yaz/ implements the high-level Z39.50 API on top
642   of YAZ. This task is implemented in <tt>zaccess.c</tt>. The
643  public header file is called <tt>zaccess.h</tt>.
644
645 <tag/kernel/ implements the ETI, kernel and monitor. The kernel
646  itself is implemented in <tt>main.c</tt>, <tt>urp.c</tt> and
647  <tt>persist.c</tt>. The ETI is implemented in <tt>eti.c</tt> and
648  the monitor is implemented <tt>monitor.c</tt>.
649 </descrip>
650
651 <sect>LICENSE
652
653 <p>
654  Copyright &copy; 1995-1996, the EUROPAGATE consortium (see below).
655
656  The EUROPAGATE consortium members are:
657
658 <itemize>
659 <item>University College Dublin
660 <item>Danmarks Teknologiske Videnscenter
661 <item>An Chomhairle Leabharlanna
662 <item>Consejo Superior de Investigaciones Cientificas
663 </itemize>
664
665  Permission to use, copy, modify, distribute, and sell this software and
666  its documentation, in whole or in part, for any purpose, is hereby granted,
667  provided that:
668
669  1. This copyright and permission notice appear in all copies of the
670  software and its documentation. Notices of copyright or attribution
671  which appear at the beginning of any file must remain unchanged.
672
673  2. The names of EUROPAGATE or the project partners may not be used to
674  endorse or promote products derived from this software without specific
675  prior written permission.
676
677  3. Users of this software (implementors and gateway operators) agree to
678  inform the EUROPAGATE consortium of their use of the software. This
679  information will be used to evaluate the EUROPAGATE project and the
680  software, and to plan further developments. The consortium may use
681  the information in later publications.
682  
683  4. Users of this software agree to make their best efforts, when
684  documenting their use of the software, to acknowledge the EUROPAGATE
685  consortium, and the role played by the software in their work.
686
687  THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTY OF ANY KIND,
688  EXPRESS, IMPLIED, OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY
689  WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
690  IN NO EVENT SHALL THE EUROPAGATE CONSORTIUM OR ITS MEMBERS BE LIABLE
691  FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF
692  ANY KIND, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA
693  OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND
694  ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE
695  USE OR PERFORMANCE OF THIS SOFTWARE.
696
697 </article>