VEST usage resulting in ASTFLT and SHRIDMISMAT

[Paul Goslin Rae McCarth]

Hello,
We are working on moving an old VAX system to Alpha. Attached is a text file with details and questions - maximize it for best viewing. Any help would be most welcome. Many thanks in advance.

[Hoff]

In this case (and after getting to current on the tools and ECOs), get HP support involved earlier rather than later.

This could be something in DECmigrate/VEST, or this could easily be a latent bug in the code, but the innards of the translation are way beyond what can be debugged here.

(And classic VAX C code is often pretty shaky stuff, in my experience. The compiler was, um, unusually tolerant, and applications can operate as much by sheer luck as any other explanation.)

Some details on the VAXCRTL and LIBRTL messages with VEST /DEPENDENCY are included in the release notes for DECmigrate/VEST, including some specific cautions around how you must configure DECmigrate/VEST to translate images built with VAXCRTL and the VAX C run-time environment.

The _TV stuff are the Translated VEST modules for the associated shareable images. Normal.

Here's a reference manual and some related, if you haven't already found such:

http://www.softresint.com/pub/doc/OMSVA_UserManual.pdf
http://starlet.deltatel.ru/sys$common/syshlp/vest011a.release_notes

If it's a small or isolated application, I might still look to rewrite it. Maintenance of these translated applications is problematic; you're looking at compiled compiled code, and sometimes at interpreted compiled code. Ugly, in other words.

Oh, and before proceeding any further here, it looks like you might have DECmigrate/VEST V1.1A here. If so, do take the time to download and install DECmigrate/VEST/OMSVA V1.2 via:

http://h71000.www7.hp.com/openvms/products/omsva/omsva.html

Stephen Hoffman
HoffmanLabs LLC

[John Gillings]

Paul,

ASTFLT usually means you've run out of stack space. The SP reported in your ASTFLT message doesn't look high enough for that to be the case, but it's odd the target PC is the same address.

I'm not sure I understand your point about renaming the file. Does it run correctly if you don't rename it? If that's the case your menu issue is easily resolved by defining a logical name:

$ DEFINE SECPATCH SECPATCH_TV

> I looked in SYS$COMMON:[SYSLIB], and the
>vaxcrtl.exe and librtl.exe files are,
>indeed, not present. Maybe we have an
>incomplete Alpha install somehow?

This makes no sense at all. A system missing LIBRTL would simply not work. Unbootable and if you somehow got it running, virtually all DCL commands would fail as they're all dependent on LIBRTL. VAXCRTL is another story, but you should at least have the vested versions. Check:

$ DIR SYS$SHARE:*VAXCRTL*,*LIBRTL*

You should see numerous files, some of which have the _TV suffix indicating a vested image.

I can't remember if there's a VEST setup procedure to define logical names. If there is, have you run it?

When it comes down to it, realistically VEST should be a last ditch option, only to be used when all other options exhausted. Debugging is all but impossible, and if you don't have source, what can you do about it anyway? If the program doesn't run correctly on the VAX, there's no way you'll get it running VESTed on Alpha.

About the best I can suggest is you write a simple test program that uses the same shareable images - something like "hello world" should suffice. Try vesting that and make sure it can be copied and run in your target environment. That should help find and eliminate systemic issues.

If you can't find anything simple to fix, you may need to just bite the bullet and reimplement these programs (and also implement a relible BACKUP mechanism so you don't lose sources in the future!). It's a matter of balancing out how much time you might spend battling VEST which might be better invested in reimplementation. Long term this is a MUCH better option than VEST.

[Paul Goslin Rae McCarth]

Hi Stephen,
Many thanks for the input. We are contacting Support. And thank you for the links to the manuals - I actually have a June 2002 version of the OMSVA_UserManual, but I did not have the release notes. If you would like the June version, here is the link:

http://h71000.www7.hp.com/doc/82final/omsva_012_translating_images.pdf

I agree with your comments regarding classic VAX C code and the compiler. And this code is very old, so even assuming it had a solid design from the beginning, it has been changed so many times, that I'm sure it has strayed from the original. Please see the next-to-last paragraph down below regarding rewriting the code.

Thank you for the link to download VEST V1.2. Our system administrator has already downloaded the newer version and installed it. I'll look into your comment on configuring VEST to translate images built with VAXCRTL and VAX C to see if there is something there to be done. And I'll try re-translating to see if that helps.


And Hello John,
Thank you also for your input and questions.

Regarding renaming the program - I only renamed it because I didn't want to have to change an existing logical name. When the renamed module did not work at first, I wanted to rule out the possibility that the _TV name was required, so I did a test with _TV appended to the name. I would not have thought it was required, but I did want to make sure that it had no bearing.

Regarding the presence/absence of vaxcrtl and librtl: I did find vested versions of vaxcrtl, and I did find librtl.exe (sorry about the misinformation on that one). Thanks for pointing that out.

I will look into a vest setup if there is one. I have not personally run it.

And lastly, I do realize that VEST is a last ditch option. But I do have one translated program from the same period, performing a similar function, and it is working correctly. That is why I'm still hopeful that we can get both of the programs that I discussed in the original attachment to this thread working. The original progam was modified some years ago - this newest program has been recompiled for Alpha, and a different error is occurring for some of the options; other optons are working perfectly. My developer tells me that it might be worth the effort to see if we can get translated versions of the older programs working to address those options that are failing with the newest version. Convoluted, indeed. The original code is just so old (and has been worked on by multiple people over the years), that I'm not surprised we're having difficulties. What we're dealing with is source that diverged and earlier versions were lost (although earlier executables were still kept) - sloppy, I agree, but that's what we're stuck with, and it's beyond my control today. My job (part of it) is maintaining the menu system that launches these programs.


So again - many thanks to both of you. It's an "interesting" situation we have here, so we will push ahead with your suggestions and work with Support to see if we can find a resolution. There is a reason you both have crowns. Thank you very much. BTW, my name is Jan - I work with Paul and Rae. I will keep this thread open until next week to see if anyone else wants to make any comments or suggestions. I am out of the office on Friday, so if anything is added to this thread on Friday or over the weekend, I will see it on Monday.

[Hoff]

"Recompiled?" You have source code?

That's gold.

That's the "forget DECmigrate" flag.

Check how the (flaky) code was recompiled; determine if the programmer(s) involved selected VAX C and/or switched off and/or ignored the diagnostics and errors. (I've found the sometimes tedious task of fixing what the newer C compiler reports -- well worth the effort, but often skipped -- is far more valuable than DECmigrate. The newer compiler is one of the best around at detecting and reporting real errors, and questionable code constructs.)

As for your goal, I'm not at all certain that DECmigrate will get you where you want; you've a newer environment that doesn't work, and an older exe-only environment that works (better?), and you're seeking to get DECmigrate as a diagnostic due to a lack of older code. If you do get DECmigrate and the translation working here, that's really a stop-gap. At best. (What do you do next when you do get there here; when you do get the DECmigrate translation working?)

If this is a critical application, and I had the choice of debugging source code or of debugging DECmigrate, the source code always wins. I can read and debug and instrument and modify source code.

Here, I'd be concentrating on the source code and on the error(s), and on moving the old code to current ANSI C. If it comes down to it, at cleaning up and reworking and documenting the existing source code to make it more maintainable. Not on DECmigrate.

With DECmigrate, you're digging a deeper hole in what is already a very bad spot. The deeper you dig, the more effort it is to get out, and the bigger the risk of collapse.

[DECxchange]

Hello,
Are you using VEST on just the program which you no longer have the source code for? It seems like it is complaining because these programs were compiled on an earlier version of VMS and there may be some incompatibilities with the newer C runtime libraries on VMS 6.2. Do you still have an older VAX with an earlier version of VMS that these programs used to run on?

I'm not a VEST expert and it's been years since I used it. But I think VEST came about before VMS 6.2. I think 6.2 is not the greatest of VAX-VMS versions. Maybe you might want to find a different newer version of VAX-VMS, like 7.3, and do your migration effort on an offline system running this different VMS version.

On the other hand, you might want to run your programs on VMS 5.5-2H4 and do your VESTing from there?

[Paul Goslin Rae McCarth]

Hi Hoff,

Sorry I missed your post last Thursday. And, sorry again, but "recompiled" in my previous response is referring to a newer version of the program that doesn't do what I need it to do.

I agree with you - if I had the original source, I wouldn't be bothering with DECMigrate. What I have is source code for a newer program that functions but doesn't do what I need, and I have an old executable (but no source) that will do what I need if we can get it translated.

As far as the criticality of the application - I would love to get it working via the menu, but worst case is my users will have to contact me or another person to RUN the new program for them. And I suppose there is a possibility that I can just discontinue support of the menu options that don't work, but I would prefer to try to keep it (access to all the menu items) intact. But I want to exhaust the migration path before I start discontinuing anything.

So, thanks again for your response and and suggestions - I agree that your suggestions would be the way to go if I/we did have the source code to the older application.


And Hello to DECxchange - thank you also for your comments. We do not have an older VAX with the earlier version of VMS that was used for the original program, so I cannot try that. Also, unfortunately, our current VAX system is on some very old hardware, so we will not be upgrading that system to a newer version of VMS-VAX. All of our other machines are either Alpha or Itanium. I am currently using VEST under OpenVMS 8.2 on an Alpha box, not under the VMS 6.2 environment on the VAX machine. But I will check with our system administrator to set up access to a 7.3 system and try to translate the program in that environment. I would have thought using VEST under 8.2 would be better than under 7.3, but I'm game to give it a try. I will let you know how it turns out.

Thanks to everyone,
Jan

[Hoff]

[[[Sorry I missed your post last Thursday. And, sorry again, but "recompiled" in my previous response is referring to a newer version of the program that doesn't do what I need it to do.

I agree with you - if I had the original source, I wouldn't be bothering with DECMigrate. What I have is source code for a newer program that functions but doesn't do what I need, and I have an old executable (but no source) that will do what I need if we can get it translated.]]]

Yes, that was clear. I'd expect that even different and derivative and even buggy source code is more valuable to your end-goal than is DECmigrate translated code. With source code, you have a shot of fixing this case, and future errors. With DECmigrate, you're stuck -- even if you get the translation working.

I'd start with buggy source code long before I brought DECmigrate onto the playing field.

Accordingly, I'd infer that this current effort is part of a throw-away stop-gap, and part of buying time for a migration else-platform.

DECmigrate is a case of painting yourself deep into a corner; if you're already painted into the corner because of a lack of source code, that's one thing, but...

[Paul Goslin Rae McCarth]

Hi Hoff,
Thanks for your continued support. I agree with everything you've said. At this point, though, we're going to go ahead and close this thread. I think we've pretty much exhausted what we can do via discussions. We will continue working with Support to resolve the translation problem as well as working on the lack of source code. My thanks to you and everyone who has contributed to this thread.

Sincere thanks,
Jan

[Paul Goslin Rae McCarth]

Closing, with thanks!

[Willem Grooters]

It might be a consideration to use a hardware emulator like CharonVax (bundeled with hardware as Futurevax) that allows you to use modern storage and network and keep your VAX software infrastructure intact - completely.