Ouch. I've never seen that. Did you check the time/date stamp on the compiled 
The only vaugely similar thing was data files getting corrupted. But that was 
only on writes and the problem was with some driver issues with the drive 
controller and network card.
You may want to check with Rocket to see if there are any known issues - or 
create one....

> Date: Tue, 20 Dec 2011 19:40:19 -0800
> From: wphaskett
> To: U2-users@listserver.u2ug.org
> 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 
> Thanks,
> Bill
U2-Users mailing list

Reply via email to