We have been using links for many years and have roughly (there are go-lives in progress) 15 types of application used in 13 hospital sites and we have 70 active production sites.
We use links for tclprocs at a ‘global’ level, so that the same tclprocs (we use TCL for almost all our translations) is available to all roots and have the other at a ‘local’ level.
ie
We are ‘InfoHEALTH’ and have /hci/InfoHEALTH/src/tclprocs/app1|app2|app3…
and /hci/rootx.x.xP/InfoHEALTH/tclprocs|Tables|Xlate etc
We believe that this provides significant saving in maintenance etc.
En example is an update to a new TCL translation script. We create a second directory, adding the new code and the update is simply to change the link and bounce the threads. If we need to back-out the change, the link is reverted and the threads are bounced again.
The ‘real’ benefit comes because we can test the actual production code by using a ‘dummy’ production site.
We use RCS id’s in all TCL scripts that output to a log file on thread startup, so we use a shell script to change sites, move links and bounce threads and prove that the correct revision is installed.
I hope this helps
