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

Description:
When you run a p_manage_nn indexing job (such as p_manage_01, p_manage_02, etc.), you find that the cycles file which it creates has a zero-length. (Note: the cycles file is in the library's $data_scratch directory.)

Resolution:
Each job has a step or a program (such as p_manage_01_a3) which creates the cycles file. These steps/programs read the last-doc-number from the z52 table (which you can see in util g/2). If the last-doc-number is 0, then the cycles file will not be created.

If the last-doc-number is correctly set to zero (that is, an SQL select count on the library's Z00 table shows no records), then you need to re-do the step which was supposed to load the doc records.

If there are doc records, then you need to set the last-doc-number to the value of the highest one. This can be determined by doing:

SQL> select max (z00_doc_number) from z00;

Note: in another case there *were* bib records and last-doc-number *was* correct, but we found that the alephm directory was defective. (For instance, the ./alephm/source/copy directory was absent.) It's not clear just how/why this affected the execution of p_manage_01, but, anyway, when a complete/correct alephm was copied in, the job ran OK.

In a third case, a special version of $aleph_proc/p_manage_01 had been placed on the server (for doing a restart using the existing cycles file). Restoring the regular/original p_manage_01 proc corrected the problem.