| Hi Andrew
You are right that the OA$SITE_DO_SHARE is a search path of
[ALLIN1.SITE.DO_SHARE] and [ALLIN1.SFCP.DO_SHARE]. So in such
case, I should not have use CM to perform the customization, I should
have chagned the file directly under [ALLIN1.SFCP.DO_SHARE].
Then I thought of defining OA$DO_SHARE to be a search path of
[ALLIN1.DO_SHARE] and [ALLIN1.SFCP.DO_SHARE] and OA$SITE_DO_SHARE to
be [ALLIN1.SITE.DO_SHARE] and [ALLIN1.SFCP.SITE.DO_SHARE] so that
the client can still keep an original copy of SFCP element.
But I wonder is there any harm to put all SFCP element into the A1TXL ?
If it is not recommanded, I would suggest my client to set up another
directory to store the original copies of SFCP elements or put them
into CMS.
Thank you very much
Banquo.
|
|
Hi Banquo,
> You are right that the OA$SITE_DO_SHARE is a search path of
> [ALLIN1.SITE.DO_SHARE] and [ALLIN1.SFCP.DO_SHARE]. So in such
> case, I should not have use CM to perform the customization, I should
> have chagned the file directly under [ALLIN1.SFCP.DO_SHARE].
???
Why not using CM? Because the SFCP_* elements are not defined in CM?
That shouldn't be a reason. Although there is the quirk that the elements in
[.SFCP] are included in the CMTXL, using CM at least keeps track of your
modifications.
> Then I thought of defining OA$DO_SHARE to be a search path of
> [ALLIN1.DO_SHARE] and [ALLIN1.SFCP.DO_SHARE] and OA$SITE_DO_SHARE to
> be [ALLIN1.SITE.DO_SHARE] and [ALLIN1.SFCP.SITE.DO_SHARE] so that
> the client can still keep an original copy of SFCP element.
> But I wonder is there any harm to put all SFCP element into the A1TXL ?
> If it is not recommanded, I would suggest my client to set up another
> directory to store the original copies of SFCP elements or put them
> into CMS.
To me I don't see any harm in putting the SFCP elements in the A1TXL. The
reason why I think it has been done is that SFCP is a modification to the WP
subsystem (together with the �10 standard ALL-IN-1 elements which have been
changed (and entered in the Site modification log))). So, $ALLIN1/NOCUSTOM
would in that case definitely not call anything related to SFCP.
However, the above is an assumption. We've never tried including the elements
in the A1TXL, so I can't give you a definite answer. So be carefull.
But, if you're are thinking of doing it, you need to modify
SYS$STARTUP:A1SFCPSTART.COM to make sure that e.g. OAX$SFCP_DO_SHARE is not
associated with OA$SITE_DO_SHARE:, but with OA$DO_SHARE: Check the part for
redefinitions at label 'Modify_Def_A1_Search_Lists'. Following is the change as
I think should do the trick (untested):
.
$Modify_Def_A1_Search_Lists:
$!
$ log_name = "OA$LIB"
$ new_trans = "OAX$SFCP_LIB"
$ gosub Redefine_Search_List
$!
$ log_name = "OA$DO_SHARE"
$ new_trans = "OAX$SFCP_DO_SHARE"
$ gosub Redefine_Search_List
$!
$ log_name = "OA$SITE_DO_SHARE"
$ new_trans = "OAX$SFCP_SITE_DO_SHARE"
$ gosub Redefine_Search_List
$!
$ log_name = "OA$BLP_SHARE"
$ new_trans = "OAX$SFCP_BLP_SHARE"
$ gosub Redefine_Search_List
$!
$ log_name = "OA$SITE_BLP_SHARE"
$ new_trans = "OAX$SFCP_SITE_BLP_SHARE"
$ gosub Redefine_Search_List
$!
$ log_name = "OA$BLP_LLV"
$ new_trans = "OAX$SFCP_BLP_LLV"
$ gosub Redefine_Search_List
$!
$ log_name = "OA$SITE_BLP_LLV"
$ new_trans = "OAX$SFCP_SITE_BLP_LLV"
$ gosub Redefine_Search_List
$!
$! Make sure SFCP Archive data files are world writable.
$ set protection = (g:rwe,w:rwe) -
oax$sfcp_data_share:sfcp_archive_docs_pending.dat
$ set protection = (g:rwe,w:rwe) -
oax$sfcp_data_share:sfcp_archive_docs_pending_recovery.dat
$!
$Modify_Lang_A1_Search_Lists:
$!
$ save_a1table = a1table
$ a1table = "''a1prefix'''ALP_Language'_table"
$ log_name = "OA$BLP_LLV"
$ new_trans = "OAX$SFCP_BLP_LLV"
$ gosub Redefine_Search_List
$!
$ log_name = "OA$SITE_BLP_LLV"
$ new_trans = "OAX$SFCP_SITE_BLP_LLV"
$ gosub Redefine_Search_List
$ a1table = save_a1table
$!
$ return
.
Re-run A1V24START.COM which should redefine the logicals.
Within CM you should then specify the Live location of the SFCP element(s) to
be one of the OAX$SFCP_SITE_*: dirtectories.
Ciao,
Simon
|