20.1.1 p_publish_06: "Param Initialization Failure"
- Article Type: General
- Product: Aleph
- Product Version: 20
Description:
In upgrading to 20.1.1, p_publish_06 is not behaving as before. When we specify "N" (No update), the parameter is changed to "Y" (see log info below).
Load: /exlibris/aleph/u20_1/alephe/tab/tab100
Load: /exlibris/aleph/u20_1/iow01/tab/tab100
ALEPH/AIX, Copyright Ex Libris.
version 20 revision 01 copy 1, 15-Feb-2009
start ABC01,PRIMO-FULL,FILE,000000000,999999999,00000000,99999999,klaa,/aleph01/xfer,N,3
procedure=p_publish_06
Fixed param: ABC01,PRIMO-FULL,FILE,000000000,999999999,00000000,99999999,klaa,/aleph01/xfer,Y,03,
setenv p_active_library "ABC01"
setenv p_publish_set "PRIMO-FULL"
setenv p_publish_type "FILE"
setenv p_start_doc_number_x "000000000"
setenv p_end_doc_number_x "999999999"
setenv p_date_from "00000000"
setenv p_date_to "99999999"
setenv p_input_file_name "klaa"
setenv p_path "/aleph01/xfer"
setenv p_update_flag "Y"
setenv p_no_process_x "03"
2nd param (target and user name):
3rd param (log file name):
Load: /exlibris/aleph/a20_1/aleph/tab/tab_job_type
Load: /tmp/utf_files/exlibris/aleph/u20_1/alephe/error_eng/p_publish_06
Param Errors Found:
F09: Updating is allowed only when working on all records or from last timestamp.
Wrote Z100 record with rec-key: 000000470
Load: /exlibris/aleph/u20_1/alephe/tab/tab100
Load: /exlibris/aleph/u20_1/abc01/tab/tab100
Load: /tmp/utf_files/exlibris/aleph/u20_1/abc01/tab/pc_tab_exp_field.eng
Load: /tmp/utf_files/exlibris/aleph/u20_1/abc01/tab/pc_tab_exp_field_extended.eng
Info: Empty table /tmp/utf_files/exlibris/aleph/u20_1/abc01/tab/tab_alert
end
Param Initialization Failure, Exiting !!!
We are able to get around this only by reverting to the previous version of the program which checks parameters.
Resolution:
As described in v20 rep_change 2057, "The batch job "Create Tar File for ALEPH Published Records" (publish-06) has two new parameters:
1. scratch_path - Allows modifying the directory where the temporary files are located (the default is $data_scratch)
2. zip_flag - Allows to define if the output files are compressed or not (the default is Y, Yes).
When I submit the job on our server, I see these two parameters in the job log after the setenv p_no_process_x, that is:
setenv p_no_process_x "01"
setenv p_scratch_path ""
setenv p_zip_flag "Y"
whereas your log's parameters end with the setenv p_no_process_x.
The rep_change's "Unix Files" section shows that a new ./aleph/pc_b_eng/p-publish-06.xml has been added to the a-tree.
Since it seems that this is not being used, you must have a local $alephe_root/pc_b_eng/p-publish-06.xml which is taking precedence over the new a-tree version. If so, you need to add the p_scratch_path and p_zip_flag setenv's to it, as shown in the rep_change Implementation Notes. (A "diff" of the $alephe_root/pc_b_eng/p-publish-06.xml and the $aleph_root/pc_b_eng/p-publish-06.xml should also show this.)
- Article last edited: 10/8/2013