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

    ue_01: "INTERNAL LENGTH NOT CORRECT" ... compress_data_ads.gnt"

    1. Last updated
    2. Save as PDF

     

    • Product: Aleph
    • Product Version: 20, 21, 22, 23
    • Relevant for Installation Type: Dedicated-Direct, Direct, Local, Total Care

    Description: 

    The z98 table space was exceeded. Table space was added, but, since then, the ue_01 indexing daemon has been crashing. The event appears to be related to a particular record in the z98 table as the run_e_01_word.nnnn log message is: 

      Update z98 from z980 : 010001417248 
      INTERNAL LENGTH NOT CORRECT!! 010001417248 

      Execution error : file '/exlibris/aleph/a22_1/aleph/exe/compress_data_ads.gnt' 
      error code: 114, pc=0, call=1, seg=0 
      114 Attempt to access item beyond bounds of memory (Signal 11) 

    We suspect that the z98 map_length fields for record 010001417248 have become corrupt, but the problem may extend to additional records as well. The Z98_TOTAL_MAP_LENGTH for the 67th row for this word has a higher value than the other 66 rows. We suspect this was the point in update in which the table_space issue was encountered, and the process finished mid-update. 

    This issue is affecting Primo as records in z07A are not being processed, so the corresponding z07P records are not created. 

    Resolution: 

    The problem occurs because the indexing daemon has allocated a buffer based on the lower, incorrect value for z98_total_map_length and the buffer overflows. The following was done to correct this: 

    * Locate cases for this z98 (same Z98-FIELD-NUMBER/Z98-REC-NUMBER) where the last Z98 has a different (higher) z98_total_map_length than the other z98's with this Z98-FIELD-NUMBER/Z98-REC-NUMBER 
    * Update the z98_total_map_length in these other z98's (via SQL) to the correct value 
    * Delete the z95 records for these other z98's (via SQL) and resend these records for indexing. 

    Note: saving the records to the server and Immediate Update of a Single document (util_f_1_13) will *not* update ” index unless the z95 is deleted. EL Development analyzed the situation as follows: 

    The indexing of these BIB docs did not occur because an array of words-per-doc is built on-the-fly, and the program compares this array to the existing one (the Z95). If no change, it is not updated. 
    In this case, Z95 (words-per-doc) was fine, Z98 (docs-per-words) was the corrupted one. So creating z07 yields no change. The only way to update the indexing is either to make a change to the bib record, or to delete the Z95 record for this doc (by SQL command) then create z07. 

    Note 1: Ex Libris Aleph Support should be involved when this problem is encountered. 
    Note 2: The problem can be solved by running the manage-01 Word indexing -- but, as that is time-consuming, the above procedures are intended as a way of avoiding that. But for a Test server, where time is not so much of an issue, manage-01 *is* normally the best solution.
     

    Additional Info / Related Articles    

    In this case, no z980 records were involved (just z98 records).  Consult the "Analysis" section of Article "ue_01: Update z98 from z980 ... INTERNAL LENGTH NOT CORRECT!! " in this regard.  

     

    • Article last edited: 28-Feb-2016