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

Description:
One of our consortial partners reported a Course Reserves item that wasn't in Primo yesterday. While investigating the problem, I found that ue_21 has not been running on production in ABC30 since 3/16. The end of the last ue_21 log in abc30/scratch is below.

Any idea why this may have crashed? Also, is there any recommended practice for ensuring that a crash like this is reported out somewhere? It's unfortunate that this went unnoticed for so long, and resulted in a backlog of over 2200 Z07P records in the ABC30 processing queue.

I've since restarted the process, Z07P is now empty, and presumably tonight publish_04 job will pick up all affected records.

Resolution:
Looking at the abc30 $data_scratch/run_e_21.3794, I see this:

HANDLING DOC NO. - NYU30.000081285 19:13:54
HANDLING DOC NO. - NYU30.000079716 19:17:24
EXITING - 19:20:10

This is the result of the p_publish_04 which (as seen in the $alephe_scratch/abc30_p_publish_04.00155 log) was started at 19:20:05.
p_publish_04 doesn't want ue_21 running.

The $aleph_proc/p_publish_04 has these lines:
touch $data_scratch/util_e_21_stop
and
rm $data_scratch/util_e_21_stop
at the end.

But this second line doesn't cause ue_21 to be restarted. It just *allows* it to be restarted.

Normally p_publish_04 is a one-time job. Once the initial run is done, ue_21 takes over and creates the Z00Ps.

For now: If you need to run p_publish_04, you should restart ue_21 when it is done.

As described in KB 16384-21105 we recommend stopping/starting Aleph weekly -- even if you aren't stopping Oracle.

If something should fall through the cracks like this, it will at least be covered by this restart....

(Keywords: p-publish-04)

• Article last edited: 10/8/2013