If a line requires a substitution of an empervariable set to FOC_NONE then that line is immediately abandoned and not put on the stack.

eg

-SET &COUNTRYSEL = 'FOC_NONE' ;
TABLE FILE CAR
PRINT COUNTRY
WHERE COUNTRY EQ '&COUNTRYSEL'
END

produces the usual 5 countries but put this code into TEST.FEX and from another FEX.

EX TEST

Will result in the FOC_NONE being tested for the country = FOC_NONE literal and the output is no countries at all.

I will raise a case but watch out for this as it had me pulling out the remaining stumps of my once proud head of hair...

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

hammo1j,

Just for kicks, add a HEADING to your focexec with the &variable in the HEADING. The line with the &variable disappears from the HEADING. I ran into this awhile back and decided not to leverage the FOC_NONE feature.

-SET &COUNTRYSEL = 'FOC_NONE' ;
TABLE FILE CAR
HEADING
"THERE SHOULD BE A LINE FOLLOWING THIS ONE BUT THERE ISN'T"
"THE COUNTRY SELECTED IS &COUNTRYSEL"
PRINT COUNTRY
WHERE COUNTRY EQ '&COUNTRYSEL'
END

Mickey

The FOC_NONE feature does not just apply to IF or WHERE tests but every PHYSICAL line passed to the stack.

It is very daunting at first but once you get used to it - it is fantastic.

Did exactly the same as you when my drills did not work but you have to use \ syntax in ss so that only the physical line gets removed.

VARWITHFOCNONE='&VARWITHFOCNONE' \

Honestly persist with it - it is a great feature.

Regards

John

john, buy me a vowel...
i don't understand what your solution is...
can you take Mickey's code example and implement your solution with it???
I'ld love to understand what you mean...
muchas g.
-s

John,

That is very interesting. I guess it has been so long since anyone has done an 'EX' with WebFOCUS, no one noticed the literal translation of FOC_NONE.

fyi, if you apply any parameter operator to your ampher variable that can be FOC_NONE, then you do not have to break the line in you stylesheet. The FOC_NONE will be passed properly to your drilldown request.

Examples:

VARWITHFOCNONE='&VARWITHFOCNONE.EVAL' 
VARWITHFOCNONE=&VARWITHFOCNONE.QUOTEDSTRING

Susannah,


What ham is saying (which is what we are all saying) is that the parser will remove any line of code from your focexec in which the FOC_NONE value appears for an &variable. Therefore any WHERE, IF, HEADING line or even a Stylesheet line will be completly removed from the code and executed as it if were never coded.

So if you had the following 2 lines in your focexec stylesheet, the first line would be removed if &CARVAR was equal to 'FOC_NONE'. this would then cause your focexec to bomb since the second line of code is incomplete without the first line.

TYPE=DATA, COLUMN=CAR, FOCEXEC=FEX002(COUNTRY=COUNTRY, CAR=&CARVAR MODEL=MODEL),
COLOR=NAVY, BACKCOLOR=YELLOW,$

To solve this problem ham is suggesting to code it this way:

TYPE=DATA, COLUMN=CAR,
FOCEXEC=FEX002(COUNTRY=COUNTRY \
CAR=&CARVAR \
MODEL=MODEL),
COLOR=NAVY, BACKCOLOR=YELLOW,$

If the CAR=&CARVAR gets removed the code will still work.

AH! light bulb. Thanks Mick.

But why does the line in question not get dropped in the parsing of the inner fex?

When passing a variable that can contain FOC_NONE to an EX, you must use the quoted string.

eg EX FEX2 COUNTRY=&COUNTRY.QUOTEDSTRING

That being said, I recently came across an issue where I was trying to call a server procedure while in MRE as follows.

-MRNOEDIT EX FEX2 COUNTRY=&COUNTRY.QUOTEDSTRING

The FOC_NONE was passed to FEX2, but the selection statement was still passed to the FOCSTACK causing the program to state that the field FOC_NONE did not exist.

This was resolved by changing it to a -INCLUDE rather than using EX.

For MRE, this was
-MRNOEDIT -INCLUDE FEX2

With the -INCLUDE, you no longer need to pass the variables as they are already present.

ah... i was just pondering the same question...wondering if it did or didn't.

This one raised as case 41502513

EXEC as opposed to EX does not work either.

john, as 'EX' is sort of an -INCLUDE
does FOC_NONE work in an -INCLUDE ?

If a line requires a substitution of an empervariable set to FOC_NONE then that line is immediately abandoned and not put on the stack.

eg if we put this into a focexec.

-SET &COUNTRYSEL = 'FOC_NONE' ;
TABLE FILE CAR
PRINT COUNTRY
WHERE COUNTRY EQ '&COUNTRYSEL'
END

produces the usual 5 countries but put this code into TEST.FEX and from another FEX.

EX TEST

Will result in the FOC_NONE being tested for the country = FOC_NONE literal and the output is no countries at all.

However

-INCLUDE TEST

works fine and produces the usual 5 countries of the 1970's.

Susannah

The distinction between EXEC and -include is that a new webfocus environment stack is created when you EXEC a fex but not when you -INCLUDE a fex.

This stack includes an entirely new area for amper variables and so when you EXEC a fex there is no access to the amper variables of the caller. Contrast this with when you -INCLUDE a fex where the amper variables are shared.

Ending the EXEC'ed .fex via eof or -EXIT, clears the stack and returns to the executor after the point where the EXEC took place. At this point the state of the caller's amper variables are restored.

The error in this case is that an old version of the dm parser is being called when a .fex is EXEC'ed. This is a case where all references have not been properly identified to be updated to the new. I am sure we have all made similar mistakes - I certainly have.

yup.
EX and -INCLUDE are s'posed to be the same, per ibi just yesterday
EXEC is s'posed to be self contained.
so, you're discovering that EX and -INCLUDe aren't exactly the same after all, that the FOC_NONE thing doesn't work?
I think i remember this very thing being a discussion at Fuse New England...

Running Mickey's example in Dev Studio 7.6.5

-- as an ad-hoc fex pasted directly to the command console, or referenced by -INCLUDE, the FOC_NONE is respected (five countries are returned, and the second heading line is suppressed).

-- but referenced in the comand console via EX or EXEC, the FOC_NONE is not respected (zero lines, and the second heading line is echoed).


It appears that the FOC_NONE feature is recognized only in the processing of adhoc code.

If programs coming from MR are presented as adhoc requests, then this all falls into place:

-INCLUDE and EX (in fexes stored in MR) are expanded inline by the client and submitted as adhocs, so FOC_NONE appearances are detected and cause line suppression.

But if the line with FOC_NONE is imbedded in a fex on the WF server, and referenced via EX or EXEC appearing outside the MR context (or via EXEC in an MR context), dialog manager treats it like any other 8-character string.


I experimented further to see whether the line is being suppressed just before DM would place it in the stack, or by some pre-processing applied to an adhoc's text before DM sees it. I broke the FOC_NONE into two DM vars:

-SET &F=FOC_;
-SET &N=NONE;
TABLE FILE CAR
HEADING
"THERE SHOULD BE A LINE FOLLOWING THIS ONE BUT THERE ISN'T"
"THE COUNTRY SELECTED IS &F&N"
PRINT COUNTRY
WHERE COUNTRY EQ '&F&N'
END

This produced zero lines when run adhoc. So it is clear to me that there is a transformation step applied to adhoc (including MR) requests, before DM receives the fex code, which can mentally compute that a single variable reference will resolve to FOC_NONE, but nothing beyond that.

quote:

-INCLUDE and EX (in fexes stored in MR) are expanded inline by the client and submitted as adhocs, so FOC_NONE appearances are detected and cause line suppression.

Jack, it's a nice theory but unfortunately the idea of inline expansion applying to both -INCLUDE and EX does not apply.

A child fex is invoked by 3 possible methods
It checks the existence of a variable in its parent caller, &PARVAR, to see if a new amper variable stack has been created.

-* File child.fex
-IF NOT &PARVAR.EXISTS THEN GOTO NO_PARVAR ;
-TYPE PARVAR HAS VALUE &PARVAR 
-NO_PARVAR
-IF &PARVAR.EXISTS THEN GOTO YES_PARVAR ;
-TYPE PARVAR DOES NOT EXIST
-YES_PARVAR

-INCLUDE

-* File parent_include.fex
-SET &PARVAR = 'HELLO' ;
-INCLUDE CHILD
-RUN

EX - runs mr version of fex if in mre

-* File parent_ex.fex
-SET &PARVAR = 'HELLO' ;
EX CHILD
-RUN

EXEC always runs application version of .fex

-* File parent_exec.fex
-SET &PARVAR = 'HELLO' ;
EXEC CHILD
-RUN

When we run each of the 3 parents on the application server only the -INCLUDE shows that PARVAR exists.

Similarly running the 3 in MRE produces the same results.

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

You are correct though that the client seems to have its own sort of dm handler which handles FOC_NONE.

Running the code pasted directly into the the window

-SET &COUNTRYSEL = 'FOC_NONE' ;
TABLE FILE CAR
PRINT COUNTRY
WHERE COUNTRY EQ '&COUNTRYSEL'
END

of the server console

http://servername:8121/webconsole?IBIF_app_override=&IBIS_page=PROCHOME

Produces no countries in the output.

The upshot is that the dm processor on the server needs to be updated in line with that on the client.

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

This begs the question as to whether the client sends the entire .fex to the server or does it have its own dm and send only stacked focexec lines.

eg if the fex passed to the client is

-SET &RUN = 2 ;
-IF &RUN NE 1 GOTO NO_RUN1 ;
TABLE FILE CAR 
PRINT COUNTRY 
END
-RUN
-NO_RUN1

-IF &RUN NE 2 GOTO NO_RUN2 ;
TABLE FILE CAR 
PRINT SEATS 
END
-RUN
-NO_RUN2

does the server only get

TABLE FILE CAR 
PRINT SEATS 
END

Perhaps an IB insider could enlighten us...

Client does not execute source code. At most it performs a static analysis.

For example, it would have no way to know how execution should proceed when it encounters
-IF &LINES EQ 0 THEN GOTO NONE;
since it cannot run FOCUS commands.

Client analyses the fex code (the content of IBIF_adhocfex in the selfservice context, perhaps a different entity but same idea in the MR context), and makes an educated guess as to whether referenced & vars will be defined, and what their value will be, to support a limited set of source-code modifications (e.g., expansion of MR include/ex references, autoprompting and attendant expansion/substitution, and apparently the foc_none line-deletions).


Yes, in this process you could say Client "stacks lines for later execution", but its output stream is a mixture of FOCUS code and Dialog Mgr directives -- a fullblown fex -- that needs to be parsed by dialog manager once it is opened by an agent on the WF Server ... as opposed to FOCSTACK, the outpt stream of the DM parser, whose content is treated strictly as FOCUS commands (i.e., "-" and "&" found in FOCSTACK have no special significance).


To resolve certain autoprompt constructs, like
WHERE STATE EQ &STATE.(OR(FIND STATE IN CENTORD)).2-3 letters for US State.
client apparently can shoot a quick request to Server, to provide the necessary list for building a

<select>

structure. After the user responds to the autoprompt page, Client resumes its duties, expanding the WHERE statement and passing the resolved fex on to the Server. -- But Client has no ability to execute your fex's lines of Focus code, so it is clueless about the change of state that each -RUN will bring.

There is a parameter that is needed on the EX statement that makes FOC_NONE kick in.
EX afex WFDESCRIBE=RUN
If you want the autoprompt facaility to kick in (through the servlet client) use WFDESCRIBE=XMLRUN and then any unresolved AMPVARs will be prompted for.

Thank you Brian - I have tried this and it works.

Once again thank you Jack

For taking time to answer regarding how the client and server co-operate. I did further tests and can confirm that the client does send the .fex with dm and all to the server and so my above idea of using wf server to process the stack of the client (although an attractive theory) is wrong.

It seems that &wfdescribe is set in the URL (via translation of HTML vars to amper vars) when you invoke the server via the client, but when you invoke the server through the server this is not normally set because the EX and EXEC create a new amper variable stack as explained above.

If you wish to EXEC something then you need to be aware that amper variables set by the client in the .wfs files and in the URL will not be available and will have to be explicitly passed.

It's taken a lot of work but it's good to get to the bottom of this.

Thank-you all

John

Have you tried setting the variables globally and then reading them locally. As in -SET &&VAR=&var and then using &&VAR in the exec'd procedure instead? A lot of times the &var values are lost between procedures depnding on how you've used EX, EX, -INCLUDE, whereas &&var values are not. Hey - I learned (or at least understand something better that I had previously learned) from SUMMIT - more good stuff to come!!

Darin

That is another way of doing things. &X and &&X are two different variables and can co-exist.

Thus
-SET &&WFDESCRIBE='RUN' ;

will not globally set FOC_NONE working throughout the system.

but as you say you could do

-SET &WFDESCRIBE = &&WFDESCRIBE ;

Nice thought.

John

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

WFDESCRIBE is not really an ampervar ... it is truely an argument that the EX processor sees and then will scan the fex for unresolved ampvars.

Setting &WFDESCRIBE does not kick the procesing in (the way &ECHO does).

Brian --

Interesting. That raises two questions:

1. IBIF_wfdescribe controls both autoprompt and FOC_NONE processing behavior. Does the WFDESCRIBE argument override the client setting with respect to both behaviors, or just autoprompt.

2. After user responds to the autoprompt page for the executed fex, how does execution of the called fex resume on the server? -- If on the same connection, you've got persistence across a user interaction, which Reporting is supposed to avoid. If a new connection, how does it re-establish context (e.g., HOLDs created earlier by the calling fex, and return-point and &vars in the pending outer fex)?

Will IBI ever fix this?

I am having to re-write my fexes to overcome this issue. It shouldn't be this hard.

i remember some issues w/ FOC_NONE...
but my memory is heat-fogged...
can you explain your sitch, Gary?

Here is the technique of passing a variable with a possible FOC_NONE value:

Calling fex:
-DEFAULT &COUNTRYSEL = 'FOC_NONE' ;
EX CarRepor WFDESCRIBE=RUN, COUNTRYSEL=&COUNTRYSEL.QUOTEDSTRING

Called Fex:
-DEFAULT &COUNTRYSEL = 'FOC_NONE' ;
TABLE FILE CAR
HEADING
"THERE SHOULD BE A LINE FOLLOWING THIS ONE BUT THERE ISN'T"
"THE COUNTRY SELECTED IS &COUNTRYSEL"
PRINT COUNTRY
WHERE COUNTRY EQ '&COUNTRYSEL'
END