MMS building FMS forms crashing on X86

[issinoho]

OpenVMS V9.2-1, QEMU Standard PC (Q35 + ICH9, 2009)
VSI X86VMS MMS V4.0-4
VSI X86VMS C X7.4-785
VSI FMS Version 2.6-4 for OpenVMS x86_64 Systems

Hi, I know the information below isn't a huge amount to go on but I'm hoping that I can get some pointers on tracking down this issue, whilst preserving IPR from a public forum.
We have a complex set of MMS scripts building libraries, shared images, executables and FMS forms. The code builds & works correctly on IA64.
My issue is when the process gets to the point of updating a forms library with a form whereupon it crashes out with an undefined function symbol error.
I can't see a way of getting more information about what is going on - perhaps you could advise.
Anyway here is the log sequence (anonymized).

Code: Select all

%MMS-I-GMTIMFND, Time for MY_USER_MENU.FLG is 23-JUL-1993 13:12:03.30
%MMS-I-GMTIMFND, Time for MY_USER_MENU.FRM is 17-NOV-1858 00:00:00.00
%MMS-I-GWKOLDNOD, Target MY_USER_MENU.FRM is older than MY_USER_MENU.FLG
%MMS-I-GWKWILLEX, MMS will try executing action line to update target MY_USER_MENU.FRM
FMS/TRANSLATE MY_USER_MENU.FLG
%MMS-I-GWKEXESTS, Status of executed command is %X18F29A91.
%MMS-I-GWKUPDONE, Completed update for target MY_USER_MENU.FRM
%MMS-I-GWKOLDNOD, Target MY$LIBS:USER_FMS_LIB.FLB(MY_USER_MENU=MY_USER_MENU.FRM) is older than MY_USER_MENU.FRM
%MMS-I-GWKWILLEX, MMS will try executing action line to update target MY$LIBS:USER_FMS_LIB.FLB(MY_USER_MENU=MY_USER_MENU.FRM)
%SYSTEM-F-CALLUNDEFSYM, Call using undefined function symbol
<CR><LF> Improperly handled condition, image exit forced by last chance handle`
Signal arguments: Number = 0000000000000003
Name = 0000000000003434
000000008005D808
000000000000001B
Register dump:
RAX = 0000000000000500 RDI = 0000000000100001 RSI = 0000000000003434
RDX = 000000007ACDD740 RCX = 0000000000000000 R8 = 0000000000014008
R9 = 0000000000000019 RBX = 000000007FFCF898 RBP = 000000007ACDDB90
R10 = 000000000000000D R11 = 000000000000000C R12 = 000000007ACE5A38
R13 = 0000000000000000 R14 = 000000007AEBA170 R15 = 00000000000DB010
RIP = 000000008005D808 RSP = 000000007ACDDAD8 SS = 000000000000001B

Any help would be appreciated. TIA.

[jreagan]

> %SYSTEM-F-CALLUNDEFSYM, Call using undefined function symbol

Some program (might be MMS, might be something MMS executed, etc. can't tell without /VERBOSE or whatever) tried to call a routine that was missing at link time. On both Itanium and x86, if the linker cannot find a routine, get the "undefined symbol" message at link-time but in reality, the linker created a small stub routine that raises the SS$_CALLUNDEFSYM error and used that instead.

It still doesn't help you right now until we know exactly what image was running. Check all your MAPs for undefined symbols.

[dgordon]

This is a hint:

MMS-I-GWKWILLEX, MMS will try executing action line to update target MY$LIBS:USER_FMS_LIB.FLB(MY_USER_MENU=MY_USER_MENU.FRM)

I suspect the MMS rule to update an FMS forms library is FMS itself. Try to do it by hand and see what happens. It may not be FMS directly, but rather something it calls, but it's a start.

[hb]

To expand on what John said, usually at link time you get (an informational I-UDFSYM for the undefined routine and) a warning: W-USEUNDEF, but the linker generates an image. (This is the way the VMS linker works.) On IA64 and x86,, the linker generates code for the undefined routine. That code raises the SS$_CALLUNDEFSYM exception. The image works as expected, as long as the undefined routine is not called at run time. If the undefined routine is called, the SS$_CALLUNDEFSYM exception is raised. If the image is linked with /TRACE you'll get the traceback information. Unfortunately that does not yet work on V9.2-1, you will always get the register dump from the last chance handler. This is fixed and will be available in an update for V9.2-1.

If this is your image which raises the SS$_CALLUNDEFSYM exception, chances are high you have the W-USEUNDEF in a linker map. But there are "exceptions", it is possible to suppress this linker warning. In this case you will still get the SS$_CALLUNDEFSYM exception but you will not find the W-USEUNDEF in the linker map.

If this is not your image, for example MMS, then you can only contact the vendor.