Logical Log files MISSING

Hello, IDS 11.10.FC2W4 on solaris 10 Ontape for backing up of logical log files to a directory using the alarmprogram.sh script I see that manyyy logical log files are missing from the logical log backup directory.. -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020073 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020074 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020075 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020076 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020077 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020078 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020079 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020080 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020081 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020082 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020083 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020085 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020086 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020087 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020088 i checked in onstat -l and found that log with uniqid a3180d77e0 142 U-B---- 20066 5:1290053 10000 10000 100.00 a3180d7848 143 U-B---- 20067 5:1300053 10000 10000 100.00 a3180d78b0 144 U-B---- 20068 5:1310053 10000 10000 100.00 a3180d7918 145 U-B---- 20069 5:1320053 10000 10000 100.00 a3180d7980 146 U-B---- 20070 5:1330053 10000 10000 100.00 a3180d79e8 147 U-B---- 20071 5:1340053 10000 10000 100.00 a3180d7a50 148 U-B---- 20072 5:1350053 10000 10000 100.00 a3180d7ab8 149 U-B---- 20073 5:1360053 10000 10000 100.00 a3180d7b20 150 U-B---- 20074 5:1370053 10000 10000 100.00 a3180d7b88 151 U-B---- 20075 5:1380053 10000 10000 100.00 a3180d7bf0 152 U-B---- 20076 5:1390053 10000 10000 100.00 a3180d7c58 153 U-B---- 20077 5:1400053 10000 10000 100.00 a3180d7cc0 154 U-B---- 20078 5:1410053 10000 10000 100.00 a3180d7d28 155 U-B---- 20079 5:1420053 10000 10000 100.00 a3180d7d90 156 U-B---- 20080 5:1430053 10000 10000 100.00 a3180d7df8 157 U-B---- 20081 5:1440053 10000 10000 100.00 a3180d7e60 158 U-B---- 20082 5:1450053 10000 10000 100.00 a3180d7ec8 159 U-B---- 20083 5:1460053 10000 10000 100.00 a3180d7f30 160 U-B---- 20084 5:1470053 10000 10000 100.00 a3180d7f98 161 U-B---- 20085 5:1480053 10000 10000 100.00 a3180d8028 162 U-B---- 20086 5:1490053 10000 10000 100.00 a3180d8090 163 U-B---- 20087 5:1500053 10000 10000 100.00 a3180d80f8 164 U-B---- 20088 5:1510053 10000 10000 100.00 So the Logical log 20084 is missing from the logical log backup directory. and there are manyyyy more... Plssss let me know what could be the reason and what more do i have to look for. the logical log directory has RWX to user and group informix and no other than the dbas so at first i dont think any one would delete that log. any idea what should i do with this ....

While looking for your logical log, I would immediately start an archive so you have a recovery point from this point forward. Take care. Clifton M. Bean Informix DBA / AIX System Admin Currency Technics & Metrics Main (972) 812-1411 x244 -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of VIKAS HIVARKAR Sent: Friday, October 10, 2008 12:02 PM To: ids@iiug.org Subject: Logical Log files MISSING [13673] Hello, IDS 11.10.FC2W4 on solaris 10 Ontape for backing up of logical log files to a directory using the alarmprogram.sh script I see that manyyy logical log files are missing from the logical log backup directory.. -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020073 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020074 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020075 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020076 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020077 -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020078 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020079 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020080 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020081 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020082 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020083 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020085 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020086 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020087 -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020088 i checked in onstat -l and found that log with uniqid a3180d77e0 142 U-B---- 20066 5:1290053 10000 10000 100.00 a3180d7848 143 U-B---- 20067 5:1300053 10000 10000 100.00 a3180d78b0 144 U-B---- 20068 5:1310053 10000 10000 100.00 a3180d7918 145 U-B---- 20069 5:1320053 10000 10000 100.00 a3180d7980 146 U-B---- 20070 5:1330053 10000 10000 100.00 a3180d79e8 147 U-B---- 20071 5:1340053 10000 10000 100.00 a3180d7a50 148 U-B---- 20072 5:1350053 10000 10000 100.00 a3180d7ab8 149 U-B---- 20073 5:1360053 10000 10000 100.00 a3180d7b20 150 U-B---- 20074 5:1370053 10000 10000 100.00 a3180d7b88 151 U-B---- 20075 5:1380053 10000 10000 100.00 a3180d7bf0 152 U-B---- 20076 5:1390053 10000 10000 100.00 a3180d7c58 153 U-B---- 20077 5:1400053 10000 10000 100.00 a3180d7cc0 154 U-B---- 20078 5:1410053 10000 10000 100.00 a3180d7d28 155 U-B---- 20079 5:1420053 10000 10000 100.00 a3180d7d90 156 U-B---- 20080 5:1430053 10000 10000 100.00 a3180d7df8 157 U-B---- 20081 5:1440053 10000 10000 100.00 a3180d7e60 158 U-B---- 20082 5:1450053 10000 10000 100.00 a3180d7ec8 159 U-B---- 20083 5:1460053 10000 10000 100.00 a3180d7f30 160 U-B---- 20084 5:1470053 10000 10000 100.00 a3180d7f98 161 U-B---- 20085 5:1480053 10000 10000 100.00 a3180d8028 162 U-B---- 20086 5:1490053 10000 10000 100.00 a3180d8090 163 U-B---- 20087 5:1500053 10000 10000 100.00 a3180d80f8 164 U-B---- 20088 5:1510053 10000 10000 100.00 So the Logical log 20084 is missing from the logical log backup directory. and there are manyyyy more... Plssss let me know what could be the reason and what more do i have to look for. the logical log directory has RWX to user and group informix and no other than the dbas so at first i dont think any one would delete that log. any idea what should i do with this .... ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

yes even i am thinking about the same but my last level 0 was sucssfully completed This tape contains the following logical logs: 20426 Program over. Thu Oct 9 07:11:50 CEST 2008: Level0 Backup Ending. and i have checked one by one all the logical logs from 20426 till now, nothing is missing and hopefully there is no more logical log missing. Dont know why there are so many missing logs,could it be some OS issue or yet another bug?

Hello I’ve checked the online.log file for one of the missing log 20084 23:12:22 Logical Log 20083 Complete, timestamp: 0x8e06d245. 23:12:22 Logical Log 20084 Complete, timestamp: 0x8e06d245. 23:12:22 Logical Log 20083 - Backup Started 23:12:23 Logical Log 20083 - Backup Completed 23:12:23 Logical Log 20084 - Backup Started 23:12:23 Logical Log 20084 - Backup Completed 23:12:26 Logical Log 20085 Complete, timestamp: 0x8e0948db. 23:12:26 Logical Log 20085 - Backup Started 23:12:27 Logical Log 20085 - Backup Completed 23:12:30 Logical Log 20086 Complete, timestamp: 0x8e0bd192. 23:12:30 Logical Log 20086 - Backup Started 23:12:31 Logical Log 20086 - Backup Completed And the online.log is showing that its backup was completed successfully but on disk there is no file for 20048 and many more. Pls Help !

Dude I bet that you are overwritting your log files - not a bug, just bad timing. Mike

On second thought... I just read about backing up logs to a directory with ontape, I didn't know about that feature. Nevermind... nothing to see here. Move along. MM

ids-bounces@iiug.org wrote on 10/10/2008 10:01:44 AM: > Hello, > > IDS 11.10.FC2W4 on solaris 10 > > Ontape for backing up of logical log files to a directory using the > alarmprogram.sh script > > I see that manyyy logical log files are missing from the logical log backup > directory.. > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020073 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020074 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020075 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020076 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020077 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020078 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020079 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020080 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020081 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020082 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020083 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020085 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020086 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020087 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020088 > > i checked in onstat -l and found that log with uniqid > > a3180d77e0 142 U-B---- 20066 5:1290053 10000 10000 100.00 > a3180d7848 143 U-B---- 20067 5:1300053 10000 10000 100.00 > a3180d78b0 144 U-B---- 20068 5:1310053 10000 10000 100.00 > a3180d7918 145 U-B---- 20069 5:1320053 10000 10000 100.00 > a3180d7980 146 U-B---- 20070 5:1330053 10000 10000 100.00 > a3180d79e8 147 U-B---- 20071 5:1340053 10000 10000 100.00 > a3180d7a50 148 U-B---- 20072 5:1350053 10000 10000 100.00 > a3180d7ab8 149 U-B---- 20073 5:1360053 10000 10000 100.00 > a3180d7b20 150 U-B---- 20074 5:1370053 10000 10000 100.00 > a3180d7b88 151 U-B---- 20075 5:1380053 10000 10000 100.00 > a3180d7bf0 152 U-B---- 20076 5:1390053 10000 10000 100.00 > a3180d7c58 153 U-B---- 20077 5:1400053 10000 10000 100.00 > a3180d7cc0 154 U-B---- 20078 5:1410053 10000 10000 100.00 > a3180d7d28 155 U-B---- 20079 5:1420053 10000 10000 100.00 > a3180d7d90 156 U-B---- 20080 5:1430053 10000 10000 100.00 > a3180d7df8 157 U-B---- 20081 5:1440053 10000 10000 100.00 > a3180d7e60 158 U-B---- 20082 5:1450053 10000 10000 100.00 > a3180d7ec8 159 U-B---- 20083 5:1460053 10000 10000 100.00 > a3180d7f30 160 U-B---- 20084 5:1470053 10000 10000 100.00 > a3180d7f98 161 U-B---- 20085 5:1480053 10000 10000 100.00 > a3180d8028 162 U-B---- 20086 5:1490053 10000 10000 100.00 > a3180d8090 163 U-B---- 20087 5:1500053 10000 10000 100.00 > a3180d80f8 164 U-B---- 20088 5:1510053 10000 10000 100.00 > > So the Logical log 20084 is missing from the logical log backup directory. > and there are manyyyy more... > Plssss let me know what could be the reason and what more do i have to look > for. This is a bug that is fixed in 11.50xC3 The problem is that when log files are filled rapidly (matter of seconds) and the alarmprogram.sh is used to perform automatic ontape backup to directory, the alarmprogram.sh which invokes ontape may cause ontape to run when there, is already another ontape running that is backing up a logfile to directory. This can cause the loss of the logfile that was being backed up by the ontape that was already running. The current workaround is that when this is detected, take a level 0 archive. Since you are on 11.10, I'll see if we can backport the fix to 11.10. Thanks. Davis. > > the logical log directory has RWX to user and group informix and no other than > the dbas so at first i dont think any one would delete that log. > > any idea what should i do with this .... > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

First thing? Take an immediate level zero archive. Second thing? Find out who or what is deleting those files. At first I thought, OH, 20084 is just included in the file with 20085 (which happens if the logs are filling fast enough), but the filesize would be doubled, so that's not it. Art On Fri, Oct 10, 2008 at 1:01 PM, VIKAS HIVARKAR <vikas.hivarkar@gmail.com>wrote: > Hello, > > IDS 11.10.FC2W4 on solaris 10 > > Ontape for backing up of logical log files to a directory using the > alarmprogram.sh script > > I see that manyyy logical log files are missing from the logical log backup > directory.. > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020073 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020074 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020075 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020076 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020077 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 proddb_1_Log0000020078 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020079 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020080 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020081 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020082 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020083 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020085 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020086 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020087 > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 proddb_1_Log0000020088 > > i checked in onstat -l and found that log with uniqid > > a3180d77e0 142 U-B---- 20066 5:1290053 10000 10000 100.00 > a3180d7848 143 U-B---- 20067 5:1300053 10000 10000 100.00 > a3180d78b0 144 U-B---- 20068 5:1310053 10000 10000 100.00 > a3180d7918 145 U-B---- 20069 5:1320053 10000 10000 100.00 > a3180d7980 146 U-B---- 20070 5:1330053 10000 10000 100.00 > a3180d79e8 147 U-B---- 20071 5:1340053 10000 10000 100.00 > a3180d7a50 148 U-B---- 20072 5:1350053 10000 10000 100.00 > a3180d7ab8 149 U-B---- 20073 5:1360053 10000 10000 100.00 > a3180d7b20 150 U-B---- 20074 5:1370053 10000 10000 100.00 > a3180d7b88 151 U-B---- 20075 5:1380053 10000 10000 100.00 > a3180d7bf0 152 U-B---- 20076 5:1390053 10000 10000 100.00 > a3180d7c58 153 U-B---- 20077 5:1400053 10000 10000 100.00 > a3180d7cc0 154 U-B---- 20078 5:1410053 10000 10000 100.00 > a3180d7d28 155 U-B---- 20079 5:1420053 10000 10000 100.00 > a3180d7d90 156 U-B---- 20080 5:1430053 10000 10000 100.00 > a3180d7df8 157 U-B---- 20081 5:1440053 10000 10000 100.00 > a3180d7e60 158 U-B---- 20082 5:1450053 10000 10000 100.00 > a3180d7ec8 159 U-B---- 20083 5:1460053 10000 10000 100.00 > a3180d7f30 160 U-B---- 20084 5:1470053 10000 10000 100.00 > a3180d7f98 161 U-B---- 20085 5:1480053 10000 10000 100.00 > a3180d8028 162 U-B---- 20086 5:1490053 10000 10000 100.00 > a3180d8090 163 U-B---- 20087 5:1500053 10000 10000 100.00 > a3180d80f8 164 U-B---- 20088 5:1510053 10000 10000 100.00 > > So the Logical log 20084 is missing from the logical log backup directory. > and there are manyyyy more... > Plssss let me know what could be the reason and what more do i have to look > for. > > the logical log directory has RWX to user and group informix and no other > than > the dbas so at first i dont think any one would delete that log. > > any idea what should i do with this .... > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Your logs are turning over at a reasonable rate... If you made them bigger then they would be slower to turn over and you might have a little more time to see who is performing IO in that directory beside ontape... And the problem might be associated with the rate... Right now you objective is to ensure your system is recoverable (at least locally) So I would make bigger and slow the whole process down... Might like to ensure that alarm shell program is checking if ontape is currently running before kicking off a new ontape...eg something like ps -ef | grep "ontape" | grep -v grep >/dev/null (Please check this code works) As funny things can happen if two ontapes try to work at the same time

Hi, most likely (> 98%), the problem is what Davis described in his answer (see below). If you want to be 100% sure, then you have to modify your alarm program script (or whatever script/program actually executes the ontape command) to capture the output of the ontape processes in a file. If you see messages indicating that some temporary file cannot be renamed and/or removed because it does not exist (errno 2), then this is the described problem. Besides taking a level-0 archive when the situation of log file backup loss occured, you may consider the following to improve the situation: a) in your script/program add some code to first check whether an "ontape -a -d" command is already being executed (e.g. using "ps ..." output). If so, then do not start a new "ontape -a -d". The one that is running will backup all the used log files anyway (except the current log file). Note: this is not 100% error proof as there still is a gap between checking for a running "ontape -a -d" process and starting a new one. b) Capture all ontape output (stdout and stderr) to a file and put in your alarm program some additional code to check this file for above dscribed errors. If such an error is detected, write a warning (to online.log or whatever) because now surely it is time to do a level-0 archive ... Note: this may also not bee 100% error proof. An error may still slip your attention. It highly depends on the implementation of the error checking/scanning ... c) The respective defect is: idsdb00165611 (for IDS 11.10). While in the upcoming 11.50.xC3 this is fixed already, you may contact IBM Informix Tech Support (check your contract) to get a fix of this problem for your IDS 11.10 ... Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 10.10.2008 21:55:01: > ids-bounces@iiug.org wrote on 10/10/2008 10:01:44 AM: > > > Hello, > > > > IDS 11.10.FC2W4 on solaris 10 > > > > Ontape for backing up of logical log files to a directory using the > > alarmprogram.sh script > > > > I see that manyyy logical log files are missing from the logical log > backup > > directory.. > > > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 > proddb_1_Log0000020073 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 > proddb_1_Log0000020074 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 > proddb_1_Log0000020075 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 > proddb_1_Log0000020076 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 > proddb_1_Log0000020077 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:11 > proddb_1_Log0000020078 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020079 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020080 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020081 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020082 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020083 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020085 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020086 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020087 > > -rw-rw---- 1 informix informix 20578304 Oct 7 23:12 > proddb_1_Log0000020088 > > > > i checked in onstat -l and found that log with uniqid > > > > a3180d77e0 142 U-B---- 20066 5:1290053 10000 10000 100.00 > > a3180d7848 143 U-B---- 20067 5:1300053 10000 10000 100.00 > > a3180d78b0 144 U-B---- 20068 5:1310053 10000 10000 100.00 > > a3180d7918 145 U-B---- 20069 5:1320053 10000 10000 100.00 > > a3180d7980 146 U-B---- 20070 5:1330053 10000 10000 100.00 > > a3180d79e8 147 U-B---- 20071 5:1340053 10000 10000 100.00 > > a3180d7a50 148 U-B---- 20072 5:1350053 10000 10000 100.00 > > a3180d7ab8 149 U-B---- 20073 5:1360053 10000 10000 100.00 > > a3180d7b20 150 U-B---- 20074 5:1370053 10000 10000 100.00 > > a3180d7b88 151 U-B---- 20075 5:1380053 10000 10000 100.00 > > a3180d7bf0 152 U-B---- 20076 5:1390053 10000 10000 100.00 > > a3180d7c58 153 U-B---- 20077 5:1400053 10000 10000 100.00 > > a3180d7cc0 154 U-B---- 20078 5:1410053 10000 10000 100.00 > > a3180d7d28 155 U-B---- 20079 5:1420053 10000 10000 100.00 > > a3180d7d90 156 U-B---- 20080 5:1430053 10000 10000 100.00 > > a3180d7df8 157 U-B---- 20081 5:1440053 10000 10000 100.00 > > a3180d7e60 158 U-B---- 20082 5:1450053 10000 10000 100.00 > > a3180d7ec8 159 U-B---- 20083 5:1460053 10000 10000 100.00 > > a3180d7f30 160 U-B---- 20084 5:1470053 10000 10000 100.00 > > a3180d7f98 161 U-B---- 20085 5:1480053 10000 10000 100.00 > > a3180d8028 162 U-B---- 20086 5:1490053 10000 10000 100.00 > > a3180d8090 163 U-B---- 20087 5:1500053 10000 10000 100.00 > > a3180d80f8 164 U-B---- 20088 5:1510053 10000 10000 100.00 > > > > So the Logical log 20084 is missing from the logical log backup > directory. > > and there are manyyyy more... > > Plssss let me know what could be the reason and what more do i have to > look > > for. > > This is a bug that is fixed in 11.50xC3 > > The problem is that when log files are filled rapidly (matter of seconds) > and > the alarmprogram.sh is used to perform automatic ontape backup to > directory, > the alarmprogram.sh which invokes ontape may cause ontape to run when > there, > is already another ontape running that is backing up a logfile to > directory. > This can cause the loss of the logfile that was being backed up by the > ontape that was already running. > > The current workaround is that when this is detected, take a level 0 > archive. > Since you are on 11.10, I'll see if we can backport the fix to 11.10. > > Thanks. Davis. > > > > > the logical log directory has RWX to user and group informix and no other > than > > the dbas so at first i dont think any one would delete that log. > > > > any idea what should i do with this .... > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi, I've started capturing the logs for "ontape -a -d" from alarmprogram.sh $BACKUP_CMD 1>>$LOG 2>&1 Fortunately since last level 0 backup we have not missed any logical log archive file and that's just my manual obervation also no any message yet as mentioned by Martin in the $LOG file. I want to know that why a alarm is not raised when the logical log file archive is missed, we have set the ALARMADMIN=3 Another Issue I've started the logical log archive file copy using scp from my prod server to a remote host as DR ( i know this is not the way to do DR but...) for this i've added the scp command in the alarmprogram.sh script just after if ( `test x${BACKUPLOGS} = xY` ) then # $BACKUP_CMD 2>&1 >> /dev/null $BACKUP_CMD 1>>$LOG 2>&1 EXIT_STATUS=$? printf " '$BACKUP_CMD' has been executed and returned CODE=%s\\ \\ " $EXIT_STATUS >> $MAILBODY else echo "Script will not backup the logical logs." LOGFILE=`ls -ltr $LOGPATH |tail -1 | awk -F" " '{print $9}'` scp -q $LOGPATH/$LOGFILE $RHOST:$LOGPATH >>$LOG 2>>$ERRLOG & fi I tested the above logic on a less heavy transaction server for 7 days and found that all the logs are copying with out any issue or missing file ( ofcourse i dont know why nothing is written to the $LOG file ). I've implemented this on the prod server but now when i see this for the prod server, there are many log files missing on the remote server ( firstly i thought there is an issue with scp but now as files are missing on prod server It is realy hard to figure out what ALL is wrong ) I see some logical log files on the Remote host server ( logical log files scp from prod server)with name such as -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021398 -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021396 -rw-r----- 1 informix informix 12713984 Oct 13 22:46 ONTL_proddb_1_Mon_Oct_13_22_46_09_2008 -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021394 -rw-r----- 1 informix informix 18481152 Oct 13 22:46 ONTL_proddb_1_Mon_Oct_13_22_45_53_2008 -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021392 -rw-r----- 1 informix informix 20578304 Oct 13 22:45 proddb_1_Log0000021390 -rw-r----- 1 informix informix 20578304 Oct 13 22:45 proddb_1_Log0000021389 What are these ONTL_proddb_1_Mon_Oct_13_22_46_09_2008 files? All the logs from 21389 to 21398 are available on the prod server. Have i configured the scp with alarmprogarm.sh in a bad manner or is this some thing very messy.. Regards, Vikas ---------------------------------- ------------ Hi, most likely (> 98%), the problem is what Davis described in his answer (see below). If you want to be 100% sure, then you have to modify your alarm program script (or whatever script/program actually executes the ontape command) to capture the output of the ontape processes in a file. If you see messages indicating that some temporary file cannot be renamed and/or removed because it does not exist (errno 2), then this is the described problem. Besides taking a level-0 archive when the situation of log file backup loss occured, you may consider the following to improve the situation: a) in your script/program add some code to first check whether an "ontape -a -d" command is already being executed (e.g. using "ps ..." output). If so, then do not start a new "ontape -a -d". The one that is running will backup all the used log files anyway (except the current log file). Note: this is not 100% error proof as there still is a gap between checking for a running "ontape -a -d" process and starting a new one. b) Capture all ontape output (stdout and stderr) to a file and put in your alarm program some additional code to check this file for above dscribed errors. If such an error is detected, write a warning (to online.log or whatever) because now surely it is time to do a level-0 archive ... Note: this may also not bee 100% error proof. An error may still slip your attention. It highly depends on the implementation of the error checking/scanning ... c) The respective defect is: idsdb00165611 (for IDS 11.10). While in the upcoming 11.50.xC3 this is fixed already, you may contact IBM Informix Tech Support (check your contract) to get a fix of this problem for your IDS 11.10 ...

Hi, a) a file with a name like "ONTL_proddb_1_Mon_Oct_13_22_46_09_2008" is a temporary file that ontape creates while doing backup. ( Such a file will be renamed to the proper backup file name once the backup has finished successfully. This is to avoid having a seemingly correct backup file lying around from an unsuccessful (and aborted) backup attempt ...) b) with your command "ls -ltr | tail -1 | ... " you get only the very last file of the listing in the directory. On a busy system one execution of "ontape -a -d" may backup more than one log file, especially when the next log file gets full while the last one is backed up. At the end of a log backup ontape checks if there are (meanwhile) more logs to backup. If so it just continues to backup logs. Finally (when ontape caught up or log filling slowed down), there will no full log to be backed up when ontape finished the last one, and then it will exit. Now assume "ontape -a -d" backed up 5 log files in a row, and when it exits you get only the last of them with your "ls -ltr | tail -1 | ...", then only the last one is copied to the remote machine and the other 4 log files are missing (on the remote machine). c) If your alarm script just finished the "ontape -a -d" and in the same (split) second a new log fills and the alarm program starts a new log backup, then this new "ontape -a -d" creates its temporary file (with a name like the above in a)). In this moment the "old log backup" is now doing its "ls -ltr | tail -1 | ..." and then the newest file will not be the one it just backed up, but it will be the temp file of the next "ontape -a -d" that has just started. Then your script copies that temp file to the remote machine (instead of the last log file that it has backed up itself). This is why you get some of these temp files on the remote machine (and miss even more proper backup files on the remote machine). So, the scripting of copying log files to the remote machine is not that simple ... You need to put "a bit" more thought into it ... ;) But as long as you see all the log backup files on the production machine, everything is OK. There's nothing "messy" with the log backup itself. :) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 14.10.2008 13:42:27: > Hi, > > I've started capturing the logs for "ontape -a -d" from alarmprogram.sh > $BACKUP_CMD 1>>$LOG 2>&1 > > Fortunately since last level 0 backup we have not missed any logical log > archive file and that's just my manual obervation also no any message yet as > mentioned by Martin in the $LOG file. > I want to know that why a alarm is not raised when the logical log file > archive is missed, we have set the ALARMADMIN=3 > > Another Issue > I've started the logical log archive file copy using scp from my prod server > to a remote host as DR ( i know this is not the way to do DR but...) > for this i've added the scp command in the alarmprogram.sh script just after > > if ( `test x${BACKUPLOGS} = xY` ) then > # $BACKUP_CMD 2>&1 >> /dev/null > > $BACKUP_CMD 1>>$LOG 2>&1 > > EXIT_STATUS=$? > > printf " '$BACKUP_CMD' has been executed and returned CODE=%s\\ \\ " > $EXIT_STATUS >> $MAILBODY > > else > > echo "Script will not backup the logical logs." > > LOGFILE=`ls -ltr $LOGPATH |tail -1 | awk -F" " '{print $9}'` > > scp -q $LOGPATH/$LOGFILE $RHOST:$LOGPATH >>$LOG 2>>$ERRLOG & > > fi > > I tested the above logic on a less heavy transaction server for 7 days and > found that all the logs are copying with out any issue or missing file ( > ofcourse i dont know why nothing is written to the $LOG file ). > > I've implemented this on the prod server but now when i see this forthe prod > server, there are many log files missing on the remote server ( firstly i > thought there is an issue with scp but now as files are missing on > prod server > It is realy hard to figure out what ALL is wrong ) > > I see some logical log files on the Remote host server ( logical logfiles scp > from prod server)with name such as > > -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021398 > -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021396 > -rw-r----- 1 informix informix 12713984 Oct 13 22:46 > ONTL_proddb_1_Mon_Oct_13_22_46_09_2008 > -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021394 > -rw-r----- 1 informix informix 18481152 Oct 13 22:46 > ONTL_proddb_1_Mon_Oct_13_22_45_53_2008 > -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021392 > -rw-r----- 1 informix informix 20578304 Oct 13 22:45 proddb_1_Log0000021390 > -rw-r----- 1 informix informix 20578304 Oct 13 22:45 proddb_1_Log0000021389 > > What are these ONTL_proddb_1_Mon_Oct_13_22_46_09_2008 files? > All the logs from 21389 to 21398 are available on the prod server. > > Have i configured the scp with alarmprogarm.sh in a bad manner or isthis some > thing very messy.. > > Regards, > Vikas > > ---------------------------------- > ------------ > > Hi, > > most likely (> 98%), the problem is what Davis described > in his answer (see below). If you want to be 100% sure, > then you have to modify your alarm program script (or > whatever script/program actually executes the ontape > command) to capture the output of the ontape processes > in a file. If you see messages indicating that some > temporary file cannot be renamed and/or removed > because it does not exist (errno 2), then this is the > described problem. > > Besides taking a level-0 archive when the situation of > log file backup loss occured, you may consider the > following to improve the situation: > > a) in your script/program add some code to first > check whether an "ontape -a -d" command is already > being executed (e.g. using "ps ..." output). If so, then > do not start a new "ontape -a -d". The one that is > running will backup all the used log files anyway > (except the current log file). > Note: this is not 100% error proof as there still is a > > gap between checking for a running "ontape -a -d" > > process and starting a new one. > > b) Capture all ontape output (stdout and stderr) to a > file and put in your alarm program some additional > code to check this file for above dscribed errors. > If such an error is detected, write a warning (to online.log > or whatever) because now surely it is time to do a > level-0 archive ... > Note: this may also not bee 100% error proof. An error > > may still slip your attention. It highl

Hi, amending the last e-mail ... d) an ALARM is not raised, because for the server the log was backed up successfully. Therefore it also is marked as backed up in the server (see "onstat -l" output). This problem with missing log backup files is that the temp file gets overwritten and or deleted by another "ontape -a -d" process before the actual owner of the file has a chance to rename it to the proper backup file name. (ALARMs are triggered or raised only by the server, not by utilities like ontape. Therefore you can see an error message by ontape, written to stdout or stderr, but no ALARM or message in online.log file from the server.) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 14.10.2008 13:42:27: > Hi, > > I've started capturing the logs for "ontape -a -d" from alarmprogram.sh > $BACKUP_CMD 1>>$LOG 2>&1 > > Fortunately since last level 0 backup we have not missed any logical log > archive file and that's just my manual obervation also no any message yet as > mentioned by Martin in the $LOG file. > I want to know that why a alarm is not raised when the logical log file > archive is missed, we have set the ALARMADMIN=3 > > Another Issue > I've started the logical log archive file copy using scp from my prod server > to a remote host as DR ( i know this is not the way to do DR but...) > for this i've added the scp command in the alarmprogram.sh script just after > > if ( `test x${BACKUPLOGS} = xY` ) then > # $BACKUP_CMD 2>&1 >> /dev/null > > $BACKUP_CMD 1>>$LOG 2>&1 > > EXIT_STATUS=$? > > printf " '$BACKUP_CMD' has been executed and returned CODE=%s\\ \\ " > $EXIT_STATUS >> $MAILBODY > > else > > echo "Script will not backup the logical logs." > > LOGFILE=`ls -ltr $LOGPATH |tail -1 | awk -F" " '{print $9}'` > > scp -q $LOGPATH/$LOGFILE $RHOST:$LOGPATH >>$LOG 2>>$ERRLOG & > > fi > > I tested the above logic on a less heavy transaction server for 7 days and > found that all the logs are copying with out any issue or missing file ( > ofcourse i dont know why nothing is written to the $LOG file ). > > I've implemented this on the prod server but now when i see this forthe prod > server, there are many log files missing on the remote server ( firstly i > thought there is an issue with scp but now as files are missing on > prod server > It is realy hard to figure out what ALL is wrong ) > > I see some logical log files on the Remote host server ( logical logfiles scp > from prod server)with name such as > > -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021398 > -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021396 > -rw-r----- 1 informix informix 12713984 Oct 13 22:46 > ONTL_proddb_1_Mon_Oct_13_22_46_09_2008 > -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021394 > -rw-r----- 1 informix informix 18481152 Oct 13 22:46 > ONTL_proddb_1_Mon_Oct_13_22_45_53_2008 > -rw-r----- 1 informix informix 20578304 Oct 13 22:46 proddb_1_Log0000021392 > -rw-r----- 1 informix informix 20578304 Oct 13 22:45 proddb_1_Log0000021390 > -rw-r----- 1 informix informix 20578304 Oct 13 22:45 proddb_1_Log0000021389 > > What are these ONTL_proddb_1_Mon_Oct_13_22_46_09_2008 files? > All the logs from 21389 to 21398 are available on the prod server. > > Have i configured the scp with alarmprogarm.sh in a bad manner or isthis some > thing very messy.. > > Regards, > Vikas > > ---------------------------------- > ------------ > > Hi, > > most likely (> 98%), the problem is what Davis described > in his answer (see below). If you want to be 100% sure, > then you have to modify your alarm program script (or > whatever script/program actually executes the ontape > command) to capture the output of the ontape processes > in a file. If you see messages indicating that some > temporary file cannot be renamed and/or removed > because it does not exist (errno 2), then this is the > described problem. > > Besides taking a level-0 archive when the situation of > log file backup loss occured, you may consider the > following to improve the situation: > > a) in your script/program add some code to first > check whether an "ontape -a -d" command is already > being executed (e.g. using "ps ..." output). If so, then > do not start a new "ontape -a -d". The one that is > running will backup all the used log files anyway > (except the current log file). > Note: this is not 100% error proof as there still is a > > gap between checking for a running "ontape -a -d" > > process and starting a new one. > > b) Capture all ontape output (stdout and stderr) to a > file and put in your alarm program some additional > code to check this file for above dscribed errors. > If such an error is detected, write a warning (to online.log > or whatever) because now surely it is time to do a > level-0 archive ... > Note: this may also not bee 100% error proof. An error > > may still slip your attention. It highly depends on the > > implementation of the error checking/scanning ... > > c) The respective defect is: idsdb00165611 (for IDS 11.10). > While in the upcoming 11.50.xC3 this is fixed already, > you may contact IBM Informix Tech Support (check > your contract) to get a fix of this problem for > your IDS 11.10 ... > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi, Here is some content of the log file. Program over. Backup to directory error: Cannot rename file from /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_36_2008 to / db/informix/logicallog/proddb_1_Log0000021945, errno = 2 Backup to directory error: Cannot remove file /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_36_2008, errno = 2 Performing automatic backup of logical logs. File created: /db/informix/logicallog/proddb_1_Log0000021942 File created: /db/informix/logicallog/proddb_1_Log0000021943 File created: /db/informix/logicallog/proddb_1_Log0000021944 Logbackup failed - Program over. Performing automatic backup of logical logs. Program over. Performing automatic backup of logical logs. Program over. Backup to directory error: Cannot rename file from /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_48_2008 to / db/informix/logicallog/proddb_1_Log0000021949, errno = 2 Backup to directory error: Cannot remove file /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_48_2008, errno = 2 Performing automatic backup of logical logs. File created: /db/informix/logicallog/proddb_1_Log0000021946 File created: /db/informix/logicallog/proddb_1_Log0000021947 File created: /db/informix/logicallog/proddb_1_Log0000021948 Logbackup failed - Program over. Performing automatic backup of logical logs. File created: /db/informix/logicallog/proddb_1_Log0000021950 Do you want to back up the current logical log? (y/n) n Program over. Performing automatic backup of logical logs. Program over. Backup to directory error: Cannot rename file from /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_59_2008 to / db/informix/logicallog/proddb_1_Log0000021952, errno = 2 Backup to directory error: Cannot remove file /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_59_2008, errno = 2 Performing automatic backup of logical logs. File created: /db/informix/logicallog/proddb_1_Log0000021951 Logbackup failed - Program over. and the files are missing :( Martin, now can we 100% say that the respective defect is: idsdb00165611 (for IDS 11.10)? Regards Vikas -------------------------------------------------------- ------------------------- Hi, most likely (> 98%), the problem is what Davis described in his answer (see below). If you want to be 100% sure, then you have to modify your alarm program script (or whatever script/program actually executes the ontape command) to capture the output of the ontape processes in a file. If you see messages indicating that some temporary file cannot be renamed and/or removed because it does not exist (errno 2), then this is the described problem. Besides taking a level-0 archive when the situation of log file backup loss occured, you may consider the following to improve the situation: a) in your script/program add some code to first check whether an "ontape -a -d" command is already being executed (e.g. using "ps ..." output). If so, then do not start a new "ontape -a -d". The one that is running will backup all the used log files anyway (except the current log file). Note: this is not 100% error proof as there still is a gap between checking for a running "ontape -a -d" process and starting a new one. b) Capture all ontape output (stdout and stderr) to a file and put in your alarm program some additional code to check this file for above dscribed errors. If such an error is detected, write a warning (to online.log or whatever) because now surely it is time to do a level-0 archive ... Note: this may also not bee 100% error proof. An error may still slip your attention. It highly depends on the implementation of the error checking/scanning ... c) The respective defect is: idsdb00165611 (for IDS 11.10). While in the upcoming 11.50.xC3 this is fixed already, you may contact IBM Informix Tech Support (check your contract) to get a fix of this problem for your IDS 11.10 ... Regards, Martin

> Martin, now can we 100% say that the respective defect is: > idsdb00165611 (for IDS 11.10)? Yes. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 "VIKAS HIVARKAR" <vikas.hivarkar@gmail.com> Sent by: ids-bounces@iiug.org 15.10.2008 07:56 Please respond to ids@iiug.org To ids@iiug.org cc Subject Re: Logical Log files MISSING [13701] Hi, Here is some content of the log file. Program over. Backup to directory error: Cannot rename file from /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_36_2008 to / db/informix/logicallog/proddb_1_Log0000021945, errno = 2 Backup to directory error: Cannot remove file /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_36_2008, errno = 2 Performing automatic backup of logical logs. File created: /db/informix/logicallog/proddb_1_Log0000021942 File created: /db/informix/logicallog/proddb_1_Log0000021943 File created: /db/informix/logicallog/proddb_1_Log0000021944 Logbackup failed - Program over. Performing automatic backup of logical logs. Program over. Performing automatic backup of logical logs. Program over. Backup to directory error: Cannot rename file from /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_48_2008 to / db/informix/logicallog/proddb_1_Log0000021949, errno = 2 Backup to directory error: Cannot remove file /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_48_2008, errno = 2 Performing automatic backup of logical logs. File created: /db/informix/logicallog/proddb_1_Log0000021946 File created: /db/informix/logicallog/proddb_1_Log0000021947 File created: /db/informix/logicallog/proddb_1_Log0000021948 Logbackup failed - Program over. Performing automatic backup of logical logs. File created: /db/informix/logicallog/proddb_1_Log0000021950 Do you want to back up the current logical log? (y/n) n Program over. Performing automatic backup of logical logs. Program over. Backup to directory error: Cannot rename file from /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_59_2008 to / db/informix/logicallog/proddb_1_Log0000021952, errno = 2 Backup to directory error: Cannot remove file /db/informix/logicallog/ONTL_proddb_1_Tue_Oct_14_22_24_59_2008, errno = 2 Performing automatic backup of logical logs. File created: /db/informix/logicallog/proddb_1_Log0000021951 Logbackup failed - Program over. and the files are missing :( Martin, now can we 100% say that the respective defect is: idsdb00165611 (for IDS 11.10)? Regards Vikas -------------------------------------------------------- ------------------------- Hi, most likely (> 98%), the problem is what Davis described in his answer (see below). If you want to be 100% sure, then you have to modify your alarm program script (or whatever script/program actually executes the ontape command) to capture the output of the ontape processes in a file. If you see messages indicating that some temporary file cannot be renamed and/or removed because it does not exist (errno 2), then this is the described problem. Besides taking a level-0 archive when the situation of log file backup loss occured, you may consider the following to improve the situation: a) in your script/program add some code to first check whether an "ontape -a -d" command is already being executed (e.g. using "ps ..." output). If so, then do not start a new "ontape -a -d". The one that is running will backup all the used log files anyway (except the current log file). Note: this is not 100% error proof as there still is a gap between checking for a running "ontape -a -d" process and starting a new one. b) Capture all ontape output (stdout and stderr) to a file and put in your alarm program some additional code to check this file for above dscribed errors. If such an error is detected, write a warning (to online.log or whatever) because now surely it is time to do a level-0 archive ... Note: this may also not bee 100% error proof. An error may still slip your attention. It highly depends on the implementation of the error checking/scanning ... c) The respective defect is: idsdb00165611 (for IDS 11.10). While in the upcoming 11.50.xC3 this is fixed already, you may contact IBM Informix Tech Support (check your contract) to get a fix of this problem for your IDS 11.10 ... Regards, Martin ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.