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

    p_cir_51: Incorrect Borrower Statuses, No Output File Created

    1. Last updated
    2. Save as PDF
    • Article Type: General
    • Product: Aleph
    • Product Version: 18.01

    Description:
    This morning, Circulation staff ran p_cir_51 for borrower statuses 01, 02, 03, and 04. Although the job completed no output file appears in ABC50 Task Manager. (The job appears in the Task Manager Batch Log and there should be an output file named studentover100709.)

    Staff then ran p_cir_51 for borrower statuses 52, 54, 56, and 59 and named the output file staffover100709. The notices in this file have the correct letter format for staff overdue notices but all of the patrons are students: they have borrower statuses 01, 02, and 04. Borrower 5104246 is borrower status 01; borrower 5176096 is borrower status 01; borrower 51 is borrower status 04 but has no books checked out (?!) and borrower 5637 is borrower status 02. There are no notices for borrowers with statuses 52, 54, 56, or 59 in the output file.

    Resolution:
    Looking in the $alephe_scratch directory, I see that

    abc50_p_cir_51.17163 (the job to produce studentover100709) started at 07:55:40 and ended at 07:57:33; while

    abc50_p_cir_51.17164 (the job to produce staffover100709) started at 07:56:33 and ended at 07:56:52.

    This means that these two jobs were running at the same time. I see error messages like this in their logs:

    I/O error : file 'TP3'
    error code: 9/065 (ANS74), pc=0, call=1, seg=0
    65 File locked

    I/O error : file 'FORM_IN'
    error code: 9/065 (ANS74), pc=0, call=1, seg=0
    65 File locked

    I/O error : file 'TP1'
    error code: 9/065 (ANS74), pc=0, call=1, seg=0
    65 File locked


    Since both of these jobs were submitted through the GUI Services, this should not happen. (Likewise, it should not be possible when submitted through the job_list. It *could* happen if submitted from the command line....)

    I was seeing entries the following in util c/1 for abc50:

    aleph 2506 1 0 Mar 06 ? 7:52 /exlibris/aleph/a18_1/aleph/exe/lib_batch ABC50

    This meant that the lib_batch (batch queue) process had been running since March 6.

    Since util c/7 showed that there were no jobs waiting in the queue, I did this in the ./abc50/files/ directory:

    > cp -p batch_queue file batch_queue.old
    > rm batch_que
    > touch batch_queue

    and started a new batch queue (util c/2).

    Since I would describe the problem you have been seeing as "the batch queue is not behaving properly", my thought was that this might help -- which it *did*.

    The following "ps -ef |grep" shows that the batch queue's for the other libraries are just as old:

    >>ps -ef | grep lib_batch
    aleph 2764 1 0 Mar 06 ? 2:03 /exlibris/aleph/a18_1/aleph/exe/lib_batch ABC60
    aleph 2644 1 0 Mar 06 ? 2:02 /exlibris/aleph/a18_1/aleph/exe/lib_batch ABC10
    aleph 2806 1 0 Mar 06 ? 2:06 /exlibris/aleph/a18_1/aleph/exe/lib_batch VIR01
    aleph 26489 1 0 12:26:57 pts/6 0:00 /exlibris/aleph/a18_1/aleph/exe/lib_batch ABC50
    aleph 2696 1 0 Mar 06 ? 2:07 /exlibris/aleph/a18_1/aleph/exe/lib_batch ABC30
    aleph 3132 1 0 Mar 10 ? 2:02 /exlibris/aleph/a18_1/aleph/exe/lib_batch ABC01

    I think that you should run aleph_shutdown followed by aleph_startup sometime in the next couple days. And that you should do this aleph restart at least once every month.

    • Article last edited: 10/8/2013