Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Task Manager > Batch Log lists processes as "Running" when they're complete

    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    I noticed this morning in my circ client > Task Manager > Batch Log that it lists several processes as "Running" when they should be complete. One of them is p_notices_courtesy, process 3946.

    The log for this process says it ended, and when I do a ps -ef | grep courtesy and ps -ef | grep 3946, nothing is returned, so it appears the process is not actually running on the server. Why is it still listed as running in Aleph?

    I notice that the two procs which are having this problem are p_notices_overdue and p_notices_courtesy. These are the cases where you have created a proc in $aleph_proc, based on the Ex Libris-supplied proc. I see that this was done yesterday.

    The proc which is started by p_notices_overdue is p_cir_51;
    the proc which is started by p_notices_courtesy is p_cir_10.

    When the job is done, the program is supposed to update the z100 record to indicate "SU - Success" or "DO – Done with errors".

    I believe that the program which handles the z100 is expecting the z100_proc_name to be the same as the name of the proc which is being started. I see this in the p_courtesy_notices:

    csh -f $aleph_proc/p_cir_10 ...

    If you want to avoid this problem, you will need to either:

    1. change the p_notices_courtesy so that rather than doing "csh -f $aleph_proc/p_cir_10 ..." it does "cobrun b_cir_10_b" and the other steps in the way that p_cir_10 does; or

    2. rename p_cir_10 to p_cir_10.orig and rename p_notices_courtesy to p_cir_10; and change it so that rather than doing "csh -f $aleph_proc/p_cir_10 ..." it does "cobrun b_cir_10_b" and the other steps ...

    The alternative would be to leave things as they are and ignore the Task Manager entries for these two jobs.

    • Article last edited: 10/8/2013