Variables in v16 aleph_start omitted from v18 aleph_start
- Article Type: General
- Product: Aleph
- Product Version: 18.01
Description:
Can you please help us with these questions about merging our old and new aleph_start file?
Resolution:
> vir01 is not in the v18 QUE_STARTUP_LIBS, but is in our v16. OK to add it back? Or is it no longer needed there? (We believe it was there to facilitate clearing files from it.)
<<Js VIR01 *does* need to be in QUE_STARTUP_LIBS (so the vir01 batch queue will start when aleph is restarted -- if the batch queue is not running, then clear_vir01 will not run.
> We have “setenv apache_version apache_1.3.27� in v16. Should there be a similar entry in v18? Or, is that what the new “setenv APACHE_MEDIA …� entry is for?
<<js APACHE_MEDIA is not the same. It seems that in version 18, "setenv apache_version" *can* be in aleph_start but does not have to be. SI 36212 says:
The problem was fixed in version 18 -
v.18.01 rpv #11680
In lower versions the variable setenv apache_version must be removed from the aleph_start file
> In v16 we have these entries:
> setenv new_ue_01 Y
> setenv new_marcive_loader Y
<<Js These are no longer used in version 18. They "new..." has become the default (and only) version of these.
> setenv prb44624 Y
<<Js rep_ver 9393 (V17), was done for the PRB 44624 as well as rpc 646 in V16. In V16 in rpc 646, a parameter is used (named "prb44624") which causes the fix to be active only if this parameter is defined. In rpv 9393 (V17 and V18), the fix is always active.
> setenv p_cir_04_sort_12 BA
<<js Can't find anything on this. If it's working OK in v16, I suggest you include it in v18. (In the worst case, it will just be ignored.)
> We removed the “2� from the entry “setenv correct_852_subfields “2hijklm�� in v16. Is there any reason that we should not remove it from v18?
<<Js If you have “setenv correct_852_subfields “2hijklm�� in v16, then you should have the same in v18.
Additional Information
faq
- Article last edited: 10/8/2013