Migrating to Integrity using AEST

[Jeremy Begg]

Hi,

A customer has asked me to move their environment from Alpha to Integrity. We have the application source code and can recompile it. It would appear that almost all the 3rd-party code is available for Integrity.

The problem is two software components for which we don't have sources.

1. There is an old program used to generate an annual calendar of events. The source code disappeared long ago. When we moved from VAX to Alpha in 20002 I used VEST to translate the image. I've just tried using AEST to translate the VESTed image, but the result isn't so good:

$ d /since

Directory D2:[ASADAY]

ASADAY_TV_AV.EXE;1 1080/1088
ASADAY_TV_AV.LIS;1 32956/32960

Total of 2 files, 34036/34048 blocks.

$ run asaday_tv_av.exe
%DCL-W-ACTIMAGE, error activating image
-CLI-E-IMAGEFNF, image file not found $12$DKA0:[SYS0.SYSCOMMON.][SYSLIB].EXE;

$ anal/image/inter asaday_tv_av.exe
This is an OpenVMS IA64 (Elf format) executable image file

Image Identification Information, in section 3.

Image name: "ASADAY_TV"
Global Symbol Table name: "ASADAY_TV"
Image file identification: " "
Link identification: "V1.1A-0"
Link Date/Time: 6-DEC-2002 09:34:39.16

Image Transfer Information, in segment 6.

Main Transfer
Entry Address: 0000000000092700 (segment 4.)
GP Value: 00000000002C0000

Image Activation Information, in segment 7.

Global Pointer: 00000000002C0000
Link flags
Call SYS$IMGSTA
Image has main transfer
TIE Signatures present
Maintain relative position of segments

Shareable Image List
TIE$SHARE
(LESS/EQUAL, 2., 1000.)
BASRTL_TV_AV
(LESS/EQUAL, 1., 12.)
LIBRTL_TV_AV
(LESS/EQUAL, 1., 14.)

The images listed in the "Shareable Image List" all appear to exist:

$ show log/full basrtl_tv_av
"BASRTL_TV_AV" [exec] = "BASRTL_D56_V73_TV_AV" (LNM$SYSTEM_TABLE)
$ show log/full librtl_tv_av
"LIBRTL_TV_AV" [exec] = "LIBRTL_D56_TV_AV" (LNM$SYSTEM_TABLE)

$ d sys$share:tie$share,BASRTL_D56_V73_TV_AV,LIBRTL_D56_TV_AV

Directory SYS$COMMON:[SYSLIB]

TIE$SHARE.AIIF;1 47/48 19-DEC-2005 17:48 [SYSTEM] (RWED,RWED,RE,RE)
TIE$SHARE.EXE;1 3305/3312 21-FEB-2005 18:48 [SYSTEM] (RWED,RWED,RE,RE)
BASRTL_D56_V73_TV_AV.EXE;1 8100/8112 21-FEB-2005 19:14 [SYSTEM] (RWED,RWED,RE,RE)
LIBRTL_D56_TV_AV.EXE;1 2099/2112 21-FEB-2005 19:06 [SYSTEM] (RWED,RWED,RE,RE)

Total of 4 files, 13551/13584 blocks.

I noticed a comment in the AEST readme file that AEST "Cannot generate a working program when the original VAX image ... was linked on a version of OpenVMS VAX earlier than V5.5"

Here's the relevant part of the VAX image header (I think):

Image Identification Information

image name: "ASADAY"
image file identification: " "
link date/time: 23-JUN-1993 15:12:06.12
linker identification: "05-13"

What VMS version's LINKER was "05-13"?

If that's not the problem, how can I work out what shareable image it is trying to activate?
(I tried SET WATCH FILE but I think that doesn't do anything until image activation is complete.)

2. One component of the application, not related to the file described above, uses an Alpha object library for which the sources have long been lost. We'll never need to change the object modules themselves but the calling program is modified quite regularly. Am I correct in assuming that our only options here are to
(a) remove the references to the object library routines from the calling program; or
(b) rewrite the object library routines; or
(c) make a shareable image out of the Alpha object library and then AEST the resulting image?

I think the application developers' preference is option (a) but (c) should be quicker if it can be done.

Thanks,

Jeremy Begg

[Robert Gezelter · Accepted solution]

Jeremy,

For the second question, the answer is a yes, at least as a starting point.

As I noted in my OpenVMS Technical Journal article "Strategies for Migrating from Alpha and VAX systems to HP Integrity Servers on OpenVMS" (available via http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.html ), it is quite feasible to call a translated shareable from native and/or translated components.

Of course, there is a cost to crossing between native and translated environments, but this cost is often reasonable.

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

[H.Becker]

>>>
$ run asaday_tv_av.exe
%DCL-W-ACTIMAGE, error activating image
-CLI-E-IMAGEFNF, image file not found $12$DKA0:[SYS0.SYSCOMMON.][SYSLIB].EXE;
<<<

The image activator is not always good at telling you what it found. But here the messages come from DCL/CLI. So the image activator doesn't even try to tell you something. I would start with SET WATCH, here. But it is also possible that the image activator encountered a problem and DCL is
just printing what it thinks is the image file name.

There is another rare case, where you can have an empty string in the shareable image list. Alpha tolerates this, I64 does not. I doubt that AEST is generating it or that it preserves it.

>>>
What VMS version's LINKER was "05-13"?
<<<

Looks like V5.5-2

>>>
If that's not the problem, how can I work out what shareable image it is trying
to activate?
(I tried SET WATCH FILE but I think that doesn't do anything until image
activation is complete.)
<<<

Set watch does exactly what you want it to do, all the files the image activator opens are listed - at the time they are opened. The ones which are installed with /open are already opened, hence not opened and not listed.

The supported tool to find all dependencies is analyze/image. There is another tool, SHIML, an early version is on the freeware CD, which prints a "recursive SHareable IMage dependency List". As analyze/image it is static. As analyze/image it is available for Alpha and I64.

>>>
I think the application developers' preference is option (a) but (c) should be
quicker if it can be done.
<<<

Yes, (c) should work and that's what others used in such a situation.

[John Gillings]

Jeremy,

Rather than chase this down a rabbit warren, why not have a look at what this program does and consider reimplementing it. If it really is 16 years old, and only 1K block when translated twice, how complex can it be?

I'm betting you could rewrite it from scratch faster than the time you'll spend trying to make it translate (if it's even possible). You'll probably end up with something much better, and maintainable.

[Hoff]

Or dig up dism32 from the archives and see how far the disassembled Macro32 code gets you with the linked (asaday or linked version of the routines in the object library) code. I had to do this a few times with ports, either reversing stuff or rewiring and rewriting it.

[Jeremy Begg]

I've just had another go with SET WATCH FILE and this time it did what I wanted, i.e. it showed me each file as the image activator loaded it. This confirmed the images being opened were the ones I expected -- and also that the final image was ".EXE" which is of course bogus.

Looking closer I found that one of the images being activated is SYS$SHARE:BASRTL_TV_SUPPORT_AV.EXE and it appears to be broken ...

$ anal/image/inter sys$share:basrtl_tv_support_av.exe
This is an OpenVMS IA64 (Elf format) shareable image file
.
.
.
Shareable Image List
TIE$SHARE
(LESS/EQUAL, 2., 1000.)


%ANALYZE-E-ELFSHR_XVCTL, Unable to find version control information (DT_VMS_NEEDED_IDENT)

Time to log a call with HP support I think.

As to John's suggestion of rewriting the program, yes that's a possibility but I believe the customer has another potential solution waiting in the wings so I'll follow that one up before rewriting this.

Regards,
Jeremy Begg

[H.Becker]

>>>
Looking closer I found that one of the images being activated is SYS$SHARE:BASRTL_TV_SUPPORT_AV.EXE and it appears to be broken ...
<<<

I would like to look at the image, but I don't have it on my system. It looks like a BASRTL image supplied by VMS, but it isn't. Where is it coming from? Does it come with BASIC or did you translate it with AEST? I would like to look at the Alpha image as well.

[Volker Halle]

Hartmut,

I find that BASRTL_TV_SUPPORT_AV.EXE image on our OpenVMS I64 V8.2 system disk (creation date 21-FEB-2005) and ANAL/IMA gives the same error.

Volker.

[Volker Halle]

Hartmut,

this image is part of TIE V1.0.

Volker.

[Jeremy Begg]

I can confirm Volker is correct, the iamges in question came from the TIE kit which I had installed some time ago. They're not present in the OpenVMS V8.3 (and later) kits.

I logged my call with HP and got a response along the lines of "OpenVMS Engineering does not support translation of BASIC programs". Nevertheless the local HP support had heard of a fix for the BASRTL_TV_SUPPORT_AV issue and tracked it down.

The replacement BASRTL_TV_SUPPORT_AV image appears to work, i.e. the image activator does its job without complaining. Unfortunately my translated image does not work :-(

After doing some initial file I/O it hangs in a tight CPU loop. At this point I think I'll have to call it quits on this program because tracking down the problem will take more time than it's worth.

Regards,
Jeremy Begg