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.
It would be nice if IBI would make the IBFS pathing scheme acccept * as a reference to the location of the referencing file (i.e., when file A references file X and the path to X contains *, the full path to X will be calculated using the full path to A to supply the missing qualifiers).
Then a parent and its co-located children could be copied or moved amongst Repository folders without issue.
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005
Your first line of code, -INCLUDE &INCLUDE_VAR.EVAL (sans -MRNOEDIT) is syntactically an MR include, and will be rejected. MR does not execute your fex code, it just performs a static analysis, looking for lines that it has to modify (and/or take special action to support). Thus, MR has to stop the music, since it cannot forward the referenced MR fex file.
In your second line of code, when MR sees
-MRNOEDIT -INCLUDE &INCLUDE_VAR.EVAL
it strips off the -MRNOEDIT, and passes the rest through to the Reporting Server without change. So far so good.
Before execution, the Reporting Server scans the code - performing a static analysis (akin to MR's) to see whether it should issue an Autoprompt. Whenthe scan encounters
-INCLUDE &INCLUDE_VAR.EVAL
he complains that it cannot scan the included fex for unresolved amper vars (since at that point he, too, does not know what value the amper var will contain) -- that's when the FOC2905 is issued.
(If you turn off autoprompting, you should not get the FOC2905).
BUT then the Reporting Server will (in my experience) proceed to execute the code, and in execution the -INCLUDE in that form is perfectly ok (it's even a recommended practice -- per DN 4501181.0114 "Developing Reporting Applications [8.0.070]", p 392]).
By the way, the .EVAL is unnecessary.
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005