Seeking basic015.release_notes and basic014.release_notes

[Art Wiens]

I'm trying to find out if an obscure problem (%OTS-F-FATINTERR, fatal internal error in Run-Time Library) we're seeing in our Basic 1.3 environment was addressed in one of these two releases. I have the 016 release notes. No mention in there.

The problem seems to be the result of the Basic program closing a file/channel with a LIB$FREE_LUN(channel_l) .

Thanks in advance,
Art

[John Gillings]

Art,

LIB$FREE_LUN doesn't close a file or channel. All it does is free a LUN allocated with LIB$GET_LUN. You need to close the file in BASIC before freeing the LUN.

From dim and distant memories, this pair of routines is very, very simple. GET_LUN is basically just a FFS instruction to find a free LUN in a static bitmask, followed by BICL to mark it allocated. FREE_LUN is a BISL to mark it free again. (I may have the sense of the free/allocated bits around the wrong way).
There are a handful of other instructions for sanity checks. There's not a lot that can go wrong!

I can't see how a problem in LIBRTL could be fixed by a Basic compiler update. Remember that all RTLs belong to OpenVMS, NOT the compiler, so compiler kits don't change RTLs.

If you think it's the LIB$*_LUN routines causing trouble, try reimplementing them yourself so you can debug them. All you need to do is allocate and deallocate numbers in the range 100-119 or 100-299 if it's Alpha or I64.

That said, my usual advice with compilers is to always use the latest version. Compilers only ever get better, and the first step in diagnosing any compiler issue is to try the latest version. It's also trivially easy to retain old versions of compilers and switch between them any time you like (Pascal does this for you automatically, I'm not sure about Basic).

Since compilers are really just user mode text processors, any user can break open a compiler kit, copy the compiler image to their local directory, define a logical name, and use a different compiler version without having to install it.

If none of that helps, please post the stack dump for the FATINTERR.

[Hoff]

Have a read of...

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=936094

as that thread looks similar...

[Duncan Morris]

Art,

running the reproducer from John Gillings response in the previous posting, I can see that the fix seems to have appeared in a newer version of DEC$BASRTL.EXE.

Under VMS V7.3-2 this version of BASRTL generates the OTS-F-FATINTERR messages:

image name: "DEC$BASRTL"
image file identification: "V01-026"
image file build identification: "X9ZK-0060100000"
link date/time: 1-OCT-2003 21:18:27.41
linker identification: "A11-50"



Under VMS V7.3-2 with a BASIC V1.7 compiler the BASRTL is reported as

image name: "DEC$BASRTL"
image file identification: "V01-034"
image file build identification: "XBPL-BL1-000000"
link date/time: 30-AUG-2007 11:19:08.54
linker identification: "A13-03"

and the reproducer runs without errors.

I do not have the 015 or 016 kits available to check out their version of DEC$BASRTL.


Duncan