1. Select "1" from the SSDOT main menu and press Enter to move to the Database Registration menu.

2. Select "1" from the Database Registration menu and press Enter to add a new database to the environment.

3. When prompted by SSDOT, type the registration name of the database at the command prompt (">") and press Enter. The database name must be between 1 and 8 alphanumeric characters with no spaces. Use this name to reference the database from this point forward while working with the database within the Open SiteSearch 4.0 software.

After you have completed this step, the Registration Information screen will appear. Refer to the sample screen below.

4. Review the Registration Information screen shown in step 3 to ensure that all of the items listed contain the correct information about your database. Pay particular attention to item number 13, Format of raw data, to verify that this information reflects the format of your database source data. Refer to the Database Registration Information table below for an explanation of each of the categories contained on the Registration Information screen.

To change any of the information listed in the database registration information, type the number of the option you want to change at the command prompt (">") and press Enter. SSDOT will prompt you with the current value of the option and/or a list of possible options. Make any necessary changes to the information and press Enter.

When all of the information is correct, type "s" and press Enter to save the information and exit. When prompted, press the space bar to return to the Database Registration screen.

If you wish to exit the registration process without saving any of the information about the database, type "x" and press Enter.

[1] Long database name.

This is the human-readable name of the database, such as "WorldCat Database" or "ERIC Database" and is different from the registered database name. This name is displayed by SSDOT at the top of the screen to show you which database in SSDOT is active.

[2] Directory containing executables.

This is the directory containing the executable files (pippin, rome, ber2txt, etc.) SSDOT uses when building and maintaining databases. SSDOT needs to know where these programs are located in order to execute them. By default, SSDOT expects all executable files to be located in one directory.

[3] Directory containing .dsc.

This is the directory in which the database description (.dsc) file resides. SSDOT uses the .dsc file when building the database, and also rewrites the file when the database is grown. SSDOT expects the .dsc file to have the form dbname.dsc, where dbname is the registered name of the database.

[4] BER directory.

This is the directory where ASN.1/BER files created by SSDOT will reside. SSDOT takes raw data files, converts them to ASN.1/BER, and then places them in this directory. Future commands which need to read ASN.1/BER files will look for them in this directory.

[5] Directory for log files.

The SSDOT processes write out log files that you may later examine. This variable specifies the directory to which the log files are written.

[6] Directory for NIP and SNIP files.

NIP and SNIP files are intermediate files produced during database builds. This variable specifies the directory to which the files are written.

[7] HDIR File Directory.

The HDIR file is one of five physical database files that constitutes the database. This variable indicates in which directory the file will reside.

[8] HEDR File Directory.

Same as HDIR File Directory, but for the HEDR file.

[9] INDX File Directory.

Same as HDIR File Directory, but for the INDX file.

[10] PDIR File Directory.

Same as HDIR File Directory, but for the PDIR file.

[11] POST File Directory.

Same as HDIR File Directory, but for the POST file.

[12] Directory for backups.

SSDOT provides facilities for making backups of the database files. This variable specifies which directory will house the backup files.

[13] Format of raw data.

This variable specifies the format of the source data for the database. You will be presented with a list of data formats known to this current SSDOT environment and must choose which type of conversion will be performed. An incorrect format will result in database build errors.

For example, choosing SGML conversion would tell SSDOT that the source data files will be in SGML format. SSDOT will use the sgmlconv utility, which requires a database tag definition (.dtd) file, to convert the data to ASN.1/BER format when you update the database.

[14] Percentage to grow database by.

This variable specifies the percentage to grow the database. If the database is being built and the space needed for any of the database files exceeds the amount allocated in the .dsc file, SSDOT will use the percentage value listed here to grow the database files. This value prevents an error from occurring during the database build.

[15] Maximum number of lines in history file.

SSDOT keeps a record of changes and commands executed in the history file. This variable specifies the maximum number of lines the history file can hold. There is one history file per database.

[16] Number of old BERs to keep.

This variable specifies whether or not SSDOT should automatically delete older BER files after creating a new one, and how many older files should be kept. Specifying "all" would cause SSDOT to never delete old BER files, while specifying "2" would cause SSDOT to keep only the two most recent files and delete any older files.

[17] Number of old backups to keep.

This variable specifies whether or not SSDOT should automatically delete older backup files after creating a new one, and how many older files should be kept. Specifying "all" would cause SSDOT to never delete old backup files, while specifying "2" would cause SSDOT to keep only the two most recent files and delete the older files. By keeping at least one backup file, you will be able to load and use an older version of the database if something in the current version goes wrong so that you do not have to rebuild the entire database from the beginning.

[18] Pippin table directory.

This variable tells SSDOT in which directory the table file for this database is located. The pippin utility has an option that allows the specification of collapsible characters, user-defined delimiters, and replacement strings with the use of table files. The table file itself must have the name dbname.tbl, where dbname is the name of the database as described in #1 above. The table file lists the diacritics that are used in the source data and the appropriate ASN.1/BER character mapping that the SiteSearch system will need to handle during conversion. If you do not wish to use a table file, this parameter may be left blank.

See the Pippin Tablefile Parameter document that describes the table file, or character file, in more detail.

[19] Automatic backup before build.

This variable specifies whether or not to automatically create a backup of the database before updating the database. It is strongly recommended that you manually create a database backup file instead of using this automatic backup option. By manually performing the backup, you can ensure each time that you have enough disk space available to create a backup file and that the database has been built or updated correctly before making a copy of it.

By selecting "y" for this variable, the value will be set to "ENABLED." By selecting "n" for this variable, the value will be set for "disabled." The default recommended value is "disabled."

[20] Automatic verification after build

This variable specifies whether or not to automatically verify the database integrity after an update. By selecting "y" for this variable, the value will be set to "ENABLED." By selecting "n" for this variable, the value will be set for "disabled." The default value is "disabled."

[21] Include BER files when making backups.

This variable specifies whether or not to save all ASN.1/BER conversion files as part of a backup. If enabled, ASN.1/BER files will be saved as part of the database backup file. If disabled, only those ASN.1/BER files that have not yet been added to the database will be included in the backup. If at any time, you have to rebuild the database from scratch, you will need the ASN.1/BER files to recreate the database. By selecting "y" for this variable, the value will be set to "ENABLED." By selecting "n" for this variable, the value will be set for "disabled." The default value is "disabled."