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

[Mark Daniel]

Jan-Erik Söderholm wrote:
> 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...

I have only superficially investigated the specific performance 
advantage(s) available in later CPU types and whether or not these 
actually translate into measurable WASD performance improvements and/or 
CPU efficiencies.  I'm guessing yes but as most WASD servers spend much 
of their time idling anyway those shops that do make serious application 
demands would have their own internal expertise to draw on.  Over the 
years I have received no comments along those lines.

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

Useful, perhaps essential, for a development shop that often has much 
smaller (and cheaper to licence) systems for building the production 
applications.

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

I sure others here can comment authoritatively on compiler construction.

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

In a mixed CPU type cluster I encountered just such a non-functional 
build.  Though this was *many* years ago, perhaps pre-7.n, and the 
detail now escapes me.  At times our clusters concurrently accommodated 
various combinations of EV4, EV45, EV56, EV67 and EV68.

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

I've never explicitly used the syntax.  Just considered <> were some 
arcane pre-VMS accomodation.  Certainly some procedure file paths are 
built using explicit '+ "]"' and so forth so it doesn't surprise 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.

IIRC you make a RFC some time ago.  Good luck.

> Jan-Erik.