[Info-vax] SYS$SYSROOT and Local Customizations
geze...@rlgsc.com
gezelter at rlgsc.com
Fri Oct 23 13:26:55 EDT 2020
On Friday, October 23, 2020 at 12:37:30 PM UTC-4, Stephen Hoffman wrote:
<deleted in the interest of brevity>
Hoff,
WADR, we have different perspectives on this issue.
I will agree with you that it is important to modify the searchlist properly, fragile methods are a poor choice. I will also agree that there have been no shortage of poor choices made when designing and implementing various additions.
However, it can be done reasonably robustly, and is fairly safe. The approach has been used by a number of layered and integrated products, including the VAX-11 RSX AME and DECwindows. Other products, including a major third party database product, have had longstanding reported bugs associated with doing the modification of SYS$SYSROOT incorrectly (Personal experience. I fixed the problem, then went into the bug report database and found a reported bug involving DECwindows).
I described almost precisely the scenario described by Phillip in my OpenVMS Technical Journal paper, "Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters" , copy at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html.
The key to properly inserting into SYS$SYSROOT and for that matter, any arbitrary search list is to not append or prepend the addition to the full translation, but to insert the new entry at the correct precedence in the search order. The lexical function F$TRNLNM is the key here, particularly the use of the Item code MAX_INDEX.
One also has to ensure that the disks containing the shared files are mounted before they are referenced. One also needs toproperly configure the STARTUP to function correctly if the shared files are not available.
Done properly, a useful techniqueue. Done without proper care, serious problems can ensue.
- Bob Gezelter, http://www.rlgsc.com
More information about the Info-vax
mailing list