The incredibly weird thing was the code would do:

TclLine  = {whatever}
TclLine := etc, etc, etc
ReportHeader  = "CLIENT BANK ACCOUNT TOTALS": @AM
ReportHeader := "FOR MONTH November 2011": @AM
ReportHeader := ""
CALL BUILD.HEADING ( ReportHeader, AddLineInHdr, PrintSw )
TclLine := \HEADING "\ : ReportHeader : \" FOOTING "\ : ReportFooter : \"\
EXECUTE TclLine

...the TclLine variable should look like:

sort BANKBOOK WHEN CLIENTNO.RSTR = "0" BY-EXP CLIENTNO BY ATYPE_ACCTNO BY ATYPE_DESC ID-SUPP BREAK.SUP " 'DO'" CLIENTNO CLIENT
     NO BNAMES ATYPE_DESCS ATYPE_ACCTNOS TOTAL CURRBAL HEADING
"Run by-: WPHASKETT CLIENT BANK ACCOUNT TOTALS Page: 'PL' Menu No: BANK 4.3.5 FOR MONTH November 2011 Date: 20 Dec 2011'L' Account: CustomerAcct Time: 12:40PM'L'" FOOTING "'L'(C) Copyright 'D', Advantos Systems, Inc. All Rights Reserved." NI-SUPP

...which they all did except, occasionally, on this one account. The calculation of the amount of spaces to center the report heading data used SYSTEM(2) and GETPTR in the subroutine "BUILD.HEADING". For some reason the corrupted value was 1024 instead of actual value of 80. Thus, when I displayed the "TclLine" variable, it looked like the one above, except when everything failed, whereupon the variable looked like:

sort BANKBOOK WHEN CLIENTNO.RSTR = "0" BY-EXP CLIENTNO BY ATYPE_ACCTNO BY ATYPE_DESC ID-SUPP BREAK.SUP " 'DO'" CLIENTNO CLIENT NO BNAMES ATYPE_DESCS ATYPE_ACCTNOS TOTAL CURRBAL HEADING "Run by-: WPHASKETT



                                            CLIENT BANK ACCOUNT TOTALS



                                     Page: 'PL'Menu No: BANK 4.3.5



                            FOR MONTH November 2011



                    Date: 20 Dec 2011'L'Account: CustomerAcct







Time: 12:40PM'L'" FOOTING "'L'(C) Copyright 'D', Advantos Systems, Inc. All Rights Reserved." NI-SUPP

...which wrecks havoc when executed and nowhere was the error logged; so it took me forever to find this.

Now, I've been known to follow the wrong path when programming, but you'd think, after 20 years, I could figure out how to build and execute a tcl command in BASIC, and what I build is what is executed. A recompile of BUILD.HEADING fixed this problem, so I'm not sure what happened. My only thought is the object got corrupted during a session.

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* jhather...@hipco.com
*To:* U2 Users List <u2-users@listserver.u2ug.org>
*Date:* 12/21/2011 12:27 PM
*Subject:* Re: [U2] Corrupted compiled code
It sounds crazy but humor me. I have seen when commands are imbedded in a variable name 
in some systems it has problems. That's why I go out of my way not to put them in my 
variable names.  In this case "CRT".  Rename the variable and see what happens? 
 It's a long shot but stranger things have happened.

John W Hatherill
-----Original Message-----
From: Bill Haskett [mailto:wphask...@advantos.net]
Sent: Tuesday, December 20, 2011 7:40 PM
To: U2 Mail List
Subject: [U2] [UD] Corrupted compiled code

I've been using UD for a number of years.  I'm currently using v7.2.7.
Occasionally, the compiled code gets corrupted.  I notice when a client
calls and indicates something doesn't work.  Today I couldn't create an
A/P check.  After a few hours I tracked down the following message:

In E:\Abo\BP\BP\_APCHECK at line 60 can not use debugger for background job
In E:\Abo\BP\BP\_M.APCHECK at line 343 Phantom run basic error, exit 4.

Line 60 of "APCHECK" looks like:

IF GUIMODE THEN SuppressCRT = 1 ELSE SuppressCRT = 0

I figured I'd left a "DEBUG" statement in "APCHECK" when I called
"M.APCHECK" (which executes "APCHECK" from a phantom).  I didn't!
Everything looked good.  I finally added a simple VOC
debug-record-writev to the"APCHECK" program , recompiled it and reran
the process.  All worked fine!  I took out the debug code and everything
works fine.  So, recompiling was all it took because the object code was
corrupted somehow.

Yesterday, I spent 12 hours tracking down an intermittent browser crash
for one of our clients and finally came to a BUILD.HEADING program I've
been using since 1995.  What happened was that SYSTEM(2) was returning
the value 1024 instead of 80.  So, when I created a three line heading
and centered stuff on each line, instead of 30 (or so) spaces created on
each side of the heading line I had about 450.  When the heading info
was added to the ECL command the line was too long and barfed when it
was executed.  No error message appeared anywhere so it was with a lot
of effort I was able to track this down.  Upon adding a
writev-debug-line and recompiling, everything started working just
fine.  I removed the debug line and all is working well.

Naturally I've recompiled everything and rebooted the server, but this
is a major pain in the a$$!  Does anyone know why code that's been used
for months, and maybe years, would get corrupted like this?  Everything
is compiled with the '-Z2' option and all cataloging is local (DIRECT
FORCE).

Thanks,

Bill

_______________________________________________
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