I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris. I recall seeing and reporting this issue back in UniData 5.something on AIX. Both times, support calls were opened. Both times, as we had done much of what you have already done, the call was closed as No Fault Found because we were unable to reproduce the fault.
There are also prior reports of this or a similar issue in the archives here (to the best of my recollection). None of these occurred after an upgrade or update to the system or UniData; administratively, the machines had been stagnant for a while. Best of luck! Regards, Bob Wyatt -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Thursday, July 25, 2013 6:11 PM To: U2 Users List Subject: Re: [U2] [UD] BASIC Code Failing 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! :-) Bill ------------------------------------------------------------------------ ----- Original Message ----- *From:* 3xk547...@sneakemail.com *To:* u2-users@listserver.u2ug.org *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... > > Best, > T > >> From: Bill Haskett >> ... a single BASIC program didn't run a couple of lines of code... > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
