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 theAPCHECK 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
Re: [U2] [UD] Corrupted compiled code
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 theAPCHECK 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
Re: [U2] [UD] Corrupted compiled code
Darn! I was hoping you'd remember something, like recompiling while someone is using the program in UO would corrupt the object is 18 days. Or, the GETPTR function returns 1024 via UO if the object is corrupted. I do not want to think our environment is unique. :-( Thanks again and have a nice holiday season. Bill - Original Message - *From:* wterh...@rocketsoftware.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 12/21/2011 5:55 AM *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 theAPCHECK 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
Re: [U2] [UD] Corrupted compiled code
Though I have to agree with Bob Wyatt: memory seems to get cheaper and less reliable as it ages :-( 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: Wednesday, December 21, 2011 10:23 AM To: U2 Users List Subject: Re: [U2] [UD] Corrupted compiled code Darn! I was hoping you'd remember something, like recompiling while someone is using the program in UO would corrupt the object is 18 days. Or, the GETPTR function returns 1024 via UO if the object is corrupted. I do not want to think our environment is unique. :-( Thanks again and have a nice holiday season. Bill - Original Message - *From:* wterh...@rocketsoftware.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 12/21/2011 5:55 AM *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). ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UD] Corrupted compiled code
On 21/12/11 17:38, Wally Terhune wrote: Though I have to agree with Bob Wyatt: memory seems to get cheaper and less reliable as it ages :-( I was thinking memory ... possibly bad? Does Unidata store its programs in shared memory? Could the memory have got corrupted and it takes a recompile to move it and reset it? Long shot I know, but stranger things have happened (and as memory gets faster and the lines get narrower, random corruption gets more likely). Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UD] Corrupted compiled code
I was actually thinking of my personal memory about UniData problems reported these past 21 years. Bill said his programs were CATALOG ... DIRECT - so unless he places his source files under UDTHOME\sys\CTLG - his object code is not managed by sbcs or stored in shared memory. Each udt process will have to malloc private memory to load all of the objects it runs. Each time he starts a new udt process and runs the problem program, that object code is read from disk and loaded into private process memory. There isn't any cache or such for this application setup. 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 Wols Lists Sent: Wednesday, December 21, 2011 1:54 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] Corrupted compiled code On 21/12/11 17:38, Wally Terhune wrote: Though I have to agree with Bob Wyatt: memory seems to get cheaper and less reliable as it ages :-( I was thinking memory ... possibly bad? Does Unidata store its programs in shared memory? Could the memory have got corrupted and it takes a recompile to move it and reset it? Long shot I know, but stranger things have happened (and as memory gets faster and the lines get narrower, random corruption gets more likely). Cheers, Wol ___ 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
Re: [U2] [UD] Corrupted compiled code
On 21/12/11 20:59, Wally Terhune wrote: I was actually thinking of my personal memory about UniData problems reported these past 21 years. I got that. It just seemed a nice intro to what I thought was a possibility. But seeing as I was thinking of INFORMATION, I knew it was a long shot. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UD] Corrupted compiled code
Ouch. I've never seen that. Did you check the time/date stamp on the compiled code? 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 Colin 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 theAPCHECK 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
Re: [U2] [UD] Corrupted compiled code
I've seen a similar thing happen on UV with catalog pointers that just stop working, but never on UD. I wonder if there's some virus control software on the server that might be fixing the object somehow? -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UD] Corrupted compiled code
I just put AV on the server and limited it to a few particular directories (upload directories). I had this problem before I installed SEP AV. I'm running Windows 2008 R2 in development but I've had the same problem with UD on a Windows 2003 Standard Dell 2U server. Looking at the date/time stamps they're all somewhat recent in development, as I'm having to recompile at off hours. At first, I just thought oh well. But this has been going on for, it seems like, several years. I have UD 7.1.9 on our production server and 7.2.7 in our development environment. It seems, 5 years ago when I upgraded from D3 to UD this happened a couple of times, but I could always attribute it to something I did. Now I'm not sure. The last few times I ran into this problem I tracked the problem to a core subroutine, recompiled it, and all worked fine from then on. I then recompiled all the code and continued my merry way. Previously I was thinking it might be I recompiled while someone was using the program and it just failed. However, today's check problem only affected me, as our application logs shows others writing checks with no problems. However, the bank listing report was misbehaving for everybody, but only from a single account. Recompiled and voi`la all works fine now. :-( Bill - Original Message - *From:* precisonl...@gmail.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 12/20/2011 9:35 PM *Subject:* Re: [U2] [UD] Corrupted compiled code I've seen a similar thing happen on UV with catalog pointers that just stop working, but never on UD. I wonder if there's some virus control software on the server that might be fixing the object somehow? -Kevin http://www.PrecisOnline.com - Original Message - *From:* alfke...@hotmail.com *To:* u2-users@listserver.u2ug.org *Date:* 12/20/2011 9:31 PM *Subject:* Re: [U2] [UD] Corrupted compiled code Ouch. I've never seen that. Did you check the time/date stamp on the compiled code? 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 Colin 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 theAPCHECK 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
