update: july 22...css has determined that 533 and 4 are not compatible with iis6, which is whats in win2003 server. the wicked infinite looping, having nothing to do with &echo, is caused by iis6.
so...now we know...6 gruelling weeks later..but now we know...
-*------------------------------------ *
533 so far has been a nightmare.
1. with -SET &ECHO = ALL a big job will loop indefinitely. with echo = on, its sometimes ok, but with any embedded dialog manager, it still loops ad infinitum.
2. embedded fexes don't recognize &vars set by the host fex.
so if you set an &var in fex1, then try to run a fex with EX fex2, it won't recognize the value of the &var, it will only use the defaulted value inside fex2. So if Fex1 looks like this:
-SET &PARM1 = 'VAL2';
EX FEX2
it wont work.
EX FEX2 PARM1 = VAL2 won't work either.
using -MRNOEDIT won't help, if fex2 has its own embedded code with its own mrnoedits...it all craches.
-INCLUDE fex2 doesn't help if fex2 has statement labels that might conflict with existing labels inside fex1, or if fex2 needs to be run multiple times inside fex1... goto label conflicts.
3.AND...if that's not enough
you can no longer use GOTO labels that are compound names
-GOTO DO&MYPARM ; works but the target
-DO&MYPARM isn't recongized.
doesn't work in 533, works fine in 52n.
4.AND...report caster doesn't respect &vars that are set with any embedded fexes, -INCLUDE or EX. That means emails with variable style sheet code enabled via -INCLUDE won't work. that's pretty much my entire application.
5.AND ... i forgot this one. the text editor in MRE now breaks when you try to do a REPLACE ALL with an & in the text. never did before. so globalizing &vars would mean Textpad or Ultraedit for sure.
6.AND ... can't use multiple USE statements with off-server databases. If your db's are on another box, you cant
USE
X
Y AS X
END
it only reads X.
Anybody else having nightmares in 533, or have any workaround ideas? Having fun yet?
thanks.
(win2003 server)

Did you use cgi before 533? And are you now using servlet?

We started using WebFOCUS with servlet only (no experience with cgi, but personally, more than 25 years with FOCUS).

We have gone from 5.2.1 to 5.3.2 in incremental steps, and will be installing 5.3.3 in a week or two.

It has proven to be a struggle, since, as you point out, much of the Dialogue Manager code that we have used for years is now not working as expected. This means "redesign", which is expensive.

It almost seems as though cgi and servlet use different versions of DM.

Suzy

thanks suzy. we use servlet for mre.
are you sure you want to upgrade to 533? is really a mess.

Hi Susannah

We pretty much have to go to 5.3.3. For us, it will probably not be that much different from 5.3.2.

Were you also going from 5.3.2 to 5.3.3 for MRE?

Thanks. Suzy

525 to 533
hoping to be able to use XFOCUS db's.
but that seems to be out of the question now.

We just upgraded to 533 yesterday and one problem we had that look similar to yours is that ReportCaster used default values for a number of our parameters. The issue turned out to be that the conversion of the ReportCaster table (botparms) dropped several rows (140 out of 325). It seemed like it only kept one parameter per report.

Marie

Marie, OMG! that's just awful.
Did you open a case, or talk to anyone about it?
They seem to have their heads in the sand over this release.

Yes, we opened a case after the fact.

Susannah,

we're about to go from 5.2.7 to 5.3.4 in a couple of weeks. Your experiences of 5.3.3 are a bit worrying. Are these issues solved in 5.3.4? Are you still struggling?

H, don't do it. we're still in a mess. we got a hotfix yesterday; didn't work; if you have a development server, or a test server, by all means test, but wait for 534 which is due out in a week or so. i'm convinced that ibi doesn't understand whats wrong. so much is different about how DM is handled. over 6 mos ago we reported that excel formula didn't work in 436. (didn't respect parentheses, couldn' column total properly) and they said they'd fix it in 534. That was 6 months ago. So i have no expectation that 534 will address the issues we just found with 533. Really, don't do it on a production system.

Thanks Susannah. No, we're not going to a production box. In fact we're not even going for a dev box, we'll start with a test environment and are having a fall-back route (ie. if 5.3.4 does not work, we'll continue with 5.2.7).

oh wonderful. Keep in touch with me, would you? i'ld like to hear how your testing goes.

Susannah, no problem. Will do.

H�kan

1) WFServlet Looping was something that was caught in 533 after it was released. We have addressed that problem with a hotfix in 533, as well as 534 Client (not released yet) and 7.1. The problem we found was when &ECHO=ALL or ON was SET. Was this your sceanrio? If so, open a case
with Customer Support Services, if you haven't already, and ask for the "533 Looping fix".
Not a very creative name, but it works for the scenario I've described.

2) If you EX FEX2, from within FEX1 and have an &VARIABLE set in FEX1. FEX2 will not see it.
The functionality you described would never work. The example you described of EX FEX2 VAR=VALUE should absolutely work. If there is a case you have opened with Customer Support with an example, we can review, but I tried this in 523, 528 and 533 and it all worked.

3) I can get this code to work in 523, 528 and 533:
-SET &MYPARM='AA';
-TYPE BEGIN
-GOTO DO&MYPARM
-EXIT
-DOAA
TABLE FILE CAR
PRINT CAR
END
Is this a representation of what you have?

4) We are working with development on this problem, with the goal of having this addressed in 534 WebFOCUS Client/ReportCaster. Unfortunately, the fix is complicated, that
it cannot be included in a hotfix for 533.

5) I've been able to get this to work fine in 533. Changing &VARIABLES to some other name.
Changing values that have Ampersands in the middle of text. Replacing All etc. If you haven't already, please open a case with Customer Support, and I can review additional documentation you provide.

6) We have addressed this problem with the 534 WebFOCUS Reporting Server Service Pack.
You can refresh your existing 533 Server install, saving all of your configuration information. Contact Customer Support Services for download information.

I hope I've turned some of your nightmares into pleasant dreams.

Ben Naphtali
Strategic Support Manager
Business Intelligence Products Group

1. part of the problem, but the hotfix had no impact whatsoever and the rest of the problem was looping that was far more insidious. we opened a case. noone would actually address the indisiousness of the looping problem.
2. always worked;
3. no -DOAA is to be -DO&AA
533 is a nightmare, there are cases open on all of these. i dont' care anymore. i'm waiting for 534. my expectations couldn't be lower.

Well Susannah...never heard you so Focus Sad before. We have 5.3.4 installed in Test. Have had some Graph issues...and something that has been working fine in the other 3 releases...passing a Blank with an &Variable..now...blows up. We are working on a work around..but who knows how many things this effects.

Susannah,

If you like, you can call me in NY and we can discuss these cases you have opened. Friday and later would be best. I wouldn't look to 534 as a panacea, since there are some unresolved questions from your posting:

1) For the Looping problem, I'm unclear what you are saying. The hotfix didn't solve the issue? It could it have been that it wasn't applied properly OR, there is another permutation of the problem you encountered. Every single customer that has had this looping problem, has been resolved with this hotfix. Same fix went in to 534, so if there is something we didn't catch, you will run in to the same issue in 534.

2) If you execute focexec B, from focexec A. The only way you can pass a variable is on the EX line OR via a global variable. That is the way FOCUS has always worked. The scope of an &VAR is within the focexec. If you used a -INCLUDE, you could reference that &VARIABLE in the -INCLUDEd focexec, but that is another story.

3) Can you provide a piece of code that works in 528?

Ben Naphtali
Strategic Support Manager
Business Intelligence Products Group

Oh, this is not good. If Susannah is FOCUS Sad, what's in store for the rest of us? Susannah, you must know that we ALWAYS count on you to help us all work through these issues.

We're 533 since March. I've never had to open a case in the 3 years prior to our upgrade to 533. Now, I've started opening cases. Unfortunately, the tech support service hasn't lived up to expectations. It has taken 1 - 2 WEEKS to get an acknowledgment that the issues I have submitted have been duplicated by tech support. Do they REALLY think I'm making this stuff up?

Here's my most recent problems using MRE Report Assistant in 533:

1. Can't use an ampervariable in a DEFINE or COMPUTE. Returns FOC295 A VALUE IS MISSING FOR ampervariable. EXAMPLE CAR DEFINE:
EFFICIENCY/A10 = IF MPG GE 'AMPERentermpg' THEN 'EFFICIENT' ELSE 'NOT';
This doesn't work anymore. You can hardcode a constant value in place of the ampervariable and then do an EDIT SOURCE and change the constant to an ampervariable to get the .fex to run correctly. You just can't go back into the DEFINE or COMPUTE function in the MRE. The "FIX" for this is to turn off the DEFINE and COMPUTE validation in the HTMLToolConfig java source. It's not much of a fix, as it just turns off the execution of a subroutine that doesn't work, but, oh well, it saves our users from the EDIT SOURCE solution.

2. MRE Report Assistant, Conditional Styling on a numeric COMPUTEd field generates different styling than the same condition on an IDENTICAL (definition and value) DEFINEd field. All conditional styling VALUEs on COMPUTEd fields become enclosed in single quotes in the .fex. You can EDIT SOURCE and remove the single quotes from the VALUE to fix the problem. Additionally, if you EDIT a conditional styling on a numeric DEFINEd field, it's value also becomes enclosed in single quotes in the .fex. So a Styling on a DEFINEd field that WAS correct will break after an edit. After waiting two weeks, the Tech Support response was, "duplicated the problem. Submitted to programming. Fixed in 7.1".

I know these issues are trivial compared to blowing up an entire app, but maybe they will help someone else who is experiencing them. I thought it was just me when I couldn't get my DM stuff to work the way I thought it should.

I would like to know why anyone is considering an upgrade to 5.3.4? Why aren't you moving to the "latest/greatest" 7.1?????

Thanks to all for all of the help and tips I have gotten just by looking at these posts. And, Susannah, I hope we can all be there for you just as you have been for so many of us.

Regards,
Deb J.

Well 7.1 has so many new things...it scares me to jump into that right away. I'd like to wait a bit to all the bugs are worked out. Look at the problems with 533 and 534....imagine 7.1!

hi debbie!
yes they really think we're making this stuff up!
I've demo'd this insidious looping problem for CSS...and ...it seems these folks don't talk to each other, because they're still unaware of it. How this stuff passes QC is amazing to me. I'm told 534 won't be out for another week, but Prairie has cleverly been able to get it already.
As for 7 , it says right there in the newfeatures manual that they no longer support ISAPI. i just laughed and threw it away.. My site depends on isapi for the cool excel integration, so we don't use servlet. And then there's the "dot one" syndrome, never upgrade to anything "dot one".

Hmmmm sounds like we are Guenea Pigs.

quote:

...you can no longer use GOTO labels that are compound names
-GOTO DO&MYPARM ;
works but the target
-DO&MYPARM
isn't recongized.
doesn't work in 533, works fine in 52n.

Some thoughts, after reading Ben's response.

MR is a bit of a mystery. I have yet to see an adequate spec explaining just how MR transforms the fex before shipment to EDA (WFRS for the young'uns). Here's my hunch as to what changed:

In 5.2 MR would substitute for references to arguments received with the url, but in the 533 rewrite no longer does so.

Thus, given a fex with
-GOTO DO&MYPARM
-DOTHIS ...
-DOTHAT ...
-DO&PARM

called with MYPARM=some value, the adhoc fex shipped to EDA would have that value ...
-GOTO DOxxxx
-DOTHIS ...
-DOTHAT ...
-DOTHIS
(where xxxx is the value you provided for &MYPARM), with nary an ampersand in sight.

If &MYPARM = "THIS", MR emits
-GOTO DOTHIS
-DOTHIS ...
-DOTHAT ...
-DOTHIS
(and would branch to the first label);

if it's OTHER, MR emits:

-GOTO DOOTHER
-DOTHIS ...
-DOTHAT ...
-DOOTHER

So MR's "&" label in effect serves as a default, without need to list the labels in an IF THAN ELSE construct. (Neat.)

In 53, without the substitution, MR emits:
-SET &MYPARM=xxxx;
-GOTO DO&MYPARM
-DOTHIS ...
-DOTHAT ...
-DO&PARM

which works as intended when xxxx matches one of the static labels, but otherwise dies -- because EDA does not substitute &var references in a label before deciding whether it matches the GOTO. Never did.

Make sense?

We have recently upgraded from 527 to 533, and so far we've had no serious issues that we couldn't take care of or work around.

We are using neither Report Caster nor Managed Reporting. Does that mean that we should be immune from these problems, or are we equally at risk?

Robin

We've recently just upgraded and have come across a character limitation where 2000 characters in a field was accepted before and now for some reason it cuts off and essentially omits everything in the field after 1100 characters when outputting to PDF. VERY WEIRD. We opened a case and were told that ibi had no limitations, so they are looking into it. It works when outputting to Excel or HTML, but not PDF. I had not encountered this in previous versions...

That's the only major issue we have come across, and let's hope that is the last. We are testing 534 to see if that can resolve the issue and so far that doesn't see to help either.

Good luck to all.

Here's another problem we had in 533.

We couldn't create an ALERT from the MRE Alert Wizard because there was no SELECTION tab presented. It's kind of hard to create an ALERT on a condition if you can't create a WHERE clause. You could, however, create a Report Heading because that Tab was presented. Report Headings aren't very useful in an Alert!

Tech Support provided a solution that involves editing the alert wizard's java source to change
hideTab('showwhereTab') to
hideTab('showHeadingsTab').

We were also having trouble scheduling the Alert. I thought I had the reason pinned down, but I can't duplicate it (unfix it), now that it's fixed. It could have been a fluke, but being a programmer, I don't really believe in "flukes". To me, there always has to be a repeatable reason for a problem. I'm still watching it. . .

We are running into similar problems with confirming that an upgrade from 5.2.7 to 5.3.3 is justified.


We commented out -SET &ECHO=ALL; and the infinite loops disappeared. However, &variable errors are appearing and we cannot detect where the problem lies.

A case has been opened with IBI. In case somebody in the FOCUS nation has had this problem pleaase help us out.

Whoa thanks for the heads up Susannah! We are about to start testing 5.3 and we currently use every one of the techniques that you are having problems with. I wonder how it will go....

Jodye, wait for 534. it was due out last week.
There's so much wrong with 533 there is really no reason at all to test it. I'ld suggest.

In developing WebFOCUS PMF we hit the same issue in 5.3.3.

The -SET ECHO=ALL looping issue is caused by a bug, a buffer issue, in the 5.3.3 servlet. It happens when the comments buffer runs over 32K.

There is a patch available for this bug. Please don't redesign your code! Instead, contact IB tech support and install a patch to your WebFOCUS Client for this issue.

Hope this helps

bob, for the three thousandth time, the looping is far more insidious than echo. we've demo'd that for you people. do you guys talk to each other???? and the patch doesn't do squat!