Problems with fbackup after Y2K-Installation for HP-UX 10.20

[Gian antonio D'addetta_3]

Hi,

since i updated our HP-UX 10.20 systems by the last Y2K Patch bundle i have
some problems with the fbackup command within the sam script
/usr/sam/lbin/br_backup. Before updating the systems the automated backup
through the above script produced some warnings (mainly due unreadable active
or open files) and exited with an error code of '0', representing a 'normal
completion' according to the manual. But since the installation of the Y2K
patches with the same amount of warnings i get an exit code of '4',
representing the situation 'if any warning conditions are encountered'.
Therefore i get the message that the backup has failed.
Further within the logfiles the inclusion of the file space for each file path
is noted, thus increasing the logfile size tremendously.

Does anyone know what has been changed through the Y2K patches within fbackup
or the br_backup scripts or where to get information about this changes? I
controlled the patch documentation, but could not find any information about
changes concerning this topic.
It's important for me to know this in order to assure a save backup. I should
mention that this happens on two independent automated backups on two different
machines.

Bye
Gian Antonio

[Dan Hull]

A new exit code (4) was added to the fbackup program. This is an informational
code only, and does not indicate any problems with the backup. Unfortunately,
SAM has not been modified to account for the new code!

To work around the problem, change line 329 of the /usr/sam/lbin/br_backup
script to accept either exit code 0 or 4 as 'success':

if ["$exit_code" = "0" -o "$exit_code" = "4" ]

Note: See online support document KBRC00000151 for a detailed explanation on
'exit code 4'.

[Chris Vann]

This sure sounds a lot like the problem we had with tar! We loaded patches &
then our script failed. Tar returned a 5 instead of a 0 if it had anything to
complain about. (owners of files not on box...) The tar patch "fixed" it
because before it just printed an error & returned 0. Now it returns a non-zero
if it printed any errors. We put our old tar file back in place for a quick fix
& changed our scripts later, then we fixed the scripts for either return code
& reinstalled the new tar.