p_cir_13: reprocessing notices not produced because of time change

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

Description:
I forgot to stop the job daemon before the clocks fell back and we got hit with the problem of all of our jobs running twice on Sunday, Monday and even today (Tuesday). I have finally stopped the job list and re-started it. There is a nice doc on the ExLibris Document portal that tells you how to re-run p_cir_51 and this was very helpful, but I also need to re-run p_cir_13 (recalls). Is there a way to reset the tables for recalls so I can re-run the recall notices?

Resolution:
p_cir_13 is different than p_cir_51. p_cir_51 updates the z36_last_letter_date while p_cir_13 does not (except for the option to set z36_last_letter_date to zero).

Determining which z36's were updated by Sunday's, Monday'w, Tuesday's run of p_cir_13 is a bit more questionable.... p_cir_13 updates the following fields:

02 Z36-RECALL-DATE PICTURE 9(8).
02 Z36-RECALL-DUE-DATE PICTURE 9(8).
02 Z36-RECALL-TYPE PICTURE X(2).

and (if the tab100 RECALL-METHOD is "1") the

02 Z36-DUE-DATE PICTURE 9(8).

If you run p_cir_13 daily, then it may be that the z36's with a z36_recall_date of 20071103 (Saturday) are the ones which need to be re-processed.

If that is the case -- and if you specify tab100 RECALL-METHOD "2" or "3" so that the Z36-DUE-DATE is not updated --, you could run p_file_03 to back up the z36 and then do the following SQL:

update z36 set z36_recall_date = '00000000', z36_recall_due_date = '00000000', z36_recall_type = null where z36_recall_date >= '20071103';

commit;

Then when p_cir_13 is run next, these z36's will be reprocessed.

• Article last edited: 10/8/2013