Hi All,

Myself and some colleagues are experiencing strange behavior in our development.
We can have perfectly good tested code in a fex file. But when we run it would give us an error (which one can very). But when we copy and past the exact same code into a different location in the same fex (the code is independent of other code in the fex) or into a new empty fex file it works just fine. This is causing much frustration and lost productivity. I have a clear example.

I have a fex which conditionally select (based on user input) which report "table file" to output. This report was developed months ago and tested. Now, I'm reviewing the program to get it ready for production and the following is occuring.

1. The program is crashing the agent on the run.

Ok, I start putting -EXITs around the code to see where the last "good" execution takes place. Well, that doesn't make any difference because if I put the -EXIT at the very top of the report before any type of table file or &var , any nothing but the starting comments it still crashes the report with a HTTP 500 error.

Ok, that's is odd. So I figured well maybe there is some weird formating error on the file itself. So, I start to re type the code into a new file. That works out just fine until I get to third report option. If I include the third report option and execute so that it executes the second report (which by the way ran just fine before adding the code for the third report) the report errors on an http 500 error.

Has anyone been experiencing similar code parsing issues?


Axion

This message has been edited. Last edited by: Kerry,

Axion, is the focexec very large? This sounds a lot like a case I opened at the beginning of 2008, 40212524. With autoprompting and running from the text editor, some very large programs where failing with an HTTP 500: java.lang.StackOverflowError. Doing the run from the Explorer view did not cause the error.

Does this in any way resemble your situation. The good news about the case was that they were able to reproduce it. The bad news is that I haven't heard that it is resolved. I am running 7.6.5.

Hi Ginny,

I'm not sure what you would call large but this particular focexec is 941 lines with stylesheet, comments, etc. All of the interaction with the database is in SQL passthroughs. Some joining between the results from those passthroughs. There are alot of &var in the program to control the program flow and to mold the SQL where clauses.

How did you get around this issue?


Axion

quote:

third report option

What does that mean?

Also, are you able to run the report with the command

SET XRETRIEVAL=OFF

which runs the code without retrieving data from the database? Do you have -REPEAT commands or GOTO commands? Do you have duplicate dialogue manager labels? How many dialogue manager variables are used in the program? Do you have -READ statements without a -RUN just before one?

These are the kinds of things I looked for in earlier versions of WebFOCUS, the newer, 7.6 versions test for most of this stuff, but it shouldn't hurt to verify these.

Axion, the case is still open. For testing, the users make the changes in the text editor, save the fex, then pop out to the explorer to run it. To my knowledge, the program runs from a browser or HTML launch.

1000 lines is a fairly big fex.

To my knowledge, this problem has not been fixed.

Francis, if he is having the same problem as my users did, it didn't matter which blocks of code were removed from the program to get it to work or fail. I started from the end then jumped up to the middle. It is the strangest thing. The commom element of all the programs (and thankfully there weren't too many) was that they were very large. I am amazed that NY was able to reproduce the problem. I hope one day that it is resolved.

Francis and Ginny,

I went over all of Francis' suggestions. I verified that the labels are correct and everything. There are ~50 &vars in the program. Using the Xretrieval = off didn't affect the report.

I checked the log and it gives the java.lang.StackOverflowError that Ginny mentioned.

But this is just one instance of a slew of issues we've been seeing. Some of which don't even deal with HTTP 500 errors. As I stated in the opening post, some pieces of code which are logically independent from anything else would execute erroneously depending on WHERE in the focexec the code appeared. It's frustrating to deal with and we all feel it would be difficult to trouble shoot with IBI since they would likely think we're nuts.

Axion

Axion, open a case and reference mine. That will give them something to work with so that they won't think you're nuts.

Opening a case is a good thing. But it will very probably not solve your problem in the short term.
What happens if you switch off the autoprompting feature?
Theoretically it should then bypass the pre-parsing of the code in search of unresolved & variables, and thereby avoid the stack overflow, allowing the process to run and finish in an orderly way.