Technical Support Base

Main -> Support -> Technical Support Base

Last Updated: October 11, 1999

The Technical Support Base serves as a resource for tasks that are not currently included in the Documentation. The following procedures are discussed within this technical resource:

Setting Name, IP and DNS Authentication

Using zclient to Test Z39.50 Resources

Modifying EmailRecs.java

Building a Database with a Sparse Index

Adding MARC 856 to a Formatted Record Display

Using Statistics in JaSSI

Configuring the ZBroker Server in WebZ

Using a Proprietary SQL RDBMS Server and Database with the Access Component

The JIT, ssmgr, and SiteSearch

Displaying DRA Holdings Information

Configuring Automatic AutoSort

The Technical Support Base will be updated frequently. These documents will be removed from the Technical Support Base once complete documentation is available.

Setting Name, IP and DNS Authentication

In Open SiteSearch, there are three modes of patron authentication: Name, IP (Internet Protocol) and DNS (Domain Name Server).

Name
Name authentication works directly from the out-of-the-box (OBI) interface. The patron's username and password are passed along as "widgets" from the index.html page using the Authorize verb. The patron clicks the GO! button and SiteSearch processes the widgets to authenticate the patron and determine the databases and display style from the authos table in the Access component.

IP
SiteSearch can also authenticate patrons based on the IP address of the client, bypassing the need to have patrons login.

There are three basic steps for activating IP authentication.

1. Populate the authos table with valid IP addresses.

2. Set the CheckIPAuthos parameter to TRUE in the Access.ini file.

3. Disable or bypass the autho/password widgets from being sent in with the Authorize verb.

More detail:

1. Populate the authos table with valid IP addresses.

Refer to "Configuring the Access Component" for details on creating the accessdb file.

UNIX
NT

Make sure to edit the accessdb data file and include the IP addresses in the authos table before importing the data into the accessdb database.

NOTE: If you want to add a range of IP addresses instead of entering each IP individually, use one of the following conventions:

ip:123.456.789.12-16
ip:123.456.789.*
ip:123.456.700-800.*
ip:123.456.*.*
ip:123.440-450.*.*
ip:123.*.*.*
ip:100-200.*.*.*

2. Set the CheckIPAuthos parameter to TRUE in the Access.ini file.

The Access.ini file is in the <WebZ_root>/ini/servers directory.

3. Disable or bypass the autho/password widgets from being sent in with the Authorize verb.

Sending autho and password widgets from the index.html page overrides IP authentication. These widgets must be removed from the index.html page or bypassed with a separate hotlink button in order to enable IP authentication.

To remove the widgets, edit out the input boxes from the index.html page.

To bypass the index.html page, create a separate hotlink. For example:

<A HREF="http://hostname:portnumber/WebZ/Authorize:sessionid=0:next=html/homeframe.html:bad=error/authofail.html">Enter via IP Autho</A>

DNS Authentication

Follow the same procedure for enabling IP authentication with these exceptions:

1. Instead of IP addresses, populate the authos table with DNS addresses in the format, dn:name.name.edu. Wildcards are valid, if applicable. For example, dn: *.name.edu

2. In the Access.ini file, set CheckDNSAuthos to TRUE

NOTE: The OBI can authenticate by Name and IP simultaneously or Name and DNS simultaneously, but not IP and DNS simultaneously. In the OBI, the CheckIPAuthos and CheckDNSAuthos parameters cannot both be set to TRUE. Users that need both modes of authentication will need to modify the Authorize class.

Using zclient to Test Z39.50 Resources
(Originally distributed with the June 1999 issue of InSite)

Z39.50 is a standard protocol that allows a user to search databases, view records, and manipulate result sets.

In a perfectly standard world, each Z39.50 vendor would implement the client/server protocol in the same manner and would provide the necessary information for the configuration of Z39.50 clients. But because each vendor has implemented a different flavor of Z39.50 and has created unique databases, some Z39.50 compatibility testing is necessary.

Open SiteSearch 4.x provides a basic Z39.50 client, zclient, to aid in this testing process and is able to test client/server connections, verify searchable indexes, view records, and analyze Application Protocol Data Units (APDUs).

Reference

Z39.50-1995 Manual
Available for download from the Library of Congress

Server Configuration Files
Default values for the variables in the configuration files located in the <WebZ_root>/ini/servers directory

Attribute Set Bib-1
Details the use and structure attributes supported with the Z39.50 protocol.

APDU document
Sample data from a zclient session conducted on tikal.dev.oclc.org

Checklist

Core elements you'll need:

Server ip address or domain name (i.e., hostname)
Port number on server for Z39.50 communication
Database name

Additional helpful information:

Query type supported

Record syntaxes supported

Indexes available for searching and definitions of index behavior
(i.e., Z39.50 Attributes: Use, Structure, Truncation)

Additional Z39.50 Facilities supported (i.e., Scan, Sort, etc.)

Most of the information you'll need is located in the <database>.ini and <server>.ini files. Printing these files for reference may be useful.

The <database>.ini file specifies the server where the database is located, the name assigned to the database, the syntax of the records and the use and structure of the searchable indexes.

The <server>.ini lists port, hostname, autho and password (if necessary), query type and whether it supports advanced searching features such as scan and sort.

Sample

port:
hostname:
autho:
password:
query type:
dbname:
index(01):
syntax:

Use data below to test zclient

210
tikal.dev.oclc.org
100118439
pxg2gxuge
101
wcat
keyword; use=1016; structure=2
marc

Start a Session

From the <WebZ_root>/scripts directory, start a zclient session using the syntax shown to the right.

Optional parameter - result set name

Servers that do not support Result set naming will return an error message: "Must use ResultSetName of 'default'". Subsequent searches will be processed correctly, though, because zclient automatically switches to naming results sets as default. However, you can avoid receiving this error message entirely but adding the -d parameter to the request.

Note that there are no spaces following each of the parameters, -h, -p, and -u. The autho and password, if required, should be separated by a forward slash.

Syntax

Command:
zclient -h<hostname> -p<port> -u<autho/pwd>

NOTE: There are no spaces between the parameters (-h, -p , -u) and the values.

Example

Command: zclient -htikal.dev.oclc.org -p210 -u100118439/pxg2gxuge

Emphasis added to improve readability.

The communication or message sent by the client to the server is called the initRequest.

The server returns another communication or message called the initResponse.

The initialization is established once the client and server negotiate communication limits and features. The message at right will appear.

If the server does not support scanning or the display of available databases, it will include this information in the initResponse and display either/both messages shown at right.

Init message

Talking to port 210 of host dev.oclc.org
Done with Init request

Does not support scan message

This server indicates that it does NOT support the Scan Facility

Does not display available database message

I don't know if you have access to any dbs

Set Parameters

Select a database to search. You'll need to know how the database is known to the server. Often this name is abbreviated, such as wcat for WorldCat.

Zclient will search on the database name entered, regardless of whether it is a valid name or not. Check typing for accuracy.

If known, also set the query type and record syntax before beginning a search.

Query types supported by zclient: 0, 1 and 101.

Record formats supported by zclient: MARC, SUTRS, BER, GRS_1 and OPAC.

Create a session log

You can create a log of your session by including the verbose parameter. Simply type 'verbose' at the prompt. This creates a ZCLIENT.LOG file in the scripts subdirectory. The log records all the interactions between zclient and the target server.

To read and interpret this file, refer to the ANS.1 specification outlined in chapter four "Protocol Specification" of the ANSI/NISO Z39.50-1995 manual.

Select database

Command: db wcat

Set query type

Command: query 101

Set record syntax

Command: syntax marc

NOTE: These commands cannot be combined on one line but must be entered separately.

Basic Searching

	Search Facility Constructing a simple keyword search is straightforward in zclient. Type in the search term or phrase and specify its use and structure. The syntax is shown at right. The combination of use and structure define an index. Use corresponds to the field indexed (ie author, title, corporate name etc) and structure corresponds to how the field is indexed (keyword, phrase etc). The database ini file lists the use and structure attributes for each index. OCLC SiteSearch includes database ini files for several OCLC FirstSearch databases and many vendor databases. To create a database ini file for a different database, we advise using an existing file as a template. To get the use and structure information for OCLC FirstSearch databases, refer to FirstSearch Databases Available from OCLC's Z39.50 Server	Syntax Command: <term \| phrase>/u=<use attribute>;s=<structure attribute>
		Simple Title Search (keyword) Command: lifelong/u=4;s=2 Exact Title Search (phrase) Command: "introduction to lifelong education"/u=4;s=1 NOTE: Phrase searches require double quotes
	Results After a searchRequest has been correctly sent to the server, the server should response with a searchResponse. The postings count should appear.	Successful search Command: lifelong/u=4;s=2 5 records found Search Successful! :-) recordSyntax='null' rspTime is 149 msecs

Displaying

Records from this result set can now be viewed using the Retrieval Facility by sending a presentRequest to the server.

The Z39.50 server will respond with a presentResponse and the records will be displayed in the zclient session.

Display records

Command: d 1-2

2 records returned
Present successful
recordSyntax='1.2.840.10003.5.10'
DataDir: fldid(0) asn1class(1) form(1) length(0) count(10)
child: DataDir: fldid(0) asn1class(2) form(0) length(0) count(8)
data: 63 61 6d 20 20 20 20 20 cam
. . .

Boolean Searches

Boolean searches are constructed using Reverse Polish Notation (RPN) in zclient. In a simple boolean search, the first search term is listed (with its use and structure) followed by the second search term (with its use and structure). The boolean operator linking them is added at the end, as seen at right.

To expand on the basic search, add successive search terms followed by the associated boolean operator. Examples of more complicated searches are also shown.

Syntax

Command: <term1>/u=;s= <term2>/u=;s= <boolean operator>

Emphasis added to improve readability.

Examples

Command: education/u=1016;s=2 higher/u=1016;s=2 and

Command: education/u=1016;s=2 higher/u=1016;s=2 and computer/u=4;s=2 and

Command: education/u=1016;s=2 higher/u=1016;s=2 and computer/u=4;s=2 and college/u=21;s=2 not

The logic for the last example looks like this:

(((kw: education and kw: higher) and ti: computer) not sh: college)

Advanced Searches

	Proximity Proximity searches can be tested with zclient if the target server supports type 101 queries. 'Within' specifies order and relation. The first search term must appear first and within n terms of the second search term. 'Near' specifies only relation. The first search term must appear within n terms of the second search term in any order. For OCLC FirstSearch databases, the maximum value for 'n' is 25.	Syntax Command: <term1>/u=<>;s=<> <term2>/u=<>;s=<> within/<n> Command: <term1>/u=<>;s=<> <term2>/u=<>;s=<> near/<n> Examples Command: history/u=4;s=2 physical/u=4;s=2 within/2 3 records found Command: history/u=4;s=2 physical/u=4;s=2 within/3 23 records found Command: history/u=4;s=2 physical/u=4;s=2 near/2 3 records found Command: history/u=4;s=2 physical/u=4;s=2 near/3 24 records found

	Truncation Zclient can be instructed to submit a Truncation Attribute of '1' for Right Truncation of a search term. If the Z39.50 server supports right truncation of search terms for the specified index, the server will locate all index terms beginning with the abbreviated search term. Zclient does not use wildcards to indicate truncation. Rather, a -t parameter is added to the search string. The value of t for right truncation is '1'. The examples compare regular searches with truncated searches.	Examples Command: education/u=1016;s=2 2597 records found Command: educat/u=1016;s=2;t=1 2887 records found Command: "history of physical education"/u=4;s=1;t=1 1 records found Command: "history of"/u=4;s=1;t=1 479 records found

	Browse Facility The browse or scan feature can be tested with zclient if the target server supports this feature. As mentioned previously the server normally will indicate if it does not support scan at the start of a session. The "number of terms requested" specifies the number of terms to display. The default value is 20. The "position of search term in list" specifies where in the list to show the search term. The default value is 11.	Syntax Command: scan -<number> -<position> <term \| phrase>/u=<>;s=<> Remember to add leading dashes with no spaces before the first two parameters, "number of terms requested" and "position of search terms in list." Example Command: scan -5 -3 "history of physical education"/u=4;s=1 'history of pharmacy in pictures reproductions of a series of original' 1 'history of philosophy' 1 'history of physical education and sport in the libyan arab republic' 1 'history of piatt county' 1 'history of pike county illinois' 1

[Top]

Modifying EmailRecs.java
(Originally distributed with the May 1999 issue of InSite)

Following are instructions for customizing messages included with email of bookmarked selections.

Steps Example

1. Open <WebZ_root>/classes/ORG/oclc/obi/extverb in your text editor

Locate: StringBuffer s = new StringBuffer( );
StringBuffer s = new StringBuffer();
if (name != null && name.length() > 0)
s.append("Hello ");
if (name != null && name.length() > 0) {
s.append(name);
s.append(", ");
}
s.append("\n");
if (note != null && note.length() > 0) {
s.append(note);
s.append("\n");
}

s.append("Thanks for using WebZ. \n");
s.append("Here are the records you requested.\n\n");
s.append(message);
s.append("\nThis message was generated by BookMarkEmail.\n");

2. Edit text in the s.append methods
Substitute your institution's message
s.append("University Systems");

3. Save file then recompile
NOTE: In order for the file to successfully compile, your CLASSPATH must be set correctly.
For more information about setting the CLASSPATH variable:
Configuring the CLASSPATH Variable for UNIX or
Configuring the CLASSPATH Variable for NT.

javac EmailRecs.java

[Top]

Building a Database with a Sparse Index
(Originally distributed with the April 1999 issue of InSite)

A sparse index is a kind of shortcut for speeding searches on local Newton databases. With a sparse index, a small set of related terms is placed at the top of the postings index list. By having a sparse index at the top, the search engine locates these terms quickly and doesn't need to scan the entire postings index.

First you need to define the sparse index in the database description file. Then you actually build the database with the SSDOT utilities. As you build the database using SSDOT (see instructions below), the build software pulls the values from the sparse index and groups them at the top of the postings index.

With a little planning, you can save a lot of search time.

Keep in mind

A sparse index cannot be added to an existing database.

A sparse index must be defined in the database description file prior to building the database.

See the Documentation Zone for:

An explanation of the syntax used in adding a sparse index to the database description file.
An example of a sparse index declaration.

Steps Explanation

1. Start the database build with SSDOT.

Go to <WebZ_root>/dbbuilder/ssdot. Then type ssdot at the prompt.

2. Type "s" to set the current database.

When you are prompted to Select a registered database, type the name of the database you will build.

3. Select option 5. Advanced Options from the menu.

4. Select option 1. Initialize database.

Once the database has been initialized, and you will receive the message There are completed jobs.

5. Select option 2. Convert input data to BER-formatted records.

NOTE: If you have already converted your input data into BER, skip this step and go to step 5.

6. Select option 3. Add records to database and create index terms (Pippin).

Wait for pippin to complete processing.

7. Select option 4. Sort index terms (Sortnip).

Wait for sortnip to complete processing.

8. Select option 5. Add index terms to the database (Rome).

Wait for rome to complete processing.

9. Select option 6. Sort sparse index terms (Sortspar).

Wait for sortspar to complete processing.

10. Select option 7. Add sparse index terms to the database (Sparrome).

After sortspar completes, your database is ready to be tested.

[Top]

Adding MARC 856 to a Formatted Record Display
(Originally distributed with the March 1999 issue of InSite)

MARC field 856 includes information required for locating electronic items such as websites, ftp servers and WAIS servers. To display this information in SiteSearch, you must modify the associated formatting class for a database. The example below shows how to add an 856 method to a formatting class. It is just one of several approaches that could be used.

Steps Example

1. Verify CLASSPATH
Verify that CLASSPATH contains correct directories including
the /classes directory, the SiteSearch jar file and the JDK classes.zip file.
  See also Configuring CLASSPATH (found in the Installing and Configuring the Open SiteSearch Suite document)
>echo $CLASSPATH
  .:/ss4/classes:
  /ss4/classes/lib/SS4_0_1.jar:
  /usr/lpp/Java/lib/classes.zip

2. Locate formatting class
Locate the formatting class used to display full records.
The class is specified in the /ini/dbs/*.ini file for each database.
  See also Modifying the Display of Records in the OBI
In a NetFirst.ini file for Generic State College:
[Formats]
   full = EDU.generic.NetFirstFullFmt

3. Add method
Add the add856 method to the formatting class.
The 856 method could be added before the 'doFormat' method.
View add856 to see sample source code for this method.

4. Add call
Reference the 856 method in the 'doFormat' method.
  See NOTE below
addISSN(dir, useLabel, useTrailer);
add856(dir,[true,false]);
addLibraries(dir, useLabel);
addHoldings(dir);

5. Compile the java file
javac NetFirstFullFmt.java

6. Restart JaSSI and ZBase

NOTE to step 4:
The call to this method can be one of the following:

To display only subfield $M (13) "Contact for access assistance" information	add856(dir, false);
To create a hotlink for subfield $M (13) For instance, when the field contains only an email address, such as in the FirstSearch NetFirst database.	add856(dir, true);

[Top]

Using Statistics in JaSSI

The JaSSI server automatically tracks user statistics (one statistics file per JaSSI). These statistics are stored in the <WebZ_root>/stats directory and contain comma-delimited information. The statistic filenames are stamped with date and time stamps to help you locate the particular file that you might need. These files contain information about user sessions, including the unique session id and the user's IP address. System tasks associated with a session, such as starting a session, initializing the session, performing search/present requests, and shutting down the session, are also tracked. You can also review information about the database(s) searched, the type of searches the user performed, the number of records retrieved, and the type of record display, brief or full, requested.

To track this information in a database, most database applications will allow you to import each file into a database table. To import the data, copy the statistic file(s) and add a file extension which your application will recognize (e.g., .txt) to the end of each filename. If necessary, open the copied file(s) in a text editor and use the "Save As..." option to save the file(s) into the new format. Next, open your database and import each file into a new table as a comma-delimited file.

Note: The first row of every statistics file contains the column header information necessary for the table.

If you would like to display the statistics information in a different format (i.e., HTML), you may want to consider writing a script to convert the JaSSI statistics files into this format.

If you would like to track additional statistics information than that currently provided by the JaSSI, you can extend the ORG.oclc.stats.JaSSIUserStats class to perform additional tracking.

[Top]

Configuring the ZBroker Server in WebZ

The Open SiteSearch WebZ software can use the ZBroker server to allow external Z39.50 clients to access the ZBase server directly to perform searches. You can then search both local and remote databases by using the zclient utility to access the ZBroker server. Upon installation, the ZBroker server is not configured to immediately start with the WebZ system. Complete the following steps to configure the ZBroker server:

In the <WebZ_root>/ini/OpServe.ini file, add the ZBroker server to the [ServerType] section. This section should now resemble the following:

Configure a port in the <WebZ_root>/ini/ZBrokerServer.ini file by editing the port variable in the [ZBroker] section.

Stop and restart the WebZ system.

Start ssadmin and use the poll command to ensure that the ZBroker server is up and running.

[Top]

Using a Proprietary SQL RDBMS Server and Database with the Access Component

This procedure explains how to configure the Access component to work with a proprietary Structured Query Language (SQL) relational database management software package, such as Oracle, Sybase, or Microsoft SQL Server, on a UNIX system. The instructions below describe how to:

create an SQL database called accessdb from a sample data file.

configure a Java Database Connectivity (JDBC) driver to serve as a communications device between your SQL server software and the Access component.

configure the Access component to start with the WebZ system.

Note: Refer to the SQL software documentation for instructions regarding database system administration.

Follow the steps outlined below:

Copy the <WebZ_root>/msql/msqldb/accessdb.dump file into the location of your existing RDBMS software that you will use to maintain your authentication database.

Open accessdb.dump in a text editor. Examine the file for any mSQL notation that is not consistent with your RDBMS format. For example, the following items will need to be changed before creating a new Sybase database on UNIX with the accessdb.dump file:
- Replace the comment notation of "#" with "--".
- Change the command separator denoted as "/g" to "go".
- Replace columns of type "TEXT" to type "VARCHAR".
- Add a value of "NULL" to the end of column definitions defined as "VARCHAR" and "CHAR".
Also review all of the SQL commands (e.g., INSERT) to ensure that your RDBMS package will support the creation of the database and its tables.
Important Note: You must use the database table structure defined in the sample database for any authentication database that will be used with the Access component.

Create and initialize a new database called accessdb using your RDBMS software. Import the edited version of the accessdb.dump file into the database. Any errors that you receive at import may reflect incompatibilities between mSQL and your RDBMS software. Repeat steps 2 and 3 until the accessdb.dump file is sucessfully imported into your accessdb database.

Note: You may need to change the accessdb.dump file extension (.dump) to reflect the file extension used by your software (e.g., .sql).

Move to the <WebZ_root>/scripts directory, and open the ssmgr.hostname file, where hostname is the name of the host environment where WebZ has been installed, in a text editor. Edit the JDBCPATH variable to reflect the location of the JDBC driver for your RDBMS package. By default, this variable contains the location of the mSQL JDBC driver that is included in the WebZ package, as shown below:

JDBCPATH="$ROOTDIR/msql/classes/lib/imaginary.zip"

After editing this line to reflect the location of your RDBMS JDBC driver Java classes, save and close the file.

Move to the <WebZ_root>/ini/ directory, and open the AccessServer.ini file in a text editor. Edit the SQLDriver and URL variables in the [JDBC] section of this file to include the Java class name for the JDBC driver of your RDBMS software and the URL/protocols that the JDBC driver uses to locate the SQL server. If you are required to supply an administrative username and password to the database, add two additional variables, username and password, that supply this information. Refer to the following as an example:

Note: Every table in the database MUST be defined in the [TablePurpose] section of the AccessServer.ini configuration file for the new RDBMS software to work with the SiteSearch Access Server.

Save and close the file.

Turn on username and password authorization in the <WebZ_root>/ini/server/Access.ini file by setting the CheckNameAuthos variable to true in the [JaSSI] section.

Stop and restart the WebZ system.

Test the Access component configuration.

[Top]

The JIT, ssmgr, and SiteSearch

The Just-in-time (JIT) Compiler is a compiler that converts all of the bytecode into native machine code just as a Java program is run. This results in run-time speed improvements over code that is interpreted by a Java virtual machine. (Sun Microsystems, Inc.)

Although the JIT is intended to increase processing speed, SiteSearch has encountered various problems with the current implementations of this real-time compiler. This is especially true with the current Aix versions of the Java Development Kit (JDK).

This causes some of the following problems (each associated with communications between servers):

The mSQL server does not communicate properly with the JaSSI server. This causes the 'WebZRed' interface not to turn red.

In 'ssadmin' - the server sessions are not listed properly

In 'ssadmin' - it is not possible to 'term' servers

In 'ssadmin' - it is not possible to 'settrace' levels for servers

We have several workarounds to this problem:

One solution is to terminate SiteSearch, turn off the JIT, and restart SiteSearch. After terminating current SiteSearch servers, you can type the following on the command line:

       setenv JAVA_COMPILER

Note: This only works for your current Unix or NT session and does not remain as a permanent workaround.

The next and suggested solution is to specify that the JIT be turned off when starting the SiteSearch servers.

In your ".../scripts/ssmgr.(host name)" file, you can set a system property using a "-D" flag (you can see this option in the Java usage statement). The following should be added to each server startup section:

       -Djava.compiler=NONE

The "ssmgr.(host name)" file should look something like this:

  echo "Starting AccessServer"
  java -Djava.compiler=NONE ORG.oclc.access.server.AccessServer $ROOTDIR/ini/AccessServer.ini &
  ;;     
 jassi) 
  echo "Starting JaSSI"
  java -Djava.compiler=NONE ORG.oclc.jassi.JaSSI $ROOTDIR/ini/JaSSIServer.ini &

Note: This should be done for each of the SiteSearch servers.

You will need to also edit the ".../scripts/ssadmin" file to disable the JIT.

The ".../scripts/ssadmin" file should look like this:

   echo "Starting SSAdmin"
   echo "java -Djava.compiler=NONE ORG.oclc.opserve.tty.SSAdmin $ROOTDIR/ini/SSAdmin.ini"

Note: In our testing at OCLC, we have noticed no appreciable difference in response times between enabling and disabling the JIT while using SiteSearch 4.0.x and JDK 1.1.x

[Top]

Displaying DRA Holdings Information

DRA utilizes a separate database, "CIRCLE_ITEM_FILE", to store holdings information. SiteSearch WebZ 4.0.2 can be configured to utilize information in this database to display holdings within the full record display for records from DRA's Z39.50 server.

In the ".../ini/interface/DisplayGadgets.ini" file, you will want to change the following section:

  # Record display formatting for Full Display records
  [FullRecord]
  gadget    = ORG.oclc.gadgets.FormatRecords
  fmtclass  = full

to this:

  # Record display formatting for Full Display records
  [FullRecord]
  gadget            = ORG.oclc.gadgets.FormatRecordsAndAttachHoldings
  fmtclass          = full
  SearchKeyFmtClass = holdingsKey

The following information should already be configured in the sample files provided with SiteSearch 4.0.2:

.../ini/dbs/DRA.ini:

   [database]
   ZBaseDbType    = ORG.oclc.db.DbRemoteZ
   ... 
   HoldingsDbName = DRANETHOLDINGS

.../ini/dbs/DRAHoldings.ini:

   [database]
   ZBaseDbType   = ORG.oclc.db.DbRemoteZ
   dbName        = DRANETHOLDINGS
   remoteZDbName = CIRCLE_ITEM_FILE
   Longname      = DRA Holdings
   recordSyntax  = DRA_HOLDINGS
   SupportsSort  = false
   SupportsScan  = false
   ServerName    = DRA
   ServerIniFile = servers/DRA.ini
   HideInMenus   = true
   ...

and both databases should be listed somewhere in the ".../ini/databases.ini" file:

   ...
   db* = dbs/DRA.ini
   db* = dbs/DRAHoldings.ini
   ...

After these changes have been made, you will need to restart SiteSearch to view the DRA holdings information.

Also, we have a bug fix that improves the display of MARC Holdings fields more completely and consistently. Please see "BR058: The WebZ Formatting Classes Do Not Parse/Display MARC Holdings Information Correctly" for information regarding applying this fix.

[Top]

Configuring Automatic AutoSort

SiteSearch WebZ can be configured to automatically request that a result set be sorted by specifying sort parameters. You will need to edit the appropriate search html file in the FORM section to reflect the changes you want. You will need add values for the "key" and "direction" variables to this section in order to instruct the server which field to sort on and in which direction.

Here is a modified ".../htdocs/html/advancedsearch.html" file which will send a sortRequest to sort the result set on 'Date' in Descending order and 'Title' in an Ascending order:

    ...
    <FORM METHOD="POST" ACTION="/WebZ/AdvancedQuery:&context;"    
      &StyleTable.targets.searchResults;>
    <input type="hidden" name="next" value="&StyleTable.pages.searchResults;">
    <input type="hidden" name="bad" value="&StyleTable.pages.badquery;">
    <input type="hidden" name="entitytoprecno" value="1">
    <input type="hidden" name="entitycurrecno" value="1">
    <input type="hidden" name="entitytempjds" value="TRUE">
    <input type="hidden" name="dbgroup" value="&dbgroup;">
    <input type="hidden" name="key1" value="Date">
    <input type="hidden" name="direction1" value="d">
    <input type="hidden" name="key2" value="Title">
    <input type="hidden" name="direction2" value="a">
    ...

You will need to examine the current value of "maxSortRecords" and "maxAutoSortRecords" in the individual ".../ini/dbs/*.ini" files and configure values appropriate for your SiteSearch installation.

Note: With higher threshold values, the response times of searches will increase, especially with large result sets.

Current default values are:

   ...
   maxSortRecords     = 200
   maxAutoSortRecords = 50
   ...

Also, you will probably want to remove the Auto Sort gadget (i.e., "&StyleTable.Sort.gadget;") from the ".../htdocs/html/advancedsearch.html" file so that this option no longer displays on this search page.

[Top]

References

Product Support FAQ

[Home] [Documentation] [Support] [Search]

Last Modified:

Steps		Example
1.	*Open <WebZ_root>/classes/ORG/oclc/obi/extverb in your text editor* Locate: StringBuffer s = new StringBuffer( );	StringBuffer s = new StringBuffer(); if (name != null && name.length() > 0) s.append("Hello "); if (name != null && name.length() > 0) { s.append(name); s.append(", "); } s.append("\n"); if (note != null && note.length() > 0) { s.append(note); s.append("\n"); } s.append("Thanks for using WebZ. \n"); s.append("Here are the records you requested.\n\n"); s.append(message); s.append("\nThis message was generated by BookMarkEmail.\n");
2.	Edit text in the s.append methods Substitute your institution's message	s.append("University Systems");
3.	Save file then recompile NOTE: In order for the file to successfully compile, your CLASSPATH must be set correctly. For more information about setting the CLASSPATH variable: Configuring the CLASSPATH Variable for UNIX or Configuring the CLASSPATH Variable for NT.	javac EmailRecs.java

Steps		Explanation
1.	Start the database build with SSDOT.	Go to <WebZ_root>/dbbuilder/ssdot. Then type ssdot at the prompt.
2.	Type "s" to set the current database.	When you are prompted to Select a registered database, type the name of the database you will build.
3.	Select option 5. Advanced Options from the menu.
4.	Select option 1. Initialize database.	Once the database has been initialized, and you will receive the message There are completed jobs.
5.	Select option 2. Convert input data to BER-formatted records.	NOTE: If you have already converted your input data into BER, skip this step and go to step 5.
6.	Select option 3. Add records to database and create index terms (Pippin).	Wait for pippin to complete processing.
7.	Select option 4. Sort index terms (Sortnip).	Wait for sortnip to complete processing.
8.	Select option 5. Add index terms to the database (Rome).	Wait for rome to complete processing.
9.	Select option 6. Sort sparse index terms (Sortspar).	Wait for sortspar to complete processing.
10.	Select option 7. Add sparse index terms to the database (Sparrome).	After sortspar completes, your database is ready to be tested.

Steps		Example
1.	Verify CLASSPATH Verify that CLASSPATH contains correct directories including the /classes directory, the SiteSearch jar file and the JDK classes.zip file. See also Configuring CLASSPATH (found in the Installing and Configuring the Open SiteSearch Suite document)	>echo $CLASSPATH .:/ss4/classes: /ss4/classes/lib/SS4_0_1.jar: /usr/lpp/Java/lib/classes.zip
2.	Locate formatting class Locate the formatting class used to display full records. The class is specified in the /ini/dbs/.ini file for each database. See also* Modifying the Display of Records in the OBI	In a NetFirst.ini file for Generic State College: [Formats] full = EDU.generic.NetFirstFullFmt
3.	Add method Add the add856 method to the formatting class. The 856 method could be added before the 'doFormat' method.	View add856 to see sample source code for this method.
4.	Add call Reference the 856 method in the 'doFormat' method. See NOTE below	addISSN(dir, useLabel, useTrailer); add856(dir,[true,false]); addLibraries(dir, useLabel); addHoldings(dir);
5.	Compile the java file	javac NetFirstFullFmt.java
6.	Restart JaSSI and ZBase