When error occurs and the subsequent request is successful, &FOCERRNUM holds 0. But documentation says, in case of multiple errors, &FOCERRNUM will retain the latest error number.

When I checked in Workspace->Monitor->Data Services, it says latest error number=9. But &FOCERRNUM at the end of the procedure returns 0.

I don't want to Sum &FOCERRNUM after each TABLE FILE request.

-SET &VAR1=0;

TABLE FILE CAR
PRINT 
CAR
COUNTRY1
-****there is no field named COUNTRY1
ON TABLE HOLD
END

-*********Above request will give error

-SET &VAR1=&VAR1+&FOCERRNUM;

TABLE FILE CAR
PRINT 
CAR
ON TABLE HOLD
END

-SET &VAR1=&VAR1+&FOCERRNUM;

TABLE FILE CAR
PRINT CAR
COUNTRY
ON TABLE HOLD
END

-****Above two requests are error-free

-SET &VAR1=&VAR1+&FOCERRNUM;

-TYPE &VAR1 &FOCERRNUM

-IF &FOCERRNUM EQ 0 THEN GOTO :LBL_NO_ERR;
-TYPE at least one error
-GOTO :LBL_END
-:LBL_NO_ERR
-TYPE error free
-:LBL_END

Is there a way to get latest error in case of one or more errors, else 0?

This message has been edited. Last edited by: Ram Prasad E,

Are you talking about errors that can throw in production, or is this part of your development process?

The easiest way in development is to -set &echo=all and perform a -type &focerrnum in your code so that it appears after each selection.

Summing your focerrors likely will not give you an effective tool to understand a problem, unless you know the location where each value occurred. At that point you may just as well type them out to your output strand and have a look.

J.

I stick this code after every END statement:

-RUN

-*-- If a WebFOCUS error occured, display an error page ----
-IF &FOCERRNUM NE 0 THEN GOTO FOC_ERROR;

I don't let the program run any further is an error is found.

quote:

But documentation says, in case of multiple errors, &FOCERRNUM will retain the latest error number.

That is exactly what is happening. The lastest error number is 0 which is the error number that corresponds to a non-error (confusing?).

Why would you want to ignore an error and just continue your process? Most frequent than not an error will get propagated down your code whenever you make a reference to any HOLD file that could not be created due to the error in the first place.

If WebFOCUS actually kept FOCERRNUM as the last "known error" throughout your procedure (and excluding 0 as you'd wish), how could you possible know where in the procedure did the error actually happen so you can do something about it?

As John and Francis have pointed out, you'd be better off checking right away and dealing with each exception as they happen on a statement-by-statement basis. Your code might decide to stop right away if the error is "fatal" (your business rules should mandate that) and log it somewhere or just consider it an "annoyance" with no further consequences and just keep on going (again, business rules determine that) but regardless of which step you take, you have to do it for each and every statement in your code. Leaving it all to be checked at the very end will serve no purpose other than knowing that "something failed" but debugging can then be quite cumbersome.

And if you happen to be using ReportCaster, ANY error that is not SPECIFICALLY managed will cause your job to fail without logging to the RC logs. I concur with the others in that you shouldn't just ignore the errors. You want to find the FIRST error and deal with it there. Any subsequent code that may execute successfully will eliminate the error code (reset to 0.) Absolutely a big mistake to allow further processing after any error has occurred.

Also, "last error number" in the WF console and &FOCERRNUM for a request are not the same thing. The may be the same at a given point in time, but if you're using multiple connections per agent, there's no guarranteeing that the "last error number" corresponds to the procedure you just ran. And if you're only using a single connection per agent, it would NEVER be correct (as the agent is closed after the request has completed/failed) and a new agent is restarted. The only way to know for sure would be to use traces.

quote:

And if you happen to be using ReportCaster, ANY error that is not SPECIFICALLY managed will cause your job to fail without logging to the RC logs

Very valid point! I forgot about Mr. Caster that seems a bit sensitive when it comes to errors (and even WARNING messages depending on the configuration).

Thanks for all your replies.

John, I want to capture production errors along with the filter conditions for which the error occurred.

FILEDEF EMGFILE DISK <app-dir>/ERR_LOG.TXT (APPEND 
SET EMGSRV=FILE
TABLE FILE ..
.
.
ON TABLE HOLD
END
TABLE FILE HOLD
PRINT
.
.
END
-****At the end of the execution
-IF &FOCERRNUM NE 0 THEN GOTO ERR_COND ELSE GOTO NO_ERR;
-ERR_COND
-WRITE EMGFILE Date: &YMD Time: &TOD FILTER_1: &PARAM_COND_1
-NOERR

Francis, I have more than 50 END statements in the entire application. So the only way is to include the code snippet after each END? I though there will be something like error stack for each execution, which can be evaluated to know errors at the end of the procedure.

Neftali,

quote:

The lastest error number is 0 which is the error number that corresponds to a non-error (confusing?).

Why would you want to ignore an error and just continue your process?

Yes, confused when webconsole agent displayed last error=9. And the errors are not frequent one. Error occurs for some specific condition. So thought of including at the end of the execution.

You are correct Darin. RC needs some special attention.

This message has been edited. Last edited by: Ram Prasad E,

quote:

the only way is to include the code snippet after each END?

Absolutely and, in my opinion, the way to code.

If you were writing a CobolII program against an IDMS datasource, when would you check that the call to IDMS was successful? At the end of the code? I doubt it.

WebFOCUS is no different to any other language, you have to code the control in. WebFOCUS, like any other 4GL, will do some things for you but my rule of thumb is to always control the processing yourself and leave nothing to chance.

If all your "production" jobs are deficient of -RUN and then error checks then you have a big job ahead of you!

Finally, the console will report the highest error number occuring with that agent, so if your agent refresh is set to 100 then the error could, perceivably, have occured in a prior job using that agent (I think?).

IB have a FOCUS internals course that might be useful for you.

T

quote:

So the only way is to include the code snippet after each END?

Ram, that is the way to do it BUT you can make simplify the process by creating a FOCEXEC with all the validations and logging stuff that you want and then just use it and reuse it whenever you need it via -INCLUDE.

Also, you don't technically have to add that check after every "END" statement but only those that actually perform a task. For instance, a JOIN statement needs an END phrase when it spans more than one line but you must not necessarily check for errors right there; same applies for DEFINE FILE ... END; I usually don't check for specific errors right there.

You need to do it right after "big" statements such as: TABLE FILE .. END, MATCH FILE ... END, GRAPH FILE ... END

Here's some pseudo-guide of what you could do ...

Create a check_error.fex procedure (or whatever name according to your own naming conventions) which can be as simple or elaborate as you need it.

-RUN
-IF &FOCERRNUM EQ 0 THEN GOTO :NO_ERR;
-:ERR_COND
-* Log error to database, file or both
-WRITE EMGFILE Date: &YMD Time: &TOD FILTER_1: &PARAM_COND_1
-* Set some flags or indicators as you want
-SET &ERR_FOUND_IND = 1;
-:NO_ERR

Now, in your actual code just make sure you -INCLUDE the aforementioned procedure to check for errors ...

-SET &ERR_FOUND_IND = 0;
-*
FILEDEF EMGFILE DISK <app-dir>/ERR_LOG.TXT (APPEND 
SET EMGSRV=FILE
JOIN .. IN FILE
  TO AL ... IN ...
END
-*
DEFINE FILE ...
.
END
-*
TABLE FILE ..
.
.
ON TABLE HOLD
END
TABLE FILE HOLD
PRINT
.
.
END
-* Check for errors
-INCLUDE check_error

-* Continue -OR- Stop depending on your rules.
-* Evaluate &ERR_FOUND_IND or &FOCERRNUM to determine what to do
.
.

- Neftali.

Thanks Tony and Neftali.

Hi Ram,
U can use the below code to catch errors in production:
-IF (&RETCODE LE 1) AND (&FOCERRNUM EQ 0) THEN GOTO SKIP_EXIT;
-TYPE *** RETCODE = &RETCODE
-TYPE *** FOCERRNUM = &FOCERRNUM
-TYPE *** FORCED TERMINATION!
-EXIT
-RUN
-SKIP_EXIT