Alpha to I64 translator

[Joe Gadsby]

I downloaded and installed HP I64VMS MSAI V2.0 and HP I64VMS VMS831H1I_IA64_TIE V1.0

There is no TIE$STARTUP.COM file.

Any ideas what I did wrong ?
Thanks !
-jg-

I64 openvms 8.3-1H1

[Volker Halle · Accepted solution]

Joe,

you first need to download and install

TIE V1.0

Translated Image Environment (TIE) software component for HP Integrity servers (OpenVMS v8.3-1H1 only)

VMS831H1I_IA64_TIE V1.0 is only a patch and not the full TIE product. Please install TIE V1.0 first, then re-install that patch.

Volker.

[Volker Halle]

Joe,

sorry, now I seem to be confused as well !

The web page say TIE is 'integrated' into OpenVMS I64 V8.2-1 and above and you say you're running V8.3-1H1 already.

I'll have to do some more checking...

Volker.

[Volker Halle]

Joe,

TIE$STARTUP.COM (from TIE V1.0) just defines a couple of xxx_AV and xxx_TV_AV logicals - nothing more. I guess these definition will have been included in V8.3-1H1.

Just check

$ SHOW LOG *_AV

So there seems to be no need to include an invocation of TIE$STARTUP.COM. Where did you read the reference to that procedure ? Maybe in the 'old' TIE V1.0 manual ?

Volker.

[Steve Reece_3]

If I remember rightly from a few weeks ago, TIE is integrated but AEST isn't. AEST is a free download from the HP website.

If you still require the TIE$STARTUP.COM, is that part of AEST?

Steve

[H.Becker]

>>>
Any ideas what I did wrong ?
<<<

Nothing. What's the problem other than that there is no startup file, which doesn't seem to be necessary?

It's all in the names. TIE is Translated Image Environment, which is integrated into VMS. It didn't ship with the initial versions of VMS for I64, so there was a TIE 1.0 kit. VMS831H1I_IA64_TIE-V0100 is an ECO for TIE on VMS V8.3-1H1.

To translate an image you do not need the TIE. To run the translated image you need the TIE.

The translator from Alpha to I64 aka AEST (Alpha Environment Software Translator) is the MSAI (Migration Software for Alpha to Integrity) product aka OMSAIS (HP OpenVMS Migration Software for HP Alpha to Integrity Servers) with a kit name HP-I64VMS-MSAI-V0n00--1. (whatever the current n is). You donwloaded version 2. Here I64 indicates that the translator runs on Integrity. There was and still may be translators running on Alpha (which may have a kit name like HP-AXPVMS-V0n00--1)

So you should have everything you need on/for your V8.3-1H1.

[Joe Gadsby]

Hi

I was looking an older install manual, that's where I came up with the TIE$STARTUP

On the Integrity server:
I did a "Sho log _AV" and there are 38 "_AV"
logicals, so that looks like it is set up correctly.

I tried it, and it seems to work !

$ AEST RS162.EXE

This created a RS162_AV.EXE.

I run this, after setting up the required logicals for RS1 and it names another file not translated. So I'm stepping through these.

The only error so far is ...
%AEST-W-PRIVSS, Image calls system service SYS$CMEXEC. Execution of privileged
code in a translated context is not supported
%AEST-W-TRANSWARN, Translation completed with warnings -- review them before using the output image

On the Alpha, RS1 was linked with Dec Windows, so I've been bringing those files over as well and running this on them. It chokes on the file DECW$SETSHODISSHR.EXE

The vendor doesn't have a I64 version of RS1 and, naturally, it's used a lot here.

Thanks !
-jg-

(Somewhere it's 5pm !)

[Volker Halle]

Joe,

AEST only supports 'user-mode OpenVMS Alpha images' !

If your .EXE files include routines that require running in non-USER mode - as evidenced by the reference to SYS$CMEXEC, you might be out of luck. If that code is NOT called during run-time, the translated image MIGHT work on OpenVMS I64, but the chances are pretty low.

Volker.

[H.Becker]

It's not obvious to me which image gives you the %AEST-W-PRIVSS. At least, you do not need to translate the DECWindows images, they are available as native ones. If you can't find them on the I64 server, then the DECWindows client is not installed.

[Joe Gadsby]

DECwindows IS installed.

I brought the RS1 directory over and started converting.
I converted RS162.exe and when I ran RS1R62_AV.EXE, the message "RS162ALL_AV.EXE file not found"

I converted RS1R62ALL.EXE and ran RS1R62_AV and a different file_AV.exe was not found.

I converted THAT one and ...

Each step got a little further down the road until it is at the point where it just hangs.

CTRL-T, CTRL-Y, CTRL-C have no affect on it.

I think we're SOL at this point.
Thanks !

-jg-

[Robert Gezelter]

Joe,

At some loss of efficiency, a translated image can invoke a native mode shareable library. I demonstrated this (and the performance implications) in my OpenVMS Technical Journal article on strategically using binary translation. This article, "Strategies for Migrating from Alpha and VAX systems to HP Integrity Servers on OpenVMS" is reachable at: http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.html.

Why are you translating the DECWindows images?

- Bob Gezelter, http://www.rlgsc.com

[Joe Gadsby]

Hi

I'm translating the DECwindows because it asks for it.

I translated RS162.exe and ran it.
It got past RS162_AV and said RS162ALL_AV was not found.

I translated that and ran RS162_AV.EXE and got -
-----------------
PROMB4->RS1
%DCL-W-ACTIMAGE, error activating image DECW$XTLIBSHRR5_AV
-CLI-E-IMAGEFNF, image file not found PROMB4$DKA7:[SYS0.SYSCOMMON.][SYSLIB]DECW$
XTLIBSHRR5_AV.EXE;
------------------

I translated DECW$XTLIBSHRR5.exe and got

-----------------
PROMB4->RS1
%DCL-W-ACTIMAGE, error activating image DECW$XTLIBSHRR5_AV
-CLI-E-IMAGEFNF, image file not found PROMB4$DKA7:[SYS0.SYSCOMMON.][SYSLIB]DECW$
XTLIBSHRR5_AV.EXE;
--------------------

I continued to "translate" until it stopped erroring out.

The decision to translate was made because the vendor doesn't support Integrity server yet and when I DID try to install I got

%ILINK-F-NOTOBJLIB, file SYS$SYSDEVICE:[RS1R62.BUILD]CALLABLE.OLB;1
is not an object library

I don't know how/why it is looking for the DECwindows_AV files.

Thanks !

-jg-

[H.Becker]

>>>
DECW$XTLIBSHRR5_AV
<<<
The native DECW$XTLIBSHRR5 seems to be available, it is on the system I currently have acces to. I would try to define DECW$XTLIBSHRR5_AV to DECW$XTLIBSHRR5. At the moment I don't understand why the _AV version is asked for. I would check if AEST put it into one of the translated images. ANALYZE/IMAGE should tell you. With the right qualifier set AEST may be able to tell you that at translation time as well.

As far as I can see, there is no need for a translated DECW$XTLIBSHRR5.


>>>
The decision to translate was made because the vendor doesn't support Integrity server yet and when I DID try to install I got

%ILINK-F-NOTOBJLIB, file SYS$SYSDEVICE:[RS1R62.BUILD]CALLABLE.OLB;1
is not an object library
<<<

It looks like the installation links at least one image and the OLB is not an I64/Elf object library.

[Volker Halle]

Joe,

from the HP OpenVMS Migration Software
for Alpha to Integrity Servers Release Notes (Feburary 2005):


DECwindows applications are not supported by HP OpenVMS Migration Software for Alpha to Integrity Servers (OSMAI).


Volker.

[Steve Reece_3]

Have you got a web link for that document Volker? I'm interested in it as I suspect that higher level language calls for RDB won't be supported either...

Thanks
Steve

[Volker Halle]

Steve,

that document (HP OMSAIS release notes )is available on the HP OMSAIS download page:

http://h71000.www7.hp.com/openvms/products/omsva/osmai_release_notes.pdf

Volker.

[Robert Gezelter]

Gentlemen,

Please pay careful attention to "Not supported". In many cases, this means that the needed transfer vectors were not created. Creating the transfer vectors is not a difficult task.

Once the needed transfer vectors are created, calling between translated and native images works fine.

In the case of installation scripts, some custom engineering may be needed. Without having had a detailed look at this particular case, I would presume from the description that what may be necessary is the creation of a shareable library on Alpha, which is then translated. This shareable library can then be used with native code.

Been there, done that. In the case of my article, I actually developed a whole suite of test libraries, and ran identical benchmarks on all of the assortments to better understand the performance implications of applications where various parts of the suite were native and invoking translated code, and vice versa.

There is certainly no magic here, it is very well documented in both the documentation and in the Digital Technical Journal articles from the original Alpha migration.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

For these corner cases and for what are effectively, well, abandoned applications and tools, the use of Alpha emulation can be a better choice.

With a solution that's based on not messing with "it" more than you and the vendors of any constituent and prerequisite components are willing to mess with "it".

Then (and if and when applicable) start planning for a more substantial migration of your applications, or of your data and what the marketeers call "business logic." At why you started painting this fence, and what options might be available.

Or, and depending on your relationship with the vendor here, work on a native port of whatever third-party application is in use here. Sometimes that's a big project. Sometimes not.

Without intending disrespect to anyone involved here and to anyone that's worked on or using VEST and TIE, the OMS stuff will eventually force a migration; it's a stopgap approach at best. Emulation is a similar stopgap, but (when it works) with (comparatively) less effort to get to an operational configuration.

[Joe Gadsby]

Hi

I went through the installation/compiling/etc options and was able to take out any (and all) areas regarding DECwindows.

I redid the installation on a test alpha and it all worked there.

I copied everything over to the Integrity server and ran the AEST thing on all .EXE

It works !!! (?)

Thanks for all the advice & comments !

-jg-

[Joe Gadsby]

closed