Hi,

I've never tested such thing in a real world scenario.

In the script you need to make a copy of the LTAPEDEV-file
right after the end of the "ontape -a" command has finished.

As logs are filled strictly serially, this will work for a normal
scenario.

However, I'm not sure what will happen if the log backup is
slower than the logs fill. The log-complete event will trigger
the ALARMPROGRAM, I think even while a log backup is
currently running. ON-Bar detects the situation where
another ON-Bar log backup process is already running.
But with ontape I'm not really sure. And if it does not, then
I don't (want to) know what happens with the LTAPEDEV file ...

Also, there's a gap between finish of "ontape -a" and the
completion of the copy command. If you get the next "ontape -a"
starting its log backup before the previous logs LTAPEDEV
has been copied ... then you lost a log file backup.

You can work around these problems in the log_full.sh script
by adding some logic (e.g. lock mechanism with a lock file).
You'd have to lock the lock file before starting the
"ontape -a" and then release the lock only after the copy
of the LTAPEDEV file has completed. And if the lock file
is locked (by some other already running process), then
you have to either wait or (maybe better) exit the log_full.sh
script.
Only with such provisions would I trust the mechanism
somewhat. Note that it still leaves holes, like when the
copy goes wrong for some reason (file system full). You'd
have to work out such issues as well ...

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

owner-informix-list@iiug.org wrote on 09.12.2005 18:26:22:
> "Superboer" <superboer7@planet.nl> schrieb:
>
> >ahum most likely in log_full.sh which is configured as
> >alarmprogram in $ONCONFIG.
> >
> >having this is a recept for disaster...
>
> Please explain. What's wrong with calling "ontape -a" from log_full.sh?
>
> Regards, Richard
sending to informix-list