Robert:

"...the object code became corrupt due to a system crash." That sounds plausible. Our systems rarely go down, but they do get rebooted with Windows Updates. UO connections often fail, then get picked up. Telnet often freezes or aborts (mostly client issues) then they log in again. Then there's ...

It's always something...and these moron kids think everything works just fine (because they haven't lived long enough to see it not work). :-)

Bill
Untitled Page


------------------------------------------------------------------------
----- Original Message -----
*From:* i...@keyway.net
*To:* U2 Users List <u2-users@listserver.u2ug.org>
*Date:* 7/25/2013 1:57 PM
*Subject:* Re: [U2] [UD] BASIC Code Failing
I just remembered another situation I saw once where a program behaved strangely. When we used the command to verify the object code (BVERIFY?) it didn't verify. A recompile fixed it because the object code became corrupt due to a system crash.

Sometimes you can have the same thing happen, but in the catalog space.

Robert Norman
ROBERT NORMAN AND ASSOCIATES
23441 Golden Springs Dr., #289, Diamond Bar, CA 91765
(951) 541-1668
i...@keyway.net <mailto:i...@keyway.net>
http://users.keyway.net/~ice/ <http://users.keyway.net/%7Eice/>
Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, UniVerse
Basic, UniBasic, R/BASIC, jBC.

On 7/25/2013 1:36 PM, Woodward, Bob wrote:
I agree with Tony.  I once had a program that my fix was just adding a
"JUNK = 0" line near the top of the program.  With that do-nothing line
the program worked.  Comment the line out or remove it completely and
the program seemed to skip lines of code.

This was a LONG time ago, though.

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Thursday, July 25, 2013 1:05 PM
To: u2-users@listserver.u2ug.org
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

_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to