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: 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)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • problems about gcc installation
    ... i need to install gcc, and when i install it, the following problems ... configure: loading cache ./config.cache ... checking for C compiler default output file name... ... checking whether the linker supports shared libraries... ...
    (comp.unix.programmer)