CUSTFUNCS'BSI:27337: ?Unmapped variable: - IF (scan'entry <> cust1.contact'phone(1)) AND (scan'entry <> cust1.contact'phone(2))
AND (scan'entry <> cust1.fax'phone) THEN << custfuncs'bsi:190_cust1.contact'phone( >>
... there doesn't seem to be any such field contact'phone() mapped in the cust1 structure. So it's not clear whether this is another case of the LSX being corrupted or an actual problem in the original source.
Sorry, it looks like some code got changed in a repository that is shared between our customer bases and didn't conditionally compile it. Sorry for wasting your time on this one.
No worries there, it's always a nice change when the problem isn't on my end! As it turns out, there was another problem in the compiler that I think is resolved in version 6.5.1716.3 (compiler edit 990) ...
This was related to the errors you saw in invdesc; although backing off the optimization seemed to resolve it, I think this update addresses the real issue (and the optimization has been re-enabled.)
Not that I want to drag this thread out any longer, but perhaps the best way to answer your question is to keep posting messages! Even better, messages with updates ...
FYI, the immediate problem is caused by the syntactic quirk that $$i.SUBLIST is actually a kind of array even though it doesn't have any trailing (). So it was fooling the new scalar vs array test that compares passed arguments to those declared in the function. That's relatively easy to fix, but in the process I've uncovered a few other issues with .SUBLIST that are more involved. Current projection is for an update by tomorrow, but it might take a little longer...
Ugh. It's clearly due to the new trap for stack underflow, but unfortunately not clear what the cause is. I may have to just remove that trap (the underflow loophole has been there for a long time, but was apparently relatively harmless) and replace it with a trace message to allow tracking it down without so much disruption.
This one is turning out to be harder to reproduce. It has actually been subject to a fair amount of field testing, so I'm reasonably confident that the circumstances triggering the underflow aren't very common. As a temporary measure to make it easier for you to test, while not covering up the existence of an error condition, I've posted a 1717.8 version that replaces the error #33 with a log message ("warning: stack underflow detected"). Perhaps we can get some additional information about the frequency / context that way.
This turned out to be a bug in the execution of the code generated by the ++PRAGMA TRACK_LAST_ROUTINE. (While while innocuous in the source code, one such statement affects the compilation and runtime of every single function after it, which explains why you were getting inundated by them.) Also the pragma is (apparently) somewhat rarely used. Anyway, the execution bug involved an otherwise harmless dummy expression evaluation that resulted in the popping off a value that had never been pushed. It was harmless enough, since the stack gets reset at the start of each statement. But forcing the error to be reported (now traced rather than aborting the program) did force it to be discovered and fixed. So in general that's a good thing.
