Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    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)

    *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


    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