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

[Jan-Erik Söderholm]

Mark Daniel wrote:
> 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.

Yes, I did that when compiling/linking on the EV56 dev system.
I guess these builds would be upward compatible with the prod
EV67 system. And anyway, there is no C-compiler on the prod system
so I can't run an optimized build for that one anyway. Hm, maybe
it would be a good idea to replace the (now old) AS800 dev
system with some smaller EV6-type system more in-line with the
EV67 prod system. That way, one could also optimize the main
COBOL apps better for the EV67 prod environment. I noticed that
the /ARCH and /OPT switched for COBOL makes a difference
between EV56, EV6 and EV67...

B.t.w, as I read the COBOL HELP texts, it seems as on should be
able to actualy build for an EV67 environment even if built
on an EV56 box, the EV67 specific parts will be emulated on
the EV56 dev box, which is OK if that makes the prod
system run faster.

The CC compiler has the same writing in the HELP texts, so I guess
this emulation of higher-EV-code is not tied to the compiler
itself.

And no, this are not clustered systems. Just two separate systems.


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

As I read the HELP texts, this will be handled by the built-in
emulation in VMS 7.1 (and "better", and with a possible performance
hit) so I'm not sure it will be "non-functional", will it ?

> This can be done by using the $ @INSTALL procedure on the target system 
> once the WASD tree has been put in place.

Yes, I thought about running the "account creation" and
"security setting" steps of the INSTALL script.

One final note...

The INSTALL* scripts do not like it if I have SET DEF using
"<>" instaled of "[]". I always use <> when doing things "by hand"
since that are easier to type "for me".

In all, WASD looks realy nice, I've been a long time user
of OSU, but WASD seems to have more momentum at the moment.

Jan-Erik.