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.
Additional Information
Article: z00p_timestamp and tab_publish_timestamp are in UTC format
Category: Publishing
- Article last edited: 10/8/2013