I'm not recalling customers reporting problems like this (except for one case I 
have with you, Bill regarding a program creating a print job that goes into a 
loop once every few years). 

Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
Tel: +1.720.475.8055
Email: wterh...@rs.com
Web: www.rocketsoftware.com/u2

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, December 20, 2011 8: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).


U2-Users mailing list
U2-Users mailing list

Reply via email to