Skip to main content
ExLibris

Knowledge Assistant

BETA
  • Subscribe by RSS
  • Back
    Aleph

     

    Ex Libris Knowledge Center
    1. Search site
      Go back to previous article
      1. Sign in
        • Sign in
        • Forgot password
    1. Home
    2. Aleph
    3. Knowledge Articles
    4. Automatic resetting of last-doc-number by system

    Automatic resetting of last-doc-number by system

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    1. Additional Information
    • 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.

    Additional Information

    Random items, holdings, etc. attached to new bib records.
    BIB and ADM system numbers out of synch.


    • Article last edited: 4/16/2014
    View article in the Exlibris Knowledge Center
    1. Back to top
      • Automatic recalls without running p_cir_13
      • Automatic start of Aleph and Oracle after server reboot
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Aleph
    2. Tags
      1. 20
      2. automatic resetting
      3. contype:kba
      4. LAST-DOC-NUMBER
      5. Prod:Aleph
      6. Type:General
    1. © Copyright 2025 Ex Libris Knowledge Center
    2. Powered by CXone Expert ®
    • Term of Use
    • Privacy Policy
    • Contact Us
    2025 Ex Libris. All rights reserved