WebFOCUS 5.3.4 is now available for download at techsupport.ibi.com. Anyone encountering a Looping problem in WebFOCUS 5.3.n when used with ECHO should apply the 5.3.4 Service Pack.
Hear ya there... sorry, guess I must behind the times on the latest knowledge about this issue. They are telling me now also that 5.3.4 will fix this stuff.
I'm not in CSS or BIPG operations but I do manage development of a WebFOCUS app and I get hit by issues like this just as our customers do, so just wanted to help - but apparently I wasn't that helpful this time! Sorry about that.
The fact that I develop WebFOCUS apps and that I'm on the IBI side, means I learn things that might help customers... hence my desire to share what I know.
After seeing your recent post and hearing your frustration, to make sure people knew how you felt, I checked in with BIPG operations management and CSS. They are already mobilized to help you guys out with the issues you're hitting. I should step out of the way.
You're in the hands of people I trust to help my team as well, and I know they will do right by you.
Just an FYI, the testing group finished testing 5.3.4 and it is being moved into production this evening...hope all goes well.
There were a few issues...but it solved several outstanding issues with 5.3.2, so we are moving forward.
Prairie, can you ask what the issues were?
I just spoke to the testing guy...and he said the issues they had, that they thought were problems...all turned out to be...issues with 5.3.2...that we had coded around...that no longer worked, because stuff was fixed. Hope that makes sense. They think this version is pretty clean... We are not upgrading to the New Graph Engine, and I'm told this has something to do with the version of Java some people have on their machines. So sounds like you should give it a try...and maybe you won't be so Focus Sad.
ah. good. we aren't using the new graph engine either; same reason. although one of the really good css reps has given me some detailed info on that...when i upgrade, i'll give it a try and let you know.
Not sure whether I should ask this , but has anyone looked into upgrading to 7.1 yet?
My client is currently on 5.3.2 and apart from some annoying limitations such as INCLUDEs via the GUI, and moving comments when opening a report via the GUI, they don't have too much of a problem. But then I suppose GUI "developing" should be more stable (give me an editor anytime).
Main areas I'm interested in is the BID/MRE using AD authentication and authorisation.
All comments would be appreciated.
I saw no mention of help-on-the-way for the original -GOTO label burning issue (use of "-DO&PARAM" as the label). Has IBI promised any relief on that front in 5.3.4 or 7.1?
This might be a bit late and not a big deal at this point... but I just saw this and had to reply. Susannah is correct. This does in fact work... we do it all the time with no problems at all. If you set some ampers in FEX1 and then EX FEX1 from FEX2, FEX2 will indeed see the ampers. I am 100% certain of this. The scope of &VAR is NOT only in one focexec. I am talking about 5.2 at least.
we're going to test 534 next week.
If its still busted...we're hugely screwed...and it will prevent us from using XFOCUS db's.
I have found that changing EX FEX to EXEC FEX allows me to put parameters on the same line as the fexname...i used to have to accomplish that by putting a blank space in front of the EX. (and this EXEC statement also makes a fex in domain b accessible to domain a..which is semi-nifty)
however still, no pass thru of &vars.
The suggestion here was to make them all && vars...
like that's going to happen...gee rewrite 1100 fexes...boy will that ever give cognos a strong foothold.
I opened a case with css...and they were totally 'unclear on the concept'
I was a little surprised by this quote from Susannah.
In all my years of FOCUS work, I never expected to have available any amper variables inside a fex that is EXecuted from another one. I would always pass them via the EX command.
I just tested the existence of variables:
Windows WF 5.3.2
MRE : variables not available
Self Serve: variables not available
AIX WF 5.2.3
MRE : variables are available !!!
Self Serve: variables not available
My test programs:
-* Program: testa1<br /><br />-SET &AVAR1 = 'testing 1';<br />-SET &AVAR2 = 'testing 2';<br /><br />-TYPE ----------------------------------<br />-TYPE Program: testa1<br />-TYPE ----------------------------------<br /><br />-? &<br /><br />EX TESTA2testa2.fex
-* Program: testa2<br /><br />-SET &AVAR3 = 'testing 3';<br />-SET &AVAR4 = 'testing 4';<br /><br />-TYPE ----------------------------------<br />-TYPE Program: testa2<br />-TYPE ----------------------------------<br /><br />-? &
Francis, i dont understand your disgruntlement with my post. your test just proved my point. in 52x, &vars are passed thru, in both mre and ss. My site has both, and has had both for, oh, all of living memory.
In 533...they're not available at all. unless we make them all &&, which is just not going to happen, or use -include which means rewrite and test absolutely everything.
Susannah, no disgruntlement intended. I just wanted to say I always thought you could not access variables created in the calling program from the called program. In 5.3.2, which I feel is the most stable environment, it is not possible. In my tests it appears it's only possible in MRE 5.2.3.
Perhaps we could compile a list of environments it does work in.
ah! now i understand.
yes, it the EX method is a clean way to exec embedded code, and to pass &vars, for a bunch of reasons...one being its self contained, no statement label conflict.
so you can repeate the execution of a given embedded fex a buncha times...and keep track of stuff;
EXEC FEXA MYPARM='val1'
-SET &RECSONE = &RECORDS;
EXEC FEXA MYPARM='val2'
-SET &RECSTWO = &RECORDS;
lots of other reasons as well, like less echo clutter. and , most serendipitously,
it works in MRE when FEXA resides in some other domain...like a set of &vars that set color pallettes..
-INCLUDE COLORS doesn't work in MRE
EXEC COLORS does work (in 52)
but it won't pass the variables unless they're &&. (in 53)
and...and this is a big problem
EXEC fexname DOESN'T WORK AT ALL if the fexname contains a REMOTE server call, and therefore has MRNOEDIT in it.
Zillion reasons why this is cool. Jodye i'm sure has a buncha different ones.
I'm so confused! LOL
We just installed 534 and I am doing some initial testing. As I stated above we are used to referencing fexes with EX fexname. And we can always use ampers in the called fex all over the place. Also we never refer to the amper in the EX line.
Take this scenario... xxx.fex has one line in it
-SET &XXX='I AM IN XXX';
contents of YYY.fex:
We are used to this working. In my first test of 534 it did not work. (FOC295) A VALUE IS MISSING FOR: XXX.
If I change EX XXX to -INCLUDE XXX then it works and I can output the value of &XXX from inside YYY.
My question is this... can I do a find/replace of EX with -INCLUDE ? What exactly is the differene between the two of them?
are self-contained...they can be repeated in the same fex.
-INCLUDE fexname is NOT selfcontained...so if you include code with goto statement labels,
you can't use -INCLUDE to exec the same fex multiple times...
The self-contained fexes no longer pass any &vars out, which is just horrid.
Susannah and Jodye,
I have the feeling that IBI "tightened the code" to fix the situation where ampervars from executed focexecs were still available in the calling fex.
In 25+ years with FOCUS, I have never seen this allowed. If you wanted ampervars to be available to the calling program, you had to -INCLUDE the focexec in the calling program. Otherwise, you needed to use global ampervars.
Perhaps it has always been different on the PC. I've used mostly mainframe and midframe opsys.
It sure sounds like it is a real problem, though. It would be nice if you could get IBI to say that "code tightening" is what they did, not that it will help your situation.
but so far i can't get ibi to say anything that indicates they even acknowledge the situation.
my guess is it wasn't done on purpose...it just happened...my other guess is ... since they don't actually build customer systems with their code, there are lots of these things that just 'happen'... and 'tough, live with it' would be the response, pretty much what i got in the expert room. If it were conscious, then there would be a list somewhere... in the update memo...but not..I've tried to get Council to pay attn to the UC issues from 4 to 5 ... no impact.
It's pretty obvious that MRE was in effect converting EX to -INCLUDE (i.e., inserting the lines of the referenced MR fex into the host MR fex, and passing the result to EDA for execution.) That's why the caller and callee appeared to share local &vars: by the time it got to EDA it _was_ a single fex.
Per the feature announced in WebFocus Newletter, in 5.3.[something] they were going to leave the EX statement as an EX statement, and provide a temp copy of the called fex to EDA (this to ensure that error msgs quote a line number that bears some relationship to the original fex, remember?).
Well, 5.3.3 is that something. The unannounced side effect is that the two fexes no longer share a single &vars address space. Hence all (well most of) your tzuris.
If you have both available, turn on the save_fex trace to reveal exactly what fex code is passed to EDA. I'll bet a beer.
Perhaps 5.3.3 contains a setting (in MRE) for turning off the feature. That would make you whole.
Have a delightful weekend.
Francis really summed this up nicely.
MRE aside, the way FOCUS has always worked, is that the scope of an &variable is for a single procedure. The reason is, in case the called procedure uses the same variable names for a different purpose. When you return to the calling procedure, which value should you use? If you need to pass a variable to another procedure, you could place it on the EX line, change it to a global variable which is designed to keep variable values between procedures, or use a
-INCLUDE. What is being seen in 52x is a bug within MRE, that allowed a second procedure to 'see' the first procedures &variables. The reason this is occurring in 52x, is that on the WebFOCUS reporting server, procedure 2 was incorrectly being -INCLUDEd in to the first procedure.
Regards, Ben Naphtali
Strategic Support Manager
Business Intelligence Products Group
Lovely patting yourselves on the back, and who cares what happens to the customer. So typical.
EXEC isn't a solution...it doesn't allow execution of remote procedure calls.
Do you realize what you are saying? We (ie your customers) are using certain techniques that work perfectly in one version and then no longer work in a future version... and your only response is that it was due to a bug in the old version and never should have worked! Now that I am using 534, how can I be sure that some new feature that I use and that works 100% of the time, isn't actually a bug and will suddenly disappear in a future version?
We were told the same thing with 5.3.4...that now the code is right. Well the last place I worked had Focus Code from the 80's they were converting to WebFocus...guess there will be lot's of things that don't work anymore....fortunately for here...they've only had WebFocus a year...some of you may really be hurting.
Not a bug, Ben; simply undocumented behavior. It can't be a bug if there is no published spec for it to violate.
When MR transforms an EX or -INCLUDE statement, then they are MR directives, not Dialog Manager or Focus statements. IBI never published a decent chart of the waters -- how MR assembles and transforms the pieces for execution on EDA.
I see two parties at fault here:
(a) IBI, for habitually failing to publish adequate specs of the product's behavior. "It ain't finished till the paperwork is done" -- and in fact it shouldn't be built until the paperwork has been vetted by the user community.
(b) *US*, for allowing the vendor to get away with (a), and complacently building hordes of fexes exploiting undocumented behavior.
Point well taken. The reason I indicated it is a bug, since it goes against basic FOCUS behavior. EX as an MRE directive is different that EX on the server, but they should operate as similarly as possible. Within all WebFOCUS documentation, it is clearly stated the scope of variables and that one procedure cannot see another procedures variables.
I was just trying to explain the situation you are up against as best as possible. Why it previously occured, and how it currently works. The fact that EX Fexname within MRE in 52x allowed this behavior, is not consistent with other areas of the product.
We don't need any more apologias. We know what we're up against.
We need answers, work arounds, how do you expect us to handle everything the way we have ALWAYS handled it NOW. Some acknowldegment that you are causing huge problems. There is never any ack, just 'tough!'; Council and css both have deaf ears. QC says 'tough,your problem, talk to css'; We need help from other developers, who have figured out what to do now....
The way to do this would be with a -INCLUDE.
That will allow test2a to see test1a's variables.
That apparently, was a problem for you with labels, so can you show me two simple MRE focexecs that show that problem.
Regards, Ben Naphtali
I think Jack has given some user view of what happened in 5.2.x, and how it changed in 5.3.3. Let me give some internal views, to clarify what happened, and where it was documented (though not in as much detail and without the implications I would have liked).
In 5.2.x, When you ran a procedure from MRE, ALL the components were packed together as a single piece, which was sent to the server. This means that any procedures which were -INCLUDEd, or EXECed, were expanded out, and that single package was shipped. All D.M. variables were expanded on the client side, so a label containing an amper variable was seen, by the server, with the variable replaced with it's value (as Jack said).
This caused several problems:
1. line numbers of errors were wrong (error at line 60 of a 5 line fex?)
2. You only had a SINGLE environment, unlike self service apps, where an EXEC'd procedure starts a 'new' environment. This is why you could -SET a variable, and use it in an EXEC'd procedure; the server only saw a SINGLE procedure.
3. more was sent than necessary. Run a procedure (EXEC or -INCLUDE it) multiple times, and the procedure was sent multiple times.
4. Variables set in EDASPROF were invisible.
As a result, we changed what was done in 5.3.x, to match other Focus environments.
Each procedure which was EXEC'd or -INCLUDEd, was sent to the server separately, and then the calling procedure was sent, which then used the other procedures, as needed. This IMMEDIATELY solved issue 1 and 3, and caused the change you saw in point 2.
Changing any EXEC to -INCLUDE should restore the prior behavior, of being able to use variables -SET before the EXEC or -INCLUDE, and, since the procedure is now sent separately, the problem of -INCLUDING a procedure more than once, which previouisly caused duplicate labels, is avoided. You can neither branch INTO or OUT OF a -INCLUDEd procedure.
We ALSO let the server tell us which variables it DIDN'T know about, rather than trying to determine that on the client side. This allowed procedures to use variables initialized in the EDASPROF or user profiles, as well as recognize STATISTICAL variables that were added to the server, but not yet known to the client. This is why the label with an '&' variable no longer worked. The SERVER has NEVER recognized that (I checked servers back to 5.2.1), and we now use the server to process '&' variables. This solved point 4.
The documentation on this change in behavior, though not covering the above, was indicated as available on our web site, in the announcement letter for the release. You can find it on our TECHSUPPORT.IBI.COM site. Select 'publications', then 'search for documents', and, on the left, choose 'Release Notes', selecting 'WebFocus Release Notes'. It's under Upgrade Considerations for release 5.3, under MRE, in the section titled:
Internal Change When Executing Managed Reporting Procedures.
This is STILL one issue, which should be resolved shortly. When you EXEC a procedure, you CAN'T pass in parameters. This is being resolved by programming NOW.
Thanks for the clarification.
I'm curious - why was EX ever introduced as an MR directive, when (MR) -INCLUDE was already available?
We just up'd to 534. no better. actually worse.
looping still there. RA won't open..java applet won't run... etc... now a FOC1517 preceeds each and every fex....
some of you all had said that 532 was the most stable... any opinions??
|Powered by Social Strata||Page 1 2 3|