Automatic resetting of last-doc-number by system

• Article Type: General
• Product: Aleph
• Product Version: 20, 21, 22, 23

Description:
After setting a library's last-doc-number (as seen in util g/2) to a higher value, you find that the system has set it back to a lower number (the *actual* last doc number in this library).

Resolution:
There is a correct_last_doc_number proc, which checks the MAX(Z00_DOC_NUMBER) and changes the last-doc-number to this highest actual z00 value. This proc is called by the following other procs:

p_manage_01, _02, _05, _07, _12, _18, _27, _35, _91, _102, _103, _180, and _431; and p_union_02 and _08.

This means that whenever you run one of these jobs in a library and there is a difference between that library's last-doc-number and the highest actual doc#, the last-doc-number is going to be reset.

There are two main cases where we have suggested increasing the last-doc-number as the solution to a problem: Article 000037616 ( "Random items, holdings, etc. attached to new bib records" ) -- to handle an ADMs-loaded-without-bibs scenario; and Article 000042200 ("BIB and ADM system numbers out of synch") -- trying to keep the bib and adm numbers in synch (See links to both in Related Articles below.) When you create a doc online, with the GUI client, the system does *not* call correct_last_doc_number: it uses last-doc-number without question.

Thus, I have updated Article 000037616 to indicate that after making the last-doc-number change, you must create a bib record online before running any of these batch jobs. Since this is a one-time scenario, this should work fine.

Article 000042200 requires a change to the ADM library's last-doc-number. The jobs shown above are not usually run in an ADM library, so this should not usually be a problem. One exception is p_manage_12 -- which may be run for the ADM library as part of an upgrade or to fix an LKR problem.

I believe that the jobs call correct_last_doc_number because the p_manage_01 Words index job creates a bitmap and large gaps in doc numbers can result in larger-than-necessary bitmaps. Thus, the system is trying to prevent such gaps. Also, the indexing jobs which create cycles can end up with a lot of empty cycles -- which can create a certain amount of confusion.... But in the case of an ADM library -- where you don't run p_manage_01 or other indexing jobs -- we have found that gaps are not a problem.