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