We have a report that checks for the existence of a (focus-format) HOLD-file by trying to read a record from it. On our test-server that works as expected, the file isn't there the first time, &FOCERROR gets set to FOC205 and the script moves on. Happy times...

But, on our production server it aborts, with the same error!

? SET ERROROUT
-RUN
ERROROUT                 OFF
-* Check whether we authorised already
TABLE FILE VOI00060H_AUTH
PRINT PRODGRP
WHERE RECORDLIMIT EQ 1;
ON TABLE HOLD
END
-RUN
(FOC205) THE DESCRIPTION CANNOT BE FOUND FOR FILE NAMED: VOI00060H_AUTH
Exiting due to Exit on Error...
BYPASSING TO END OF COMMAND

I thought the ERROROUT setting would control this behaviour, but as can be seen above that's set to OFF on the problematic server.

Any ideas?

Weird, explicitly setting ERROROUT to OFF did help, even though it was already set to OFF globally?!?

Hi Wep5622,

I checked with our technicals and was suggested that, it looks like this is resolved with a setting. In order for us to properly document the issue, you may want to open a case any way. Please include sample code and traces when opening a case. The phone number is 1-800-736-6130, or access online at InfoResponse.

Cheers,

Kerry

quote:

Originally posted by Kerry:
I checked with our technicals and was suggested that, it looks like this is resolved with a setting.

There's a setting that sets how another setting (ERROROUT) behaves depending on the scope in which it was set?
What setting would that be?

Or are you misunderstanding the problem here?

Hi Wep5622,

I resent this to our internal technical staff. I'll get back to you shortly.

Thanks,

Kathleen Butler
Information Builders

Hi Wep5622,

Sorry for the delay but I hope this helps.


ERROROUT
The ERROROUT parameter controls how a batch FOCUS job step responds to an error condition encountered in a procedure. This parameter cannot be set with the ON TABLE SET command.

When ERROROUT is set to ON, any error message generated terminates the job step and issues a return code of 8. Warning messages do not invoke this behavior. When ERROROUT is set to OFF, depending on the specific message, FOCUS determines whether FOCEXEC processing continues. Users can check a Dialogue Manager variable, such as &FOCERRNUM and issue the following command to terminate FOCUS and set n as the return code:

-QUIT FOCUS n

exit rc

Note: The ERROROUT setting is ignored in an interactive session.

The syntax is:

SET ERROROUT = {ON|OFF} (select OFF)

where:

ON

When an error message is generated in a batch FOCUS job step, ON sets the return code to 8 and terminates the job step.
In addition, the following message displays to inform the user why the program terminated:

Exiting due to Exit on Error

OFF

Does not set a return code or automatically terminate a job step or procedure in response to any error message. OFF is the default value.


Maybe the issue is batch versus interactive.

Let us know if this helps or please feel free to open a ticket with our technical support team.

Sincerely,

Kathleen Butler
Information Builders

What is considered an "interactive session" in the context of a (WebFOCUS) HTTP request? I don't see how that would apply.

Anyway, the described behaviour contradicts what I've been seeing.
ERROROUT is supposed to default to OFF and is ignored in an interactive session, yet it behaves like it is ON by default on our production server. Printing its value however (using ? SET ERROROUT) it claims that the setting is OFF.

To recap:

• Printing the current setting of ERROROUT yields OFF,
  
• The default for the ERROROUT setting when not specified is OFF,
  
• Interactive sessions ignore the ERROROUT setting altogether, which I assume means it is OFF,
  
• Yet, when running the procedure it behaves as if ERROROUT=ON.

That seems impossible!

Also, when explicitly setting SET ERROROUT=OFF in the procedure, it behaves correctly. That suggests that we're not dealing with an interactive session on the production server. On the test server we can get the observed behaviour by specifying SET ERROROUT = ON, so we don't appear to have an interactive session in there either; changing the setting changes the behaviour, so it's not being ignored.

It's a mystery. Computers are logical, they're not good at creating mysteries, so this must be a human error somewhere.