We noticed a difference in behaviour between procedures that end with -RUN and those that end with just a TABLE requests END statement. The difference seems to be mostly related to whether (syntax) errors are triggered or not, but that's not really the point here.

The big question is why the behaviour can be different?

I mean, what's the difference between:

TABLE FILE CAR
PRINT CAR
BY COUNTRY
END
<<EOF>>

And:

TABLE FILE CAR
PRINT CAR
BY COUNTRY
END
-RUN
<<EOF>>

IBI has been telling me that those requests are not the same (when this popped up while using -EXIT instead of -RUN), but I fail to grasp what possible use that might have. Can anyone here explain? To me it just looks like careless language design as it stands.

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

For me I found that using -RUN is better because each messages, errors, memory allocation/deallocaion, hold files, ... is done, displayed and completed at the steps is referring to and before the next step starts.

In debugging it is much more useful because every thing is tight together: Focus Code, translated SQL code, messages/errors of a each step are aligned. Which is not the case without -RUN where the messages/errors are placed at the end of the log. And then you have to find out to which step it belong...

There's something called the FOCUS Stack where code gets stacked until the end of a fex or until a -RUN. I don't know the gory details.

I stick a -RUN after every END statement (DEFINE, JOIN, TABLE). In this way if there is an error you see the error where it occurs, not at the end of the code.

As far as I know, sometimes a -RUN is required - before a -READ or -READFILE for example, because the WEBFOCUS code must run before the Dialogue Manager code...

This message has been edited. Last edited by: Francis Mariani,

I am familiar with what -RUN does in between FOCUS statements, the case in point is about -RUN after the last statement!

Statements on the FOCUS stack do get executed at that point, same as with -RUN, or you wouldn't get report-output without -RUN. However, I found that the effect without -RUN after the final statement is not always the same as with it, even when EOF is reached next.


Case in point, I was reproducing an issue with a report with PDF output (can't share, unfortunately), where the repro was containing but a single TABLE request. Hence, there was no opportunity for error processing to get postponed until after a next FOCUS statement.

In copy-pasting I forgot to add the END statement after the TABLE request and there was no -RUN after it, just an EOF.
Hence, the TABLE request ended with an ENDSTYLE statement and I got an error ("(FOC36218) AN EQUAL SIGN (=) IS INVALID IN ON TABLE SET") that made no sense at all - the only ON TABLE SET statement was for the STYLE, and that did not have an '=' symbol until inside the style rules block:

ON TABLE SET STYLE *
$
TYPE=FOOTING, SIZE=8, BORDER-TOP=LIGHT, JUSTIFY=CENTER,$
-* Etc...
ENDSTYLE

Adding -RUN at the final line, with the (TABLE's) END statement still missing, resulted in the desired PDF output.

I would have expected that repro to behave the same without -RUN, because processing reaches EOF and should execute all stacked statements at that point.

Apparently there is a difference between -RUN and EOF, but why?!?

Here's a repro using the CAR database:

TABLE FILE CAR
PRINT CAR
BY COUNTRY
ON TABLE PCHOLD FORMAT PDF
ON TABLE SET STYLE *
$
TYPE=FOOTING, SIZE=8, BORDER-TOP=LIGHT, JUSTIFY=CENTER,$
ENDSTYLE

Adding:

-RUN

And the report works...

quote:

Apparently there is a difference between -RUN and EOF, but why?!?

Don't we have enough stuff to worry about? Just stick an END where it's needed. I've found you get very odd and misleading errors when certain major syntax errors exist in the code.

My guess would be that there is some exception/error handling code that allows the parser to "END" a table request when it is obvious that the statement is finished.

The -RUN would do this as it is an explicit statement that you want all code up to this point to be run.

An EOF - while an indicator that the file is finished - may be passed due to an error in networking, an issue with the reporting server or several other sources. So when you don't have the -RUN the parser is left trying to guess on what the programmer wanted to happen or whether there should be more to come.

Obviously both instances should give the same error as a missing END is quite a large syntax error for FOCUS code

Cheers

Stu

Stu, I think that may indeed explain what happens.

If I attempt a parallel to SQL, I suppose this is what happens with respect to commands stacked up to the -RUN or EOF (which excludes everything before the last -RUN of course):

• in the case of -RUN, stacked commands are "COMMITted",
  
• in the case of EOF with an error condition, stacked commands are "rolled back", and
  
• in the case of EOF without an error condition, stacked commands are again "COMMITted".

It appears that somebody thought that -RUN should do our thinking for us and implicitly add that missing END when we "clearly" forgot to. I would much prefer (and I think you're with me on that respect) to get an error in such situations. Hidden errors generally result in nasty surprises further down the chain in my experience.

But even if that's the case, IMHO EOF should behave the same, at least in this particular case.