I've seen the problem going back 10+ years on UniData 5.X. The issue was
reported to UniData, we worked with support for a while, but we never
achieved the point of being able to identify the cause. This was on Solaris.
A couple of years later, another client saw it in 6.X on AIX, but it was not
reported to UniData - it happened with one program and was not reproducible
once the steps Bill describes had been taken . Neither client elected to
compile and re-catalog their software collection proactively.

*DISCLAIMOR - the actual UniData version afflicted may be different from
those indicated above - memory seems to get cheaper and less reliable as it
ages

Bob Wyatt

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wally Terhune
Sent: Wednesday, December 21, 2011 8:55 AM
To: U2 Users List
Subject: Re: [U2] [UD] Corrupted compiled code

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).

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

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

Reply via email to