Based on a recommendation from Informix, our DBA's recently starting doing
onbar -b -w instead of onbar -b -L 0.  I don't know the details but you
might check with Informix.

On Mon, 25 Jan 1999, Hayes, Doug wrote:

> Platform Versions:
> IDS 7.24.UC1
> AIX 4.3.2
> ADSM Server Version 3, Release 1, Level 1.5
> ADSM Client Version 2, Release 1, Level 0.6
>
> I have been performing backup and recovery testing under various scenarios
> with unpredictable results using the above configuration. I have been
> performing onbar -b -L 0 and onbar -b -L 1 backups while using onbar -r -n
> <logid> for my restore. I performed my first restore and several dbSpaces
> were not restored (I did not have entries in either the online.log or
> bar_act.log for these dbSpaces). The dbSpaces were marked down after the
> restore. I was told by Informix support that the following error messages in
> my bar_act.log indicated a CRITICAL failure during my backup:
>
> 1999-01-19 21:49:32 43090  16884 ERROR: Unable to open connection to server:
> could not fork server connection.
> 1999-01-19 21:49:32 16884  12948 The ON-Bar process 43090 exited with a
> problem (exit code 130 (0x82), signal -1).
>
> These critical failures created a corrupt backup for the entire server. To
> complicate matters the onbar command issued (onbar -b -L 1) returned with a
> return code of 0. I was told this was to be expected!
>
> Has anyone else experienced these types of problems? What did you do to work
> around the issue?
>
> I also find it unusual that onbar will not wait for additional ADSM server
> resources to come available. I was told to control this by lowering the
> BAR_MAX_BACKUP onconfig parameter. I have found this to be difficult as the
> number of available ADSM resources can change from time to time. Does anyone
> have any ideas for this issue?
>
> Thanks In Advance,
> Doug Hayes
> DBA, Senco Products Inc
> Dhayes AT senco DOT com
>
>
>
>
>