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

    p_acq_06_b stalled/looping

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

    Description:
    On 2009-07-01, Acq seervice acq-06-b which started at 12:57 stalled (loops?) for no obvious reason at 13:42. Here are the final lines from the log for the service:

    68069 READING Z68 0047419050000 AT 13:41:57
    69070 READING Z68 0047475720000 AT 13:42:01
    70071 READING Z68 0047515590000 AT 13:42:04
    71072 READING Z68 0047530410000 AT 13:42:08
    72073 READING Z68 0047569000000 AT 13:42:12

    (The same service ran successfully earlier the same day on our development server.)

    Oracle space does not appear to be an issue.

    Here are the relevant unix processess:

    aleph 13871 13870 0 12:57:18 ? 0:00 csh -f /exlibris/aleph/a18_1/aleph/proc/p_acq_06 ABC50,acq-06-b-so_report_20090
    aleph 13870 1512 0 12:57:18 ? 0:00 sh -c csh -f /exlibris/aleph/a18_1/aleph/proc/p_acq_06 'ABC50,acq-06-b-so_repor
    aleph 13959 13871 8 12:57:21 ? 764:38 /exlibris/aleph/a18_1/aleph/exe/rts32 b_acq_06_a

    Finding a way to allow this service to resume and complete would be ideal but, short of that, how can the service be brought down gracefully and in such a way that it can be re-run?

    Resolution:
    The following SQL shows that acq-06 is working on ADM# 004759346:

    abc50@ALEPH18> select max(z601_rec_key_3) from z601 where z601_rec_key like '%-2010%' and z601_rec_key_3 in (select z68_rec_key from z68 where z68_order_type = 'O');
    **** Hit return to continue ****

    MAX(Z601_REC_K
    --------------
    00475934600001

    This shows that a -2010 encumbrance has been created for the first CJAPI-2009 but not the second:

    abc50@ALEPH18> select Z601_REC_KEY from z601 where Z601_REC_KEY_3 like '004759346%' and z601_type = 'ENC';
    **** Hit return to continue ****

    Z601_REC_KEY
    -----------------------------------------------------------------
    CJAPI-2006 401014357422754
    CJAPI-2005 400820141123440
    CJAPI-2007 200607115604537
    CJAPI-2008 200706292024491
    CJAPI-2009 200806278678940
    CJAPI-2010 200907014947840
    CCHIN-2005 401004185597727
    CCHIN-2006 401014362182119
    CCHIN-2007 200607115604539
    CCHIN-2008 200706292024493
    CJAPI-2009 200905114057190

    Please have the Acq staff look at this order/encumbrance to see if anything seems wrong -- and compare it to the Dev server where this worked.

    If not, have them also look at the next order/encumbrance which the program would be processing, which is 004759368:

    abc50@ALEPH18> select substr (Z601_REC_KEY_3,1,9) from z601 where substr (Z601_REC_KEY_3,1,9) > '004759347' and Z601_TYPE = 'ENC' and z601_rec_key like '%-2009%' order by substr (Z601_REC_KEY_3,1,9);

    **** Hit return to continue ****
    SUBSTR(Z601_REC_KEY_3,1,9)
    ---------------------------
    004759368
    <etc.>

    As described in the p_acq_06 header and the "How to Manage End-of-Year Procedures in Acquisitions" doc, attached to KB 5510, we strongly suggest that you back up the affected tables before running p_acq_06.

    Since this site lacked a backup and since it was unclear what should be done to order 004759346 (or 004759368) to let it be processed successfully, I killed the p_acq_06_b job, saved the existing program, and changed b_acq_06_a.cbl to skip all orders less than 004759369.

    When the job was rerun -- for standing orders! -- it skipped orders 004759346 and 004759368, started with the orders beyond those, and ran successfully. The 004759346 or 004759368 orders needed to be rolled over manually.


    • Article last edited: 10/8/2013