If you notice any GSE related functions in the trace
(they will have the letters GSE in them), look at the first entry in the GSE queue
and the referenced entry in the events database. Most of the time, the event referred
to in the GSE entry is the offending entry. To fix this problem:

If the entries are not corrupted, then it could be a special case that
the calendar server could not handle.

Take the following steps:

Take a calendar environment snapshot of the corrupted database, and contact
customer support.

To create an environmental backup:

Use the db_checkpoint utility found at:

cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint

Run db_archive -s.

Use the -s option to identify all the database files and copy them to a removable
medium, such as CD, or DVD, or tape.

Run db_archive -l.

Use the -loption to identify all the log files and copy unapplied log files to a removable-medium
device.

To avoid service interruptions, place your calendar database into a read-only
state temporarily, and revert to a hot backup copy.

Placing your calendar database into a read-only state temporarily
prevents any add, modify or delete transactions from taking place. End users will
get an error message when they try to add, modify or delete any calendar data. Administrator
tools that add, modify or delete calendar events and todos also will not work while
the database is in read-only mode.

To put your calendar database in read-only
mode, edit the ics.conf file and set the following parameter to “yes”, as shown:

With csstored configured and enabled, a hot backup is available that should be
within minutes of being up-to-date. You should always verify your hot backup copy
to make sure it is not corrupt also. (Run db_verify.)

If all else fails, perform the dump and reload procedure to see if it
can salvage the database.