Re: Need Help with recovery of 7.31

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