+-----------------------------------+ | Description of parameters used | | when starting the Horizon ZServer | +-----------------------------------+ As of version 1.18 ------------------ /s server /p password /u user_id /d database This is the classic Horizon "spud" connection information. /f flavor This specifies the pac flavor to use. The default is "pac". /g logfile All SQL commands sent to Sybase will be logged in the specified file. This switch turns on logging of all SQL commands for all zserver processes for the entire life of the zserver process. Unfortunately there are sometimes "runaway processes" (typically SQL commands that never return, due to deadlock or other reasons). As it is impossible to guess the last performed SQL command without a logfile, and as it is impractical to leave logging on permanently, another logging feature has been added for Unix ZServers: you can signal a specific zserver process using SIGUSR1, which will toggle on and off logging of all SQL commands starting with the last submitted command for that zserver process. The logfile will be stored in /tmp/zs_PID.log . Example: kill -s usr1 100 This command will turn on logging for pid 100. The same command a second time will turn logging off. -pportNb Specifies the port number the ZServer will be listening on. No space is allowed between the -p and the port number. -sserviceName This must always be the first parameter in the list ! Allows the specification of the NT Service name (NT only). See below under "NT System Service" for more details. /b bibtagSubfield If this parameter is specified, the ZServer will add to each Marc record the bib# of the record, in the specified tag and subfield. Example: /b 29b will put the bib# in tag 29 subfield b. /B borrower# This enables the 911a tag security restriction. The specified borrower# is used to retrieve the security_group from the borrower_911 table. If /B is used, bibs that have a tag 911 subfield a will only be returned when the subfield matches the specified borrower's security group. /B can also be used without specifying a borrower#; in that case, any bib that has a 911a tag will be filtered out from all result sets. /k Starting with release 1.15, the ZServer sends by default a "cookie" along with each scan entry. This cookie is used for scan to briefs. Before release 1.15, cookies were only sent for call number and uniform title searches. Some WebPac 1.3 builds parse the search string and choke on the cookie. If you have this problem, disable the cookie generation by using the parameter /k . Cookies will then be sent only for call number and uniform title searches (just like pre-1.15 builds). /h Suppress copies without summary of holdings. Prior to release 1.15, all copies (holdingsAndCircData) and items (circRecord) would be returned in the OPAC record; copies without summary_on_holdings would not have a Volume record. In release 1.15, only copies (and therefore items) with a summary_of_holding would be returned. The /h switch allows you to choose between the two behaviors: with the switch, the 1.15 behavior takes effect; without, the pre-1.15 behavior is used. /m maxConnections Specifies how many database connections can be concurrently open in one process. The default is 25 connections. As the Unix builds of the ZServer create one process per connection, each process will always have only one connection. The NT build, on the other hand, creates one thread per connection, all threads therefore sharing the same limit. If you need more than 25 connections for your NT ZServer, use this parameter. /c client_codepage This specifies in which codepage input/output will happen. If no codepage is specified, the old (pre 1.11) approach is used: search term: workstation codepage (always ANSI) scan general term: server codepage (850) scan display term: ALA scan see/seeAlso: ALA holdings information: server codepage (850) MARC record: ALA The specified codepage can either be one of the codepages specified in the ala_to_cp table, or "ALA". Regardless of the codepage chosen, MARC records will always be sent back in ALA format. /C Tells the ZServer that call number search terms should be converted to all caps. The default (without this switch) is to leave the terms unchanged, but the LC processor parses call numbers in unexpected ways when encoutering mixed-case search terms. /n interface_language_code This specifies which string to use in a multilingual field, such as a location name. The parameter must specify the language code as specified in the interface_language table. /l localefile This allows the specification of a file that contains locale-specific information. This is a text file, with one item per line, using the following format: attribute=value The valid attributes are: attribute: default value: valid values: explanation: ---------- -------------- ------------- ------------ iDate MM_DD_YY MM_DD_YY date format DD_MM_YY YY_MM_DD MM_DD_YYYY DD_MM_YYYY YYYY_MM_DD sDecimal . (any string) decimal point symbol sDate / (any string) date separator sTime : (any string) time separator iDigits 2 (any number) position of decimal point iTime 0 0 or 1 0: AM/PM format; 1: military time s1159 AM (any string) gets appended to morning times s2359 PM (any string) gets appended to afternoon times Example: If /l locale.txt is specified at startup and the file locale.txt contains the following 3 lines: iDate=DD_MM_YY sDate=- iTime=1 then the due_date/due_time string "03/21/98 04:15 PM" (default format) will be returned as "21-03-98 16:15". /r restriction This allows a ZServer-wide restriction. All connections to the given port will be affected. The /r parameter can be used multiple times to specify more than one restriction (the restrictions will be ANDed together). The restriction can either be a predefined restriction or a valid SQL "where" clause on the item and the copy table. Restrictions will only affect Z39.50 search requests (not scan requests). Examples: 1) If /r books is specified and "books" has been defined in the restriction mq_view as being "itype='b'", only books 2) If /r "location='main'" is specified, only items in the "main" location will be displayed. Note: The /r parameter acts like a ZServer-wide 9900 restriction. For search-specific restrictions (restrictions specified during a search request), see the section "Restrictions Use Attributes" below. /S sort_file The specified file is used for the following operations on result sets: - specify maximum resultset size for restricting/filtering - specify a default sort order, specific to each use attribute - create additional use attributes defining user-selected sort orders - create additional use attributes for marcmap-based filtering The contents of this file is discussed in detail in a section below entitled "Sorting and Restricting Result Sets". Note: If this parameter is not specified, Z39.50 result sets will not be sorted (they will default to the database order, which is usually the bib#). There is a memory usage and a performance penalty for sorting result sets; if no sorting is required and high performance is crucial, this parameter should be omitted. +-------------------------------+ | Z39.50 Structure Attribute | +-------------------------------+ When the ZServer starts, it displays (or writes out to the log file for the NT version) a list of all the valid Z39.50 Use Attributes that have been setup for the given PAC flavor and which mq_view and mq_index will be used for the search. It also indicates the index type, using the following numbers: 0 keyword 1 alpha list 2 inverted list 3 call number 4 multi-source When the ZServer receives a request (search and scan alike), it looks at all the possible searches, and based on the Use Attribute and the Structure Attribute of the request, it will choose the most appropriate mq_index, using the following matching table: Structure Attribute Index Type 1 (phrase) 1 (alpha list) 1 (phrase) 2 (inverted list) 1 (phrase) 4 (multi-source) 2 (word) 0 (keyword) 3 (key) 3 (call number) If none of the above lines applies, the ZServer will return the error 114 (Unsupported Use Attribute). If more than one line match, the first matching search is used. +------------------------------------------+ | Item-based Restrictions Use Attributes | +------------------------------------------+ In addition to specifying ZServer-wide restrictions (specified through the /r parameter explained above), restrictions can also be specified in search requests, using the following use attributes: use attribute: restriction: -------------- ------------ 2002 collection 3008 location 9900 predefined restriction or "where" clause 9901 same as 9900, but only used on item table These search restrictions will be ANDed with the ZServer-wide restriction(s). Such search request restrictions must be placed at the root of the search tree in the RPN query. Just as for the /r parameter, the 9900 and 9901 can be either a predefined Horizon restriction or a valid SQL where clause. Note: Difference between 9900 and 9901: During searches, the 9900 and 9901 restrictions are ANDed together. To display holdings information, the 9900 restriction is used when retrieving information from the copy table, the 9900 and 9901 are ANDed together to access the item table. Therefore, the 9900 must be applicable to the item AND the copy table, while the 9901 only has to apply to the item table (i.e. it can reference columns that don't exist in the copy table). For example, if you want to filter on a location AND on item_status, you need to specify the location restriction through use attribute 3008 or 9900, and the item_status restriction through use attribute 9901. The restriction specified with /r is equivalent to the 9900 use attribute. +-------------------------------------+ | Sorting and Restricting Result Sets | +-------------------------------------+ The previous section explained several use attributes used for item-based restrictions. Item-based restrictions are performed during searches and are therefore very efficient. Another type of restriction is the marcmap-based restriction: this is when a restriction is based on a MARC tag subfield. In this case, the restriction must be performed once the result set is created and all the MARC tags are loaded. This type of restriction is more computationally intensive and causes a performance penalty, but allows much more flexible restrictions. Marcmap-based sorting works just like marcmap-based restricting: sorting is done once all relevant MARC tags are loaded into memory. Because very few Z39.50 client programs support the Sort request, we opted for an extension to the Search request to specify sort orders and restrictions. Sort orders and restrictions must be specified using special use attributes, just like item-based restrictions. And like item-based restrictions, marcmap-based restrictions and sort orders must be placed at the root of the search tree in the RPN query. In order to set up marcmap restrictions and sorting, a mapping between the use attribute and the marcmap must be established. This mapping is specified through a sort file with the /S startup parameter. This file is organized in separate sections, each section being optional. Below a sample sort file: maxrset=500 [Sort] 0 TitleD, DPDate:D 1003 author, TitleD 555 DPDate:D [Restrict] 5555 DPDate The first line specifies the maximum resultset size past which not sorting/filtering will take place (in this case 500 bibs). In the [Sort] section, all use attributes requiring a default sort order are listed, with the following format: use_attr column1_label[:A|D] [column2_label:[A|D]] The ascending/descending flag can be omitted (ascending is the default). Up to two columns can currently be specified. Each use attribute can appear only once in the section. You can specify the use attribute 0 (zero) for default sorting: use attributes not defined in this section will use the zero use attribute's sort order. In the example above, all Z39.50 result sets will be sorted by ascending title and descending publication date, except for author searches (use attr 1003) which will be sorted by author and title. The default sort order can also we overridden by adding the sorting use attribute 9990 at the root of the search tree, and specifying in the search term an entry from the sort file. If for example the ZServer receives a search request with the use attribute 1003 (author keyword), it will sort the result set by author and title. If however the search tree also contains a use attribute 9990 with the search term "555", the result set will be sorted by descending pubdate instead. Any number can be defined in the sort_file. Use attributes that are to be used only for sorting, not for searching, should use numbers that won't interfere with valid searching use attributes. In the above example, 555 has not been defined in the search table; it it merely being used to represent a pubdate sort order. In the [Restrict] section, you can establish a mapping between use attributes and marcmaps. Similar to user-defined sort orders, the restriction is then specified by adding a node to the search tree. For restrictions, the use attribute is the entry in the sort_file, the search term is the value to be compared against, and the relation attribute is used to specify the test to perform during the restricting process. For example, using the above sort_file, if the search contains the term "1980" with the use attribute 5555 and the relation attribute 4 (greater or equal), only books published since 1980 will be returned. Restrictions can also take advantage of the conditions specified in the marc_extraction definition. When no other condition than the one(s) specified in the marc_extraction is necessary, the search term should be "*". The ZServer will then do no other restricting then what has been done during the marc_extraction process. This is especially useful for ORing multiple conditions. Note: The sort filter of the marc_map must be set up correctly for the sorting to work properly (dates for example won't be sorted correctly otherwise). +--------------------+ | NT System Service | +--------------------+ The NT version of the ZServer runs as an NT System Service. zstart.exe creates the service and starts it. The parameters passed to zstart are stored in a zdaemon.arg file, which is then read by the actual service executable, zdaemon.exe. The third executable, zkill.exe, is used to stop the service and remove it from the available list of services in the registry. Once the service exists, the service can be stopped and started through the NT Services control panel. The file zdaemon.arg can also be edited to change spud values. Multiple zdaemon services can be started, in which case each instance must have a unique name. The default name is zdaemon. You can specify other names through the startup parameter -s. To kill a service with a non-default name, use the same parameter. Example: zstart -szdaemon1 /ssybase /dhorizon /usa /ppasswd /fflavor1 -p210 zstart -szdaemon2 /ssybase /dhorizon /usa /ppasswd /fflavor2 -p211 The above starts 2 services on 2 different ports using 2 different flavors. The files zdaemon1.arg and zdaemon2.arg are created. To kill the second service, type: zkill -szdaemon2 Notes: - The parameter -s must be the first parameter in the list. - Make sure each service uses a different port zdaemon.exe can also be executed from the command prompt (no system service) by using the switch -noss (must be the first parameter). This can be useful to make sure the database is available and the spud valid, or to display the build date. Examples: zdaemon -noss /ssybase /dhorizon /usa /ppasswd /fflavor -p210 Ctrl-C will then stop the ZServer. zdaemon -noss displays the available parameters and also the build date.