Persistent "xxxx.lock" files in $alephe_scratch
- Article Type: General
- Product: Aleph
- Product Version: 18.01
Description:
We see these jobs in $alephe_scratch, but I don't find any of them using the "ps -ef | grep command" -- or util c/1:
-rw-rw-r-- 1 aleph aleph 0 May 13 08:48 abc50_p_cash_05.87326.cc_bills.lock
-rw-rw-r-- 1 aleph aleph 0 May 13 11:38 abc50_p_cir_32.87330.lock
-rw-rw-r-- 1 aleph aleph 0 May 13 11:43 abc50_p_cir_51.87331.print_bb.lock
-rw-rw-r-- 1 aleph aleph 0 May 13 12:49 abc50_p_cir_51.87338.jj_print.lock
Resolution:
The 0-length ".lock" files are not jobs. A batch job creates a lock file in order to prevent another exactly-the-same job from running while it is running. If the job fails, the lock file can be left behind.
Each of the first four jobs did fail. For instance, the abc50_p_cash_05.87326.cc_bills log has this at the end:
Load: /aleph/aleph/u16_1/abc50/tab/form_sub_library_address
Bus Error
Oracle error: handle_connection
ORA-03113: end-of-file on communication channel
get_print_file_name : abc50.z52.last-file-number does not exist.
Creating entry with default values.
Oracle error: handle_connection
ORA-03113: end-of-file on communication channel
get_print_file_name : ERROR - Could not create new z52 entry
I/O error : file ''
error code: 9/104 (ANS74), pc=0, call=1, seg=0
104 Null file name used in a file operation
These four lock files are from yesterday morning when there was the problem connecting to Oracle. The solution is to delete them, which I have done.
You need to consider each job individually. In most cases the records which they fail to process will simply be picked up in the next run.
Note: this lock:
-rw-rw-r-- 1 aleph aleph 0 May 14 11:39 abc50_p_acq_14.87549.lock
is for a job which is currently running. It needs to be left as is, which is what I have done.
- Article last edited: 10/8/2013