[Info-vax] Moving WASD from one box to another...

[Mark Daniel]

Hello Jan-Erik.

Jan-Erik Söderholm wrote:
> Hi.
> Let's say I have two similar Alphas, same VMS and
> TCPIP version, incl patches and all. One has C compiler
> (the "dev" box) the "prod" box has not. One (the dev)
> is an AS800/EV56, the prod box is an DS20e/EV67, if
> it matters.
> 
> Now I have a compiled, linked and working install on
> the "dev" box. Can the whole dir structure just be
> moved over to the "prod" server, or would it be
> best to re-link everything also ?

Linking is a relatively inexpensive step but if everything O/S, etc., is 
equivalent it should be an unnecessary one.

With differing types of CPU there *are* some considerations.

By default WASD builds to a base of VMS V6.0 and on Alpha with a generic 
compile.  So far there have been no default build object kits 
distributed that have been reported with issues across various CPU types 
(EV56, 67, etc.)

However, it is *possible* to build with specific optimisations during an 
installation/update.  It prompts

   By default the server image is built with the VMS version set at a
   base level of V6.0 and generic compiler optimizations.  It is also
   possible to build it against the currently installed VMS version
   and with local optimizations.  This may provide some performance
   improvements and/or efficiencies.

     /OPTIMIZE=(INLINE=AUTO,LEVEL=4,UNROLL=0,TUNE=HOST)

   In a cluster with a common WASD installation, mixed systems and CPU
   levels this might result in a functional but less-than-optimal build
   for some.

   Build using local system optimizations? [NO]:

and also

   Further optimization can be made by the compiler based on the CPU
   family (i.e.EV4, EV5, EV56, EV6, EV67, etc.).  This may provide
   significant performance improvements and/or efficiencies on later
   families of CPU.

     /OPTIMIZE=(INLINE=AUTO,LEVEL=4,UNROLL=0,TUNE=HOST) /ARCHTECTURE=HOST

   CAUTION: In a cluster with a common WASD installation this might
   result in a non-functional build for systems with different family
   or older CPUs.

   Build using local host optimizations? [NO]:

Provided a vanilla build or optimised for comparable CPU types it should 
be straight-forward.  I'm unsure how 'backward compatible' 56 -> 67 
would be.  Optimised on 67 I guessing 57 would complain.

> There might be (but I think the startup scripts
> fixes it automaticly) some minor changes to some
> COM files.

The only other things that spring to mind ...

1) If the systems are clustered the server and scripting accounts and 
identifiers should already exist in the cluster-common databases.  If 
not these will be absent from the target system and must be created.

This can be done by using the $ @INSTALL procedure on the target system 
once the WASD tree has been put in place.  Each step of that 
installation may be individually declined so it's just a matter of 
working through the various stages and using only the account creation 
portion of the procedure.

                      **********************************
                      *  CREATE/MODIFY SERVER ACCOUNT  *
                      **********************************

And so forth.

The INSTALL.COM procedure complains if it detects the system already has 
WASD instantiated on it.  This can be overridden using

   $ @ INSTALL INSTALL

2) Subsequent to account creation it might be a good measure to also

                         *****************************
                         *  (RE)SECURE THE PACKAGE?  *
                         *****************************

   Begin to make changes to files and security settings in the package.

   Secure the package? [NO]:

ensuring that there have been no file-system confusion (ACLs, 
identifiers, etc.) during the transplant (ZIP, BACKUP?) of the WASD tree.

> Jan-Erik.

Undoubtedly there will be others :-{

Cheers, Mark.