Re: Moving WASD from one box to another...

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.
.

Relevant Pages

  • Re: Getting rid of "if condition" by some math equation.
    ... You still have a loop (which the OP ... loops are harder for the JIT compiler and CPU to deal with than one). ... optimizations, those optimizations generally assume certain commonly ...
    (comp.lang.java.programmer)
  • Re: Getting rid of "if condition" by some math equation.
    ... If the OP thinks that it's really worth unrolling the loop, they certainly also should believe that embedding known constants into the logic is also worthwhile. ... (It was also pointed out that the compiler and CPU designers should be trusted first. ... It's that the compiler and CPU _do_ optimizations, those optimizations generally assume certain commonly used patterns, and writing code that attempts to optimize based on assumptions rather than real-world measurements are likely to thwart the ability of the compiler and CPU to optimize, by failing to use those known, commonly used patterns. ...
    (comp.lang.java.programmer)
  • Re: left-to-right (was In-Out Parameters for functions)
    ... optimizations that take advantage of the reordering freedoms, ... without superscalar and OoO support in the CPU. ... superscalar out-of-order CPUs it might make a Master's or PhD thesis. ... freedom to reorder, and the compiler code to take advantage of it, was ...
    (comp.lang.ada)
  • Re: i386 compiles from a x86_64 system?
    ... install. ... That binary will work just fine on 32-bit FC6, ... but the 'default compiler' will not take ... advantage of the actual CPU used, ...
    (comp.os.linux.development.system)
  • Re: WaitForSingleObject() will not deadlock
    ... One is to hijack the semantics of volatile to disable compiler optimizations ... and otherwise let the compiler to agressive optimization. ... Agressive optimizations are the ones that work on the edge of the semantics of the ... Because the compiler can see into lock and unlock, it is able to reduce f ...
    (microsoft.public.vc.mfc)