If I run the following piece of code I get 1 then 2 as a result for the value contained within CR.

5 line code snippet

-DEFAULTS CR=1
-TYPE &CR

-DEFAULTS CR=2
-TYPE &CR

I was always taught that if a value had been assigned to a variable then a -DEFAULTS would be ignored.

Clearly it has been assigned by the first -DEFAULT rather than a -SET command, but I am investigating a saved parameter report that does not work properly and the mechanism of a saved parameter report is to create a dummy fex with the values saved in -DEFAULT statements with the .fex you are saving the parameters for as a -INCLUDE. If the -INCLUDE contains defaults itself then this will override early defaults.

Could users with version of wf other than mine 762 please test this 5 line code snippet and report back to see if this is a version specific bug.

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

Tom

Thanks for your reply.

Have a look at this saved parameters report.

-IF &TITLE.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &TITLE=R1376 Emergent & Additional VO Work;
-IF &REPORT.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &REPORT=4;
-IF &CR.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &CR=12489;
-IF &CRTYPE.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &CRTYPE=Activity;
-IF &LABOUR_DATE.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_DATE=TODAY;
-IF &LABOUR_OVERHEAD.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_OVERHEAD=0;
-IF &CONTRACT.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &CONTRACT=7.29;
-IF &LABOUR_WARRANTY_PERCENT.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_WARRANTY_PERCENT=0.00;
-IF &LABOUR_FLAT_RATE.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_FLAT_RATE=31.96;
-IF &CONMAN.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &CONMAN=Adrian Michie: BVT Contracts Manager;
-IF &CONTYPE.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &CONTYPE=M O D;
-IF &RFS_DATE.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &RFS_DATE=17/10/2008;
-IF &DAYS.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &DAYS=0;
-IF &LABOUR_General_Engineering.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_General_Engineering=0.00;
-IF &LABOUR_Logistics.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_Logistics=0.00;
-IF &LABOUR_Proj_Mgmt.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_Proj_Mgmt=0.00;
-IF &LABOUR_RN.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_RN=0.00;
-IF &LABOUR_Technical_Services.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_Technical_Services=0.00;
-IF &LABOUR_Waterfront.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &LABOUR_Waterfront=0.00;
-IF &ZEROPRICE.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &ZEROPRICE=No;
-IF &VIC_COMP_DATE.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &VIC_COMP_DATE=TBC;
-INCFEX
-INCLUDE app/r1376_emergent_and_additional_vo_work.fex

If the first defined defaults does not take precedence then how can the saved parameter report be guaranteed to work if, for example, R1376 has a defaults statement of its own.

btw the fact that the proc is -INCLUDED makes no difference.

ie if you have

-*proc 1
-DEFAULTS CR=1
-TYPE &CR
-INCLUDE PROC2

-* proc 2
-DEFAULTS CR=2
-TYPE &CR

still gives you 1 followed by 2.

Does anyone else have problems with saved parameter reports?

Amper vars have a values and a state indicator. They have two possible states -- call them preliminary and confirmed.

-DEFAULT confers only an preliminary value, which is overridden by execution of a subsequent -DEFAULT -- i.e., the last DEFAULT wins.

-SET (and EX parameters) confer a confirmed value, which is immune from subsequent -DEFAULT statements.

For both states, .EXISTS is 1.

The state attribute applies to globals as well as locals, and is preserved across -RUN's:

-SET ECHO=ALL;
-DEFAULT &&FOO=ONE
-? &&FOO
-RUN
-DEFAULT &&FOO=TWO
-? &&FOO

yields:

 -DEFAULT &&FOO=ONE
 CURRENTLY DEFINED & VARIABLES STARTING WITH '&FOO':
 &&FOO         = ONE
 -? &&FOO
 -RUN
 -DEFAULT &&FOO=TWO
 CURRENTLY DEFINED & VARIABLES STARTING WITH '&FOO':
 &&FOO         = TWO
 -? &&FOO

Jack

Thanks for your reply.

Are you responding definitively on behalf of a known IBI undocumented feature or on the basis of your experience.

What you are saying would suggest that the saved parameter screens will NEVER work on its own (unless the procedure has no defaults), but only if you use it as a template in the amend saved values option.

Certainly during amper autoprompting with -DEFAULTS gives the opposite result in that it is the FIRST amper variable encountered whose value is taken and displayed in the text box.

eg this results in a prompt of 1

-DEFAULTS CR=1
-TYPE &CR

-DEFAULTS CR=2
-TYPE &CR

-SET &DUMMY = &UNKNOWN.Other Variable. ;

John,

Remember, the saved parameter logic is not there to provide actual default values for the parameter, it is only there for the autoprompt feature. This thing only reads the procedure, does not execute it, nor follows the logic. And that way it finds the latest used values (the -defaults) for the used parameters.
So forget whatever is in the saved parameter logic, it is not meant to be executed at all.

quote:

Are you responding definitively on behalf of a known IBI undocumented feature or on the basis of your experience.

I'm sure I saw that in writing once upon a time, but don't recall where. Might have been a Greg Dorman article in the Systems Journal.

While the behavior (last DEFAULT wins, absent SET) may not be documented, I cannot see IBI changing it.

I have created a small peice of code to replace -DEFAULT, more for the issue of -DEFAULT not working for -INCLUDE more than 2 levels down.

-SET &TEMP_VAR = IF &AmpVAR.EXISTS EQ 1 THEN '&|AmpVAR' ELSE '''DefVal''' ;
-SET &AmpVAR = &TEMP_VAR.EVAL ;

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

John,

It is also interesting to see that the documented syntax is -DEFAULT (without the S) or at least in the DS help files it is. Having been bitten on using undocumented "loop holes" when code tightening is introduced, I would advise against using -DEFAULTS and change your existing fexes to have -DEFAULT instead.

On the subject of -DEFAULT and to quote the DS help files (again) -

quote:

You can override values set with -DEFAULT by supplying new values when you call the WebFOCUS scripts, or by issuing -SET after -DEFAULT.

In the case of a single fex (e.g. not calling it and supplying values), this seems a little ambiguous as it could read either way - i.e. a DEFAULT value only gets overriden by using -SET or a subsequent reassignment (either -SET or -DEFAULT) will cause the fex to replace the previous value (unless a -DEFAULT follows a -SET where it will retain the value from -SET obviously).

I've always understood it to be the latter explanation, that in the case of no -SET, the value used is the last -DEFAULT value issued before a -RUN.

T

Tony


-DEFAULT or -DEFAULTS

It depends where you look. In most EDA/Iway documents and Mainframe FOCUS it's -DEFAULTS in WebFOCUS it's usually -DEFAULT.

Nothing like consistency.

Command:	-DEFAULTS
Syntax:	-DEFAULTS &[&]name=value [...] where: &name Is a name of a variable. value Is the default value assigned to the variable.
Function:	-DEFAULTS supplies an initial (default) value for a variable that had no value before the command was processed. Override values set with -DEFAULTS by supplying new values: On the function call EDARPC. On the command line EXEC. With the command -SET subsequent to the command -DEFAULTS. By supplying values to variables in a stored procedure, -DEFAULTS helps ensure that it runs correctly.

This message has been edited. Last edited by: <JG>,

In the Systems Journal article to which I referred, Greg Dorman explained (inter alia) how -RUN operates. As I recall, it went as follows:

When the interpretation of a Focexec resumes at the line following -RUN, it is a fresh execution of the program. To allow for this, -RUN saves the state (before handing over control for execution of the stacked FOCUS commands), and the new execution re-establish the state based on that information. The state information is (or was back then) appended to FOCSTACK. (You could see that by setting FOCSTACK=0, forcing the entire content of FOCSTACK into a disk file.) For each amper variable, the saved information includes the var's name, length, value, and state (meaning whether it was established by -SET, or only by -DEFAULT).


I don't think the article explicitly covered what happens when a second -DEFAULT is encounted for the same variable -- but if you think about it, if the first -DEFAULT wins it would be irrelevent whether a previous value was established via -DEFAULT or -SET. So the inclusion of that bit of state info in the save and restore reflects the behavior of 'last -Default wins' that we see in the Focus and WebFocus products today.

I would not consider that article to be binding documentation of product behavior, and I am not aware that this particular aspect of Dialog Manager behavior (last DEFAULT wins, absent SET) appears in any 'ex cathedra' documentation. But operation of untold applications (undoubtably including some provided by IBI) would be sideswiped by deviation from that model, so I cannot see IBI changing it.

quote:

Originally posted by Waz:
. . . the issue of -DEFAULT not working for -INCLUDE more than 2 levels down.

I haven't come across that. Do you mean a var established by a -DEFAULT appearing earlier in the outermost fex of the nest is invisible to the innermost -- or one established by a -DEFAULT in the inner is lost when control returns to the outer?

Have a look at this Symptom/Problem/Solution, 2nd -DEFAULT in -INCLUDE overrides 1st -DEFAULT in Parent .

As for -DEFAULT and -DEFAULTS, there is also a -DEFAULTH, which is supposed to not effect autoprompt.

All three work the same way, the second override the first.

What I see there is a statement that a second -DEFAULT value (which happens to reside in the Included file) overrides the first; nothing new there, other than confirmation of the behavior we have observed.

I'm still puzzled -- what is "not working for -INCLUDE more than 2 levels down" -- can you provide an example?

Jack, The issue I have, is exactly what was in the Symptom/Problem/Solution, I only experiences it with the second level include. i.e. -INCLUDE in a -INCLUDE in an EX.

To solve the problem with -DEFAULT in the -INCLUDE file I did away with the -DEFAULT and used the code above.

Waz --

I was thrown off by the wording: "the issue of -DEFAULT not working for -INCLUDE more than 2 levels down."


To supply a default value in the outer fex and make it behave like a -SET, I just add a set to itself after the default:

-* FEX1.FEX
-DEFAULT &FOO='BAR';
-SET &FOO=&FOO;
-INCLUDE FEX2

If &FOO was set as an incoming parameter, the parameter value acts like a -SET, so the -DEFAULT is ignored; and the -SET leaves the parameter value intact.

If no '-SET' (or equivalent) has yet occured, the outer fex's default will create the variable with a tentative value, and then the -SET will promote the default value, immunizing it from subsequent defaults.


That's what the Symptom/Solution page meant by "use -SET".

Waz

To deal with your issue - it looks as though IBI have fixed this for 762.

-* one.fex 
-DEFAULTS CR=1
-TYPE &CR
-INCLUDE TWO
-TYPE one &CR

-* two.fex 
-DEFAULTS CR=2
-TYPE &CR
-INCLUDE THREE
-TYPE two &CR

-* three.fex
-DEFAULTS CR=3
-TYPE &CR
-INCLUDE FOUR
-TYPE three &CR

-* four.fex
-DEFAULTS CR=4
-TYPE four &CR

Produces

1
2
3
four 4
three 4
two 4
one 4

Which is what we expect according to our rules of last default wins the war of defaults.

GamP

quote:

Remember, the saved parameter logic is not there to provide actual default values for the parameter, it is only there for the autoprompt feature. This thing only reads the procedure, does not execute it, nor follows the logic. And that way it finds the latest used values (the -defaults) for the used parameters.
So forget whatever is in the saved parameter logic, it is not meant to be executed at all.

If you follow this example you will see that the saved parameter code does get executed as a normal focexec.

Create this in MRE

-* test.fex
-DEFAULTS CR=1
-TYPE &CR

From within the BID Dashboard/Reporting Portal...

1. Run test - it will amper autoprompt and enter the value 2 and then run the report and it will correctly display 2.

2. Now save the parameter as CR2 test. Here is the fex created.

-IF &CR.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &CR=2;
-INCFEX
-INCLUDE app/test.fex

3. Now locate the saved parameter report in
tree - My Reports - Saved Parameter Reports

Double click this to run directly and you will avoid being amper auto prompted and the value displayed will be the wrong answer of 1.

OR

Right click and select Run and you get the same result.

4. If you right click and selct 'Edit Parameters', this time you are auto prompted and the report thus will have the correct value.

It seems from this example that the designer of saved parameter reports realised that in autoprompting that first defined wins and he assumed that in the execution phase the same rules applied but as we have confirmed it is last wins out!

What the designer of Saved Parameter reports should have coded as suggested by J.Gross et al is this.

-IF &CR.EXIST EQ 1 THEN GOTO INCFEX;
-DEFAULTS &CR=2;
-INCFEX
-SET &CR = &CR ;

-INCLUDE app/test.fex

In fact this code is simpler than the original and will always work and is what it should be - I shall raise this as a fix request.

-DEFAULTS &CR=2;
-SET &CR = &CR ;
-INCLUDE app/test.fex

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

Jack, that may be true for fex's that set the environment, but my includes are called from many places and the variables may have been -SET or -DETAULTed or not at all.

The code I posted seems to handle all cases.

John, this is not an issue for me, just posting some code that may help someone.

Is this the spanish Inquisition ?

One more turn of the screw:

Both approaches have their place, when supplying a -DEFAULT value in a fex that may get invoked (as parent or child or both) in an -INCLUDE structure, where you are not in charge of the other (including or included) fexes. It depends on the objectives.

(I've homogenized the names for ease of comparison.)

If you want to immunize your default from any later defaults, simply adding a "-SET to itself" does the trick (without need for a second amper var or a label and goto).

-DEFAULT &var=value
-SET &var=&var;

If you want to preserve any default value already acquired, you need something more complex

-- either avoid executing it when the var already has a value:

-IF &var.EXISTS GOTO continue;
-DEFAULT &var=value
-continue

-- or adjust the value assigned in your -DEFAULT, as Waz suggested:

-SET &temp = IF &var.EXISTS THEN '&' | 'var' ELSE '''value''' ;
-DEFAULT &var = &temp.EVAL

And if you need to do both (respect prior Default and immunize from later Defaults), change that DEFAULT to SET (as in Waz's posted code):

-SET &temp = IF &var.EXISTS THEN '&' | 'var' ELSE '''value''' ;
-SET &var = &temp.EVAL;

I have raised this as case 50192507.