We have just encountered a problem that we've never experienced before. We make a change to a program, compile it, the change works. Same programmer makes another change, and compiles, and though the.gnt file appears to have been updated, the program change is not effective. That programmer can compile it 20 times, and it will not make a difference. A different programmer can compile it, and then the new code does show up. But then for further changes, another programmer must do the compile.
What gives?? Anyone had this happen?
We've tried 3 programs so far...delivered or custom - makes no difference. An example would be PA52.
I am not familiar with that command. Normally all we need to do is compile - sometimes an xscrgen or scrgen. We have never needed to do a tmcontrol to effect code changes. ??
FYI, we are LSF9, 8.0.3 apps, Windows.
The program would not be in use. We are doing this in our Development environment.
The original code change was for a new error message, which would simply not display - either in Portal OR in LID.
But now that we have discovered the problem, we are simply inserting a display message, and changing that with each compile, in trace mode, to see if it takes. We are looking in the the trace log file to view the code change...and it will only change with the first compile, until a different programmer runs the compile. We've done thos several times now, and the code changes are not showing up in the subsequent compiles for the same programmer.
We have tried deleting the .gnt file before recompiling, but got the same results - which makes NO sense at all. We also tried the same scenario in our TEST environment, with the exact same results.
Both programmers (it happens with both that have tried) have been in the same domain/class for years, as far as I know.
Good idea on the security tho - I'll try that.
No luck with the lawsec on/off thing. Any other ideas?
Mid-December was the last compiled change in our DEV system. I thought about the licensing...and I don't know the answer to that - it shouldn't be the case.
Another thing we noticed is that the .xml files are not being regenned, unless we actually do them manually. And normally the compile would always recreate the xml files.
We are trying this now in our 9.0.1 apps test system to see if it happens there as well. Obviously, we've not tried it in PROD yet.
Not UNIX - we are on Windows/NT.
The change is being made in the PD. No, have not used the debugger - the changes are simply not going into the compiled version. I
The problem occurs no matter where I test it - Portal, OR LID
Posted By Jimmy Chiu on 01/06/2010 08:58 AM Can you have your system engineer turn off all the read/write cache on your dev server? You would not happen to be using SSD(s) on your server, would you?
Not sure about SSD - what is that? No we've not had the system engineers do anything...yet. We may go there.
Posted By Joe O'Toole on 01/06/2010 09:05 AM So rebooting and running a manual srgen fixed it for one test cycle and then the problem returned? I wonder if this could be related to environmnet variables. You might want to try dumping your variables with a set command to a text file and comparing when you have the problem and when it works ok. You can also compare the user that has no problems with the one that does.
Once one person compiles, they cannot do it a second time. Well, they can, and it compiles, it just won't use the new obj. And last night, I deleted ALL the xml files for that program, both the ones in the \map folder and the one in the \src folder, and the program STILL worked in portal. That tells me that it's holding on to stuff somewhere...a cache that won't clear somehow. Once I rebooted, it cleared it, and then I got an error when I tried to access the program in portal again. Of course once I recreated the xml files, the error went away. But still, the program is compiling, and the listing has the new code, but the old code is what is being executed. And yes, I have been refreshing the cache...but it doesn't make any difference.
FYI, I tested our PROD system this morning with a program that is no longer used, and it is working fine there.
Have your system engineer do a full server hardware check? And have the engineer disable all the read/write cache on the raid controller while he's at it. You would also want to disable software hd cache on all the drives under device manager for troubleshooting purposes.