The Question is:
What we are trying to accomplish is to have a common code library in CMS on the
Alpha and centralize object libraries on the Alpha but allow programmers to
compile code on the vax without having to copy many files over to the vax. Can
you have the link li
brary logicals pointing to .OLB files on the Alpha?
I am able to do a Lib/lis and lib/extract command with no problems.
The Answer is :
First, please ignore the error messages and the problems reported
with the current approach, and consider the implications of your
First, think how OpenVMS libraries are processed. The LINKER must
read through the library "index" several times attempting to resolve
the symbols. For any resolved symbol, it must then locate and load
the object module.
Now consider the way that a programmer will typically work. Typically,
an application will cucle through the compile/link/test cycle numerous
Now think about the nature of the "standard" libraries. Hopefully, they
are relatively stable (and are organized into shareable images whenever
possible -- please see the Shareable Image Cookbook for details; see the
OpenVMS FAQ for pointers).
When the libraries reside on another system accessed via a network file
specification, the LINKER process effectively must copy parts of the file
across the network, potentially multiple times per link -- the exact
number of copies depends on the efficiency of the host buffering. This
must be repeated for each LINKER operation. You will also need to start
network FAL processes on the remote node to service the incoming file
request, potentially one process per network file.
It doesn't much matter what disks or network hardware you have, it's almost
certain that the network I/O will be substantially slower than I/O from a
local disk. So, unless the updates to the libraries are very frequent, or
the libraries contain very large numbers of routines that are rarely
referenced, then you're almost certainly better off copying the libraries
once a day or once a week depending on their update frequency. The more
LINKER operations performed by programmers, the performance more you win
by maintaining local copies. It's a very simple matter to create a small
DCL procedure to synchronize local copies with your master copy on a known
host. (hint: use the F$CVTIME(F$FILE_ATTRIBUTES(file,"RDT")) to compare
Alpha, VAX and Itanium object modules (and hence libraries) have different
formats. You can certainly store VAX object libraries on Alpha systems,
and you should be able to access them via a network file address -- it's
all just bits to the Alpha system. However, for best performance, the
OpenVMS Wizard would tend recommend against this approach.
The OpenVMS Wizard has performed some simple experiments with network file
specifications and link libraries, but is unable to reproduce the error
message you describe. If you wish to persue the issue, please log a case
with your local customer support centre, and be prepared to provide example
code to reproduce the condition.
Probably the easiest solution here is to cluster at least one OpenVMS
VAX and one OpenVMS Alpha host together -- the CMS libraries can be
common, as can the build and test procedures. No copying, and direct
access to the files.