p_publish_06: records not processed into PRIMO; re-running **MASTER RECORD**

• Article Type: General
• Product: Aleph
• Product Version: 20
• Relevant for Installation Type: Dedicated-Direct; Direct; Local;

Aleph records are (sporadically) not being processed into PRIMO. We find that the following runs of p_publish_06 got the "No such file or directory" error, indicating that there were z00p records which failed to have a tar file created for them:

abc01_p_publish_06.00943 (Jun 16)
abc01_p_publish_06.00944 (Jun 17)
abc01_p_publish_06.00955 (Jun 25)
abc01_p_publish_06.00956 (Jun 26)

Resolution:
*Solution A.* If this is a one-time event (for instance because an incorrect path was specified):

Edit the $aleph_root/tab_publish_timestamp (see Article link below), setting the date to a date preceding the first date that records failed to be processed.

For instance, you would change June 30th to June 23rd, that is, change:

PRIMO-FULL 201206301730110

to:

PRIMO-FULL 201206231730110

(You need only be concerned with the month and day. You can leave the bytes 9-15 in this timestamp as they are.) (See link to article about this date format below.)

The preceding presumes that p_publish_06 is being run with p_publish_type "LAST-DATE".

If you set it back more than is necessary, the only effect will be that more records will be reprocessed than might be necessary.... No problem.


*Solution B.* If this is a recurring problem, -- until we find some other solution -- change the job_list to execute p_publish_06 twice each day:

* the 1st time at 5:15 with UPDATE-FLAG set to No and
* a 2nd time at 7:15 with UPDATE-FLAG set to Yes.

Possible scenarios:

1. Both the 5:15 and the 7:15 work. Result: the Primo pipe will process the updates twice. Not a problem.

2. The 5:15 fails and the 7:15 works. Result: the tar file will be written once (by the 7:15) and processed by the Primo pipe..

3. The 5:15 works and the 7:15 fails. Result: the tar file produced by the 5:15 run will be processed by the Primo pipe. Since the 7:15 fails the timestamp will not be updated. This means that the next day's run will include the previous day's z00p's also. Not a problem.

4. Both the 5:15 and the 7:15 fail. Hopefully, this won't happen. If it does, you will need to update the timestamp and run manually from the command line. (See Solution A. above.)

Note: As described in KB 16384-49393, this solution can only work in v20 if you specify Y" for p_zip_flag in p_publish_06.

This change should result in far fewer cases where the tar file is not written and you need to do the manual procedure.

*Solution C.* Rerun publish-04 to republish all of the z00p records.