- Article Type: General
- Product: Aleph
- Product Version: 14.2
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.)
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.
- Article last edited: 10/8/2013