LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (07/04/88)
[The author has been having his batch BACKUP job terminating for no apparent reason. Doing a SET NOON didn't solve the problem; he still gets a log file that looks like: .... (stuff removed) $ backup/log - dua0:[epbu]/exclude=(*.DAT,*.DMP,*.BCK),- dua0:[customer]/exclude=(*.DAT,*.DMP,*.BCK),- dua0:[oraload.sys...]/exclude=(*.DAT,*.DMP,*.BCK) - dua0:[oraload.sys]backup.bck/save/block=2048 %BACKUP-S-COPIED, copied DUA0:[EPBU]1.SQL;7 .... (stuff removed) %BACKUP-S-COPIED, copied DUA0:[ORALOAD.SYS]UVSTARTUP.COM;1 %BACKUP-S-COPIED, copied DUA0:[ORALOAD.SYS]WELCOME.TXT;2 SYSTEM job terminated at 27-JUN-1988 23:43:04.06 <CR><LF> Accounting information: Buffered I/O count: 1268 Peak working set size: 512 Direct I/O count: 7384 Peak page file size: 2709 Page faults: 224919 Mounted volumes: 0 Charged CPU time: 0 00:38:13.43 Elapsed time: 0 00:43:04.00 ] Very strange. Try checking the accounting record for the process; it will show the final exit status, which might give you a clue. Also, check the system error logs; look for bugcheck records. (If a file was screwed up, you might get an RMS bugcheck whenever BACKUP touched it. RMS bugchecks are usually non-fatal, but will delete the current process. They don't quite fit the pattern you see - LOGINOUT wouldn't run, so you wouldn't normally see the accounting information at the end.) Other things to look at: Compare the log files for a couple of runs. Does the process always die after logging the copying of one particular file? Or perhaps just BEFORE starting on a particular file or directory? -- Jerry