We recently upgraded from WebFocus 8.09 to WebFocus 8.13.


Here is the version information on the Reporting Server:

Configuration Date 12/18/2012 14:22:33
Build Date 01/23/2015 18:44:26
Gen Number 827
Release 81M
Source Date 01/23/2015 17:25:46


Here is the version information on the Client:

Edition: WebFOCUS
Product Release: 8.1
Service Pack: 0.3
Build Version: branch8103
Build/GEN Number: 60
Build/GEN Date: February 5, 2015 2:10:49 PM CST
Application Server: Apache Tomcat/7.0.33


After the upgrade we encountered a problem with the use of the ‘MFD_PROFILE’ in a set of metadata. Anytime the file with the ‘MFD_PROFILE’ is accessed it will hang the system up. About the only way to stop it is to kill the process in the Task Manager on the server.

I put a simple example together below:

FILENAME =TFMIC_DYNAM_REGION,
SUFFIX =DB2,
MFD_PROFILE =irfui_user_region_filter,
SEGMENT=TFMIC_DYNAM_REGION,
SEGTYPE=S0
FIELDNAME=REGIONTYPE, ALIAS=REGIONTYPE, USAGE=A1, ACTUAL=A1, $
FIELDNAME=REGIONCD, ALIAS=REGIONCD, USAGE=A2, ACTUAL=A2, $
FIELDNAME=DIVISIONCD, ALIAS=DIVISIONCD, USAGE=A3, ACTUAL=A3, $
FIELDNAME=REGIONDESC, ALIAS=REGIONNAME, USAGE=A30, ACTUAL=A30, MISSING=ON, $
FIELDNAME=DIVISIONNAME, ALIAS=DIVISIONNAME, USAGE=A30, ACTUAL=A30, MISSING=ON, $

TABLE FILE tfmic_dynam_region
PRINT *
END

If I run the table file, it will hang up. If I remove the MFD_PROFILE, it will return results from the file. We are using this as a filter for security access. As mentioned, this is code that has been running perfectly in prior releases of WebFocus the last one being 8.09.

Thanks for anyone's help.
JR

This message has been edited. Last edited by: johnh,

The Manual

Need to add the application folder where the focexec resides, my guess..

This message has been edited. Last edited by: Tom Flynn,

Tom,

Thanks for your response and the link for the manual. Adding the app folder doesn't make a difference. I have tried it with and without. In the manual, there was nothing noted (that I found) about changes to the way MFP_PROFILEs are handled beginning with version 8.13.

The only thing I found in the manual I wonder about is a caution about issuing a request against the file in the master file. I am doing a 'FILTER FILE' using the file in the master file. However, if this is a problem why did it work before?

JR

Hi JR,
Sounds like a normal release 8 BUG!
I would open a case with IBI...
Tom

Thanks Tom,

That's what I thought also.

I appreciate your help,
JR

Sounds like the FILTER FILE is engaging the profile and you are being put into an endless loop ... so to speak.

Add some logic to prevent a second execution in the profile

-DEFAULTH &&DOFILTER = 'YES'
-IF &&DOFILTER NE 'YES' GOTO :SKIP_FIL;
... some code
-:SKIP_FIL
-SET &&DOFILTER = 'NO';
  

Or something like that.

dhagen...Thank you very much. This works perfectly.

It is obvious the 'FILTER FILE' is invoking the MFD_PROFILE in this version where it did not in previous versions causing it to hang in an endless loop. I don't know if this is a bug or feature change?

I found the following in the doc:
-----
'The MFD_PROFILE is executed for every TABLE, TABLEF, MATCH, GRAPH, CREATE, DEFINE, CHECK, ?F, and ?FF request against a Master File that contains the MFD_PROFILE attribute.'
-----

I also read in a different link where the CHECK command was previously not invoked but that changed and I wonder if the same is true with the FILTER command.

At any rate (thanks to your help) I have a solution regardless if IBI fixes this or not.

JR

One postscript to this. The change I implemented did keep the server from hanging but did not completely fix the problem. The change would only allow the MPD_PROFILE to be executed once during the session (as long as the double amper was set). However I need this to execute each time the table is referenced.

So, the only way I could figure out to do this was to let it run every other time it was executed. I know there is a better way do do it but the following works:

------

-DEFAULT &&LOOPCNT = 0;
-SET &&LOOPCNT = &&LOOPCNT + 1;
-SET &&LOOPCNT = IF EDIT(&&LOOPCNT, '$9') EQ ' ' THEN '0' | &&LOOPCNT ELSE &&LOOPCNT;
-SET &&LOOPCNT = IF EDIT(&&LOOPCNT, '$$9') EQ ' ' THEN '0' | &&LOOPCNT ELSE &&LOOPCNT;
-SET &&LOOPCNT = IF EDIT(&&LOOPCNT, '$$$9') EQ ' ' THEN '0' | &&LOOPCNT ELSE &&LOOPCNT;
-SET &&LOOPCNT = IF EDIT(&&LOOPCNT, '$$$$9') EQ ' ' THEN '0' | &&LOOPCNT ELSE &&LOOPCNT;
-SET &&LOOPCNT = IF EDIT(&&LOOPCNT, '$$$$$9') EQ ' ' THEN '0' | &&LOOPCNT ELSE &&LOOPCNT;

-IF EDIT(&&LOOPCNT, '$$$$$9') EQ '0' OR '2' OR '4' OR '6' OR '8' GOTO :SKIP_FIL;

....original code.....

:SKIP_FIL

------

Thanks,
jr

Hi, sorry I'm semi-retired so don't get on as frequently as I probably should.
This has worked for other customers . At the very END of the procedure , right before you get out, -SET &&LOOPCNT = 1;
-IF &&LOOPCNT GT 1

Then the logic works
-IF &&LOOPCNT GT 1 GOTO :SKIP_FIL;
... some code
including
-SET &&LOOPCNT = 2;
-:SKIP_FIL
-SET &&LOOPCNT = 1;

I have opened a project for programming to see if they can do this "automagically" .

Again, my apologies for the delay