As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
Maybe I'm off base here, but after our recent upgrade from 7.6.8 to 7.6.11 an issue was brought to my attention by a user.
In our older version, if there were an error in the fex file, it halted processing at that line (to the best of my remembrance). An ugly HTML based 'No HTML Output' page was displayed with the error at hand.
After the upgrade, it appears the environment is much more error tolerant. These errors that should have ground execution to a halt in a hurry now seem to allow further processing.
Case in point:
TABLE FILE CAR
PRINT
TOMATOES
END
-HTMLFORM BEGIN
<html> <head> <meta HTTP-EQUIV="REFRESH" content="0; url=http://server:8080/approot/library/filename.pdf"/> </head> <body> !IBI.FIL.REPORT; </body> </html>
In real life, it creates a file (filename.pdf) based on the output of the above query and then redirects the user to the file, generated and saved on the server. Prior to upgrade, the inclusion of the 'TOMATOES' field in CAR would have thrown an error and stopped processing. Post upgrade, the program happily executes all the statements, skipping over the error thrown in the first step. This is bad.
Is there a setting I can add to the Server config file that reinstitutes the old behavior or otherwise achieves the same effect? Any ideas?
- ABTThis message has been edited. Last edited by: ABT,
I entirely concur with Waz. Any production code must have error checking along the way right after any important piece of code (TABLE FILE, MATCH FILE, GRAPH FILE, ..).
Take a look at this post for some insights about the matter.
Thanks for the confirm and thread, that does certainly make the most sense for the long run. I am, however, in the 'hundreds of production programs coded this way' camp and am looking for anything (server setting, 'set' declaration, etc) that will reinstitute the way execution previously occurred (halting execution upon error).
Is this something a case should be opened to address? Or is this simply a case of a bug that is finally fixed? I can't imagine, as it is less restrictive, instead of more.
WebFOCUS always soldiers on and runs through all the code - you could have 25 errors accumulating and it would still go on - UNLESS you trap the error. It's been like this from the very beginning. The most graceful method would be as suggested in the post that Neftali mentioned.
ERROROUT is a recently added command and really doesn't do enough - I don't rely on it.
SET ERROROUT = ON
TABLE FILE CAR
PRINT
APPLES
END
TABLE FILE CAR
PRINT
JACKALS
END
TABLE FILE APPLES
PRINT
CAR
BY JACKALS
END
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
Agreed, but I'm looking for a quick interim fix (erm, workaround). Neftali's approach is not off the table and makes the most sense for a long-term solution, but in the meantime, I'm hoping to get something just as bad as relying on the prior approach of verbal failure (versus silent failure).
Believe it or not, for my most immediate need, errorout works until something better can be developed and deployed. And thanks to the community (this thread and the other) I have a great jump start with approaches for resolution.
I don't understand why you feel the behaviour changed after upgrading from 7.6.8 to 7.6.11 - this is the way WebFOCUS has always behaved, ERROROUT tames it a tiny bit.
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
With all due respect, no it isn't. At least not for our 7.6.8 installation. Going back to my original code snippet (it is the closest to what I am trying to do/workaround in production).
TABLE FILE CAR
PRINT
TOMATOES
END
-HTMLFORM BEGIN
<html> <head>
<meta HTTP-EQUIV="REFRESH" content="0; url=http://server:8080/approot/library/filename.pdf"/>
</head> <body> !IBI.FIL.REPORT; </body> </html>
When this code was run on a 7.6.8 Client/Server via Dev Studio 7.6.6, it throws a 'No HTML Output' error with a visible message regarding not being able to find a column 'TOMATOES' in the CAR file. After our upgrade (Server/Client/Dev Studio 7.6.11), the user gets a browser with 'filename.pdf' loaded (or Acrobat or however the user has their system configured).
I've been on 7.6.8 for 6 months (I'm new to this role) and 7.6.11 for a week and I can tell you that the 'No HTML Output' error was the user experience prior to upgrade.
Since this was such a marked change in the execution, I was thinking there might be a setting that did not make it through the upgrade or something similar.
There are some redirection settings in the WF Client for specific file types, but I don't know if those would affect the behavior your are experiencing. You can compare the new and old settings to see if they are different for the file type(s) you need.
Regards,
Darin
In FOCUS since 1991 WF Server: 7.7.04 on Linux and Z/OS, ReportCaster, Self-Service, MRE, Java, Flex Data: DB2/UDB, Adabas, SQL Server Output: HTML,PDF,EXL2K/07, PS, AHTML, Flex WF Client: 77 on Linux w/Tomcat
Posts: 2298 | Location: Salt Lake City, Utah | Registered: February 02, 2007
My concern in the long run, is that if you get the process to operate that same as 7.6.8, then there is no need to "Fix" your code, and it will go on this way.