An example (for FATMEN) can be found here.
(To create the final RZ file in exchange mode in the "NEW" format (see ZEBRA manual under RZMAKE), use CHOPT='XN').

Restore the more recent online backup from /cdback/cd{experiment}/*.good

Then 'mv' the necessary update files from /hepdb/cd{experiment}/save to /hepdb/cd{experiment}/todo and restart the server.

If surgery is required on the RZ file, best wait for an expert.

Best wait for an expert.

Explanation of HEPDB files

• BAD directory

  This directory is used by the server to store update files that are not valid HEPDB update files. Usually happens when a user application writes to the unit reserved for HEPDB updates.

• *.DBS files

  ZEBRA-RZ files containing one of the HEPDB database for the corresponding experiment.

• SAVE directory

  After processing, updates are 'mv-ed' to this directory (which is often/normally a link to another filesystem). Update files are kept to enable recovery from corrupted catalogs. They are automatically deleted a cleanup script.

• LOGS directory

  The directory where log files are kept. Again, often a link.

• CDSERV.LOG

  The server log file.

• CDSERV.SH

  The shell script that runs the server.

• CDSRV

  A link to the HEPDB server.

• HEPDB.NAMES

  A configuration file. See the documentation for more information.

• TOxxx.yyy.zz directories

  Directories where updates are queued to remote sites. See the documentation for more information.

• TODO directory

  The directory where user updates are queued. Processed by the CDSRV process.

HEPDB programs and scripts

These are kept in the directory /afs/cern.ch/project/hepdb/@sys/bin and /afs/cern.ch/project/hepdb/scripts.

Programs

ls /afs/cern.ch/project/hepdb/@sys/bin
cdbackup  cdmove    cdsrv

• CDBACKUP

  A program run every night to backup the HEPDB databases.

• CDMOVE

  The program responsible for transferring updates between different HEPDB servers (e.g. at CERN and IN2P3).

• CDSRV

  The HEPDB server itself.

Scripts

The scripts contain a brief comment explaining their function and are described in the user documentation.

Many are run from cron as user root.

#
# Backup database files
#
0 23 * * * /afs/cern.ch/project/hepdb/scripts/cdbackup.sh > /dev/null 2>&1
#
# Look for servers that are stopped
#
0 8 * * * /afs/cern.ch/project/hepdb/scripts/cdchk > /dev/null 2>&1
#
# More powerful check
#
20 * * * * /afs/cern.ch/project/hepdb/scripts/cdcheck > /dev/null 2>&1
#
# Check for backlogs
#
# TGB - fixed syntax error
#
0 0 * * * /afs/cern.ch/project/hepdb/scripts/cdqueue > /dev/null 2>&1
#
#
# Special check for cdmove
#
30 * * * * /afs/cern.ch/project/hepdb/scripts/cdmovechk >> /tmp/cdmovechk.log 2>&1

Y2K Information

Like many CERNLIB programs, HEPDB relies on the DATIME routine to handle dates and times. As is described here, this routine returns the date in YYMMDD format through the argument list.

Calibration data entered into HEPDB are given a validity range that consists of one or more pairs of integers. HEPDB makes no assumptions as to these integers - they may be start and end run, run and event, time or any other range.

HEPDB stores the insertion time of each entry in a packed format. The insertion time may be overridden by the user, but by default is obtained using the DATIME routine described above.

Modifications to support Y2K have been received from Rob Komar and tested. Thanks Rob!