I have inherited a WebFOCUS environment that I feel is a bit of a mess. I have a question regarding the APP PATH nad MRE folders.

From edasprof.prf:

APP MAP ent_app d:\ibi\WebFOCUS53\basedir\enterpri\app
APP PATH ent_app eidw system ibisamp ibinccen

Is this conventional, adding an MRE domain folder to the APP PATH?

It seems to cause problems with -INCLUDE statements - they work sometimes and don't other times. Sometimes you need -MRNOEDIT. Sometimes drilldowns from MRE reports don't work when executed from a Dashboard.

The reason for adding the MRE domain folder to the APP PATH is that several programs in the (MRE) APP folder are -INCLUDEded in reports in multiple MRE domains.

I'd like to know if anyone else is doing this kind of thing?

Thanks,

Francis.

pF, we've been talking to ibi about this since version 524. Before that version, everything worked across domain, but the higher the version, the more work you had to do. 436 was the easiest. But with 524, it all fell apart.
We outlined very carefully what the problem was.
We never got a bullet proof answer, just alot of 'you're wrong, oh its not a problem, APP PATH will fix it'.
My absurdly-burdensome workaround is to copy each included fex from its single source into the current agent.
and another flavor of the problem extends to embedded fexes... now the EXEC command seems to have an MRNOEDIT in it by default...which means we can't use it to call some jobs (like remote jobs..that already have their own MRNOEDIT in them)). And the {blank}EX command workaround is history with 53
-S

In our environment for -includes we oftem just copy them over into the other files area of the domain in question. Maintenance nightmare of course.

Happy New Year

Yikes! Thanks for the information.

According to my previous boss, he sets up MRE apps this way: All programs in MRE Domains have minimal code in them (what he calls "stubs") which have -INCLUDEs of fexes in the APP PATH. I cannot recall if -MRNOEDIT has to be coded as well.

Nevertheless, I have a bit of a mess on my hands. I would like to find a definitive answer for Dashboard, MRE, Drilldown and ReportCaster reports.

Cheers.

your previous boss's method worked without a hitch up to 524 (or 5 i can't quite remember);
in 436 -include fexname worked, as long as the fex was somewhere on the edapath.
in 523 that -include had to specify the full path of the fex
-include d:\ibi\....\fexname.fex
and all was swell; and stubs called fexes from anywhere, passing domain-specific parms.
Now the -includes don't work, and parms can't be openly passed to embedded ex.
It used to be that a space in front of an EX FEXNAME would take parms from the current agent and pass out more parms back to the host fex. not any more. there's no way to get parms out of an embedded fex at all, and the only way to pass parms to an embedded fex is on the exec line.
EXEC fexname parm1=...
A jcl job with repeated executions of the same embedded fex...won't work anymore. ibi's response is 'just use -includes'... can't control branching to the same statment labels. One FP'er has posted that he
dynamically sets his statement label names based on the execution iteration. a nifty work around...but we shouldn't have to do this.
Let us know, would you, if you get anywhere?