Any time a customer calls in with a problem, the first thing to realize is
that no errors will(should) be displayed to the users screen. Any/all errors
that OnBar encounters will be sent to the Onbar Activity Log. The location
of the activity log is specified by the BAR_ACT_LOG onconfig parameter (see
Onbar onconfig parameters). The customer may
also see errors in the online log, however the bar activity log may be more
useful in explaining why OnBar is having some problems.

If reviewing the onbar log is simply not enough to solve the problem
and additional debugging is required then online has some built in
debugging features.

There are 2 onconfig parameters that can assist us.
BAR_DEBUG and BAR_DEBUG_LOG can be set so that a specified amount of
debugging information can be sent to the debug file while onbar is running.
This information has proven to be extremely useful when isolating where/how
problems are occuring.

BAR_DEBUG=2 - This will basically dump a message to the debug
file every time onbar goes into a funtion. It also dumps a messaage
to the log every time is exits a function along with that
functions return code.

BAR_DEBUG=4 - This will have Onbar dump information about Onbar
doing parallel operations.

BAR_DEBUG=5 - This will have Onbar dump information about objects
that are being backed up/restored. Also dump info from the act_node
structure which corresponds with the bar_action table.

BAR_DEBUG=6 - Same as Number 5.

BAR_DEBUG=7 - Onbar dump the contents of the ins_node structure,
which corresponds with the bar_instance table. Also displays
modifications to the bar_action table. Shows info about logical
logs that are to be restored. Displays the list of objects that
need to be restored. SQL statements that are done on the sysutils
database along with some SQLCODES that were returned.

BAR_DEBUG=8 - Onbar will dump that page header of ALL pages that
it archives/restores. WARNING This will take quit a bit of space.

BAR_DEBUG=9 -Dumps the contents of the bar_ins structure after
it had been initialized. Dumps the contents of the obeject descriptors
that are to restored during acold restore.

TIPS

I ususally set BAR_DEBUG either 9 or 7 under the following curcumstances.

BAR_DEBUG = 7 If OnBar fails some time after it starts
processing pages. This way we dont fill up the log with page
headers from BAR_DEBUG=8.

BAR_BUG = 9 If the Onbar fails before is starts processing pages.
That way we get as much info as possible without all the page headers.
Another reason for setting BAR_DEBUG=9 is if you need to verify
wether a page is getting archived/restored. You can then just scan
the file looking for that particular page.

Once again this should be used by technical support or R&D scince the output
generated from this is generally not something that a customer would be able
to understand. This feature should show us exactly where in the OnBar source
we are startting to fail or go wrong.

If Onbar encounters a problem that prevents it from doing its job, an
error number should be sent to the BAR_ACT_LOG. This error number can
have many different meanings depending on where it was encountered. Error
messages that are sent to the BAR_ACT_LOG can come from 4 different places.