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

    z13_year in ADM library

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

    We use z13 records in our ADM library abc50. They are fine apart from the fact that z13_year is always 0000. The relevant line in tab22 is identical in abc50 and abc01:

    YEAR 1 008 0008

    The help for p_manage_07 suggests that the only expand required is expand_doc_adm_bib. We have tried expand_doc_yr with CREATE-Z13, but without success.

    Is it possible to display the 008 date in z13_year in abc50 as is it displayed in abc01, and how can that be achieved.

    The reason for the 0000 year is that the 008 exists in the ADM as well as the BIB, and when the build_z13 program is looking at the record with the bib fields expanded into the ADM, the 008 which it sees first -- and uses -- is that from the ADM record.

    There are two possible solutions:

    1. Use the manage-21 (Global change) program in the xxx50 ADM library to delete the 008 from the ADM records -- after which, the build_z13 program will find the only 008 expanded from the bib record. {Note: typically, the only useful information in the ADM 008 is the date that the ADM record was created (bytes 00-05) and the language (bytes 35-37). These values are *not* used by Aleph. And when the ADM record is being exported, they could be expanded from the bib record.}

    2. Since the ADM z13 is used only by the local, customer SQL -- and is not used *at all* by Aleph -- drop the ADM z13 and use the bib z13 table, linked to the ADM via the z103 table, as described in Article 000046573 ("Joining bib Z13 table with adm Z30 table in SQL") below.

    Additional Information

    Article 000046573  Joining bib Z13 table with adm Z30 table in SQL 

    Note:  The original Resolution had these additional paragraphs, which would likely apply only in certain unusual cases:
      We tried changing the 008 to the 260c in the xxx50 tab22, but it does not work when the 260c is preceded by "c" or is enclosed in square brackets, in which case z13-year remains 0000.
      There is no way around this latter problem; the year is expected to be 4 characters long. 

    Category: Cataloging

    • Article last edited: 10/8/2013