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.