As always, thanks G-Man!

I can't replicate it. It just comes up every six months (or so) with something totally different happening within our application, not to everybody, but to someone. The testing is always the same; test to confirm, put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile, test to confirm fix, then move on. In the meantime, hundreds of thousands of transactions have taken place with no problems.

All I can say is; it could be worse!  :-)


----- Original Message -----
*Date:* 7/25/2013 1:04 PM
*Subject:* Re: [U2] [UD] BASIC Code Failing
Bill, at Pick Systems we occasionally saw issues like this, where the
object code would behave differently if specific statements (their
opcodes/tokens) were broken across frame boundaries. Until DBMS
patches become available, the problem could be avoided with some
carefully-placed NULL statements. I've seen this with RPL too, for
exactly the same reasons. I know nothing of U2 internals but the
internals are of course similar. Unfortunately without a confirmed
cause/effect scenario defined by engineers, it's a crap shoot as to
whether inserting NULLs will help, or where they can be inserted to
ensure they work.

I suggest you contact Rocket and ask them to pursue this as a
byte-level issue in your object code. Sending them the code might not
help if they test in an environment that's different from your own.
They need to see it on your system. I'm just trying to save you some
wasted diagnostic time...


From: Bill Haskett
... a single BASIC program didn't run a couple of lines of code...
U2-Users mailing list

U2-Users mailing list

Reply via email to