Someone may find this interesting or (with any luck) have similar requirements and have already found the answer to my question. So this is a case I just submitted.
--8<--
We have just upgraded our development server from 7.6.4 to 7.6.9. Since that time very few of the many reports on that system ran correctly. All of them autoprompted for ampers that were never an issue before.

I have investigated and I believe I have identified the source of the problem. We make extensive use of -INCLUDE files. In many cases the files to be included are included via a loop iterating over a fakearray like so:

-* This bit is set up prior to the include.
-SET &INCLUDEFILES0=3;
-SET &INCLUDEFILES1='firstincfile';
-SET &INCLUDEFILES2='secondincfile';
-SET &INCLUDEFILES3='thirdincfile';
-*
-* this next bit is -MRNOEDIT -INCLUDED as part of a larger file.
-***********************************************
-* Loop through and include required files.
-***********************************************
-REPEAT INCLOOPEND FOR &INCLOOP FROM 1 TO &INCLUDEFILES0;
-TYPE -MRNOEDIT -INCLUDE include_files/&INCLUDEFILES&INCLOOP.EVAL.EVAL.fex
-INCLOOPEND

If the above code is run in isolation it behaves as follows:
On 7.6.9 it autoprompts for INCLOOP INCLUDEFILES0; and INCLUDEFILES
On 7.6.4 it autoprompts for INCLUDEFILES

However the big difference comes from its behavior when this code itself is executed as part of an -INCLUDE. On 7.6.4 it appears that the "error" of unresolved ampers is reported but ignored. Execution continues unaffected. On 7.6.9 it throws up an autoprompt.
So it appears that there are a few things with that snippet that were problematical but invisible to us on 7.6.4. I removed the redundant .EVAL (which was not affecting execution), the ampersand on the INCLOOP variable and the trailing semicolon on the -REPEAT statement. That just left me with the prompt for INCLUDEFILES. Of course on 7.6.9 this is still enough to throw up the autoprompt page. To get rid of that I tried various things to no avail.

Then out of frustration I -SET INCLUDEFILES =''; and (tada) it worked! Well "worked" as in no longer prompted me. I would rather not have to skirt around the problem like this so I really need to know the correct "future-proof" way of accomplishing this type of fakearray/loop. When it is time to install 7.7.x I do not want to spend hours jumping through hoops because more "code tightening" means I have to adhere to syntax that is so obscure it might as well be written in sanskrit

So please let us know how this is supposed to be done!

While looking for a solution I foud the following behavior that may interest you and may shed some light on my issue. Even if it doesn't is does seem rather odd and bears an explanation.


-*Works on 7.6.4
-* Prompts for FAKEARRAY0 on 7.6.9

-SET FAKEARRAY0=3;
-REPEAT ALOOP FOR ARRAYLOOP FROM 1 TO &FAKEARRAY0
-SET &FAKEARRAY.&ARRAYLOOP = '[ &ARRAYLOOP.EVAL ]';
-ALOOP

-REPEAT BLOOP FOR ARRAYLOOP2 FROM 1 TO &FAKEARRAY0
-TYPE &FAKEARRAY.&ARRAYLOOP2
-BLOOP

-* When you look at the amper dump you'll see FAKEARRAY0 is set to 3 regardless of what you entered in autoprompt.
-* Obviously it's attempting to resolve it prior to the -SET.

-? &
-EXIT
-***************************************************************************************
-***************************************************************************************
-***************************************************************************************


-* Works on 7.6.9
-* Autoprompts for FAKEARRAY on 7.6.4

-SET &FAKEARRAY0=3;
-SET &FAKEARRAY1='[ A ]';
-SET &FAKEARRAY2='[ B ]';
-SET &FAKEARRAY3='[ C ]';

-REPEAT CLOOP FOR ARRAYLOOP FROM 1 TO &FAKEARRAY0
-TYPE &FAKEARRAY.&ARRAYLOOP
-CLOOP

-* When you look at the amper dump you'll see FAKEARRAY is set to whatever you entered in autoprompt

-? &
-EXIT

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

I think that the "autoprompted for ampers that were never an issue before" is due to an admin setting... Check out "Parameter Prompting" / "IBIF_wfdescribe" in the "WebFOCUS Admin Console"... There's probably other stuff that got configured differently in the upgrade.

I would tend to agree with Doug,
It sounds like you have just forgotten to migrate your configuration.

When you go into the WF Administration Console for the first time it should ask if
you want to migrate, if you did an upgrade and not a clean install.

Thanks guys, I understand what you mean. However we always have the autoprompt feature turned on. It's just that before the upgrade our code wasn't causing any unresloved amper problems, and afterwards it did. Once I fixed the -REPEAT loop syntax, some of the ampers prompted for went away, but I still needed to set a dummy unused amper because the preprocessor gets confused by derived amper var names. I think I understand why it's doing what it's doing. It just seems pretty dumb behavior that's all. Much as I'm hoping to avoid more problems of this type at the next upgrade, I think I'll just have to deal with the problems as they crop up *sigh*

I don't see why you need .EVAL at all. I would use -SET to construct the fileid, using the standard dot notation for "indexed" variables, and reference the resuting &var in the -include:

-SET &INCLUDEFILES0=3;
-SET &INCLUDEFILES1='firstincfile';
-SET &INCLUDEFILES2='secondincfile';
-SET &INCLUDEFILES3='thirdincfile';
-***********************************************
-REPEAT INCLOOPEND FOR &INCLOOP FROM 1 TO &INCLUDEFILES0;
-SET &fex = 'include_files/' | &INCLUDEFILES.&INCLOOP | '.fex';
-MRNOEDIT -INCLUDE &fex
-INCLOOPEND

You only need -MRNOEDIT in order to escape the -INCLUDE (so that it becomes a server-side include rather than an MR include). The -SET shouldn't require it.

The reference to &fex will be expanded by dialog manager when

-INCLUDE &fex

will be parsed on the server; .EVAL should not be needed.

J, I use the ".EVAL" whenever I want to ensure that the variable is EVALuated before the statement is interpreted. I was told that this was one of the "Best Practices" where you can never go wrong doing it this way. "A little .EVAL never hurts anything"...

Whoever sold you that aphorism owes you a refend. .EVAL is a transformation, and there are times when adding it will change your result. Get to know the mechanics of what it does, and you'll know when it is called for.

Getting back to your code, and what changed with the releases:

&INCLUDEFILES&INCLOOP.EVAL.EVAL.fex

Dialog manager scans the line right to left left to right [my head was still on vacation is Israel], locating amper var references and performing substitution.

Under the old release, apparently the interpretation of &INCLUDEFILES, when immediately followed by an &, is left pending. If &INCLOOP is 1, the application of the first .EVAL changes
&INCLUDEFILES&INCLOOP.EVAL.EVAL.fex
to
&INCLUDEFILES1.EVAL.fex
and the remaining .EVAL is applied to
&INCLUDEFILES1
resulting in
firstincfile.fex


Under the newer release, once the rightward scan encounters the & (of &INCLOOP) immediately following &INCLUDEFILES, &INCLUDEFILES is recognized as an amper variable reference and its fate is sealed (substitution if it's defined; error or autoprompt otherwise).

I don't think the old behavior was documented, so I would avoid going there -- especially when the dot construct (&stemvariable.&indexvariable ) is provided (search on "indexed variables") precisely to provide a means of referencing indexed variables.

This message has been edited. Last edited by: j.gross,

Thanks for the clarification Jack. Allow me to elaborate on my "whenever I want" statement with a clarification of the fact that I do stringent testing and verification before I accept the final results of my coding. That is "whenever I want" NE "ALWAYS" -Doug