One of the users at my current site approached me regarding a problem they were experiencing with a new compound report they were writing.


The examples provided do not necessarily show a realistic situation.

Without getting into the specifics, the following two sets of code illustrate this behaviour

 

-* File report1.fex

SET ASNAMES = ON
SET HOLDLIST = PRINTONLY

-* Extract all cars from carfile.

TABLE FILE CAR
BY CAR
ON TABLE SAVE AS CARS
END
-RUN
-SET &CAR = ' ';
-SET &TOTLINES = &LINES ;
-SET &CNTR = 0 ;

-* Based on output format, set up the compound.

-SET &CMPND1 = IF &OUTPUT EQ 'EXL2K' THEN 'SET COMPOUND=OPEN' ELSE ' ';
&CMPND1
-*-TYPE &CMPND1

-* repeat loop to go through each car and include a new fex to produce a report.

-REPEAT :LOOP WHILE &CNTR LT &TOTLINES ;
-SET &CNTR = &CNTR + 1 ;
-READ CARS &CAR.A16.

-SET &PDFCLOSE = IF (&OUTPUT EQ 'PDF') AND (&CNTR EQ &TOTLINES) THEN 'CLOSE' ELSE 'OPEN' ;
-SET &CMPND2 = IF (&OUTPUT EQ 'EXL2K') AND (&CNTR EQ &TOTLINES) THEN 'SET COMPOUND=CLOSE' ELSE ' ' ;
&CMPND2
-*-TYPE &CMPND2
-*-TYPE THE CAR IS &CAR
-*-TYPE PDFCLOSE &PDFCLOSE
-INCLUDE report2

-:LOOP

 

The above logic will loop through the saved file to then include the following logic to produce a compound report

 

-* File report1.fex

-SET &ECHO = ALL ;

-IF &OUTPUT EQ 'PDF'   THEN GOTO PDF&CNTR ELSE
-IF &OUTPUT EQ 'HTML'  THEN GOTO HTML&CNTR ELSE
-IF &OUTPUT EQ 'EXL2K' THEN GOTO EXL&CNTR ;

-* PDF output.  The logic successfully branches to this label PDF&CNTR

-PDF&CNTR
TABLE FILE CAR
SUM SALES BY CAR
WHERE CAR EQ '&CAR'
ON TABLE PCHOLD FORMAT PDF &PDFCLOSE
END
-IF &OUTPUT EQ 'PDF' THEN GOTO :END&CNTR ;
-GOTO :END&CNTR

-* HTML output.  The logic successfully branches to this label PDF&CNTR

-HTML&CNTR
TABLE FILE CAR
SUM SALES BY CAR
WHERE CAR EQ '&CAR'
END
-IF &OUTPUT EQ 'HTML' THEN GOTO :END&CNTR ;
-GOTO :END&CNTR

-* EXL2K output.  The logic successfully branches to this label PDF&CNTR

-EXL&CNTR
TABLE FILE CAR
SUM SALES BY CAR
WHERE CAR EQ '&CAR'
ON TABLE PCHOLD FORMAT EXL2K
ON TABLE SET STYLE *
TITLETEXT='&CAR',$
ENDSTYLE
END

-:END&CNTR

 

In this second report, if you were to comment out the following after the PDf report:

-IF &OUTPUT EQ 'PDF' THEN GOTO :END&CNTR ;

and just use the -GOTO :END&CNTR, it returns the following error message:

0 ERROR AT OR NEAR LINE 19 IN PROCEDURE report2 FOCEXEC *
(FOC305) SPECIFIED LABEL NOT FOUND: :END1

I'm curious as to why the -GOTO will not work but replacing it with the -IF (with the GOTO) will work.

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

Adding .EVAL to the labels may make the GOTO work.

-PDF&CNTR.EVAL

Francis,

That doesn't work either. Something to note is that the GOTO for the -PDF&CNTR, -HTML&CNTR and -EXL&CNTR work just fine.

It's the GOTO to the :END&CNTR that doesn't work.

I've tried using .EVAL on the label, even in the GOTO. I've also tried setting a new parameter to be ':END' || &CNTR with other variations and that doesn't work either.

Ken

Ken, have you tried changing the label name? Perhaps the ':' or the 'END' is causing the problem.

Ken,

I'm probably looking at this too simply, but why are you messin' about with this. I haven't seen anything in the doc about &vars in labels. Experience has taught me that if it isn't documented, even if it works now, there is no guarantee that it will work in a future release.

If the table requests in the second procedure only differ by the output line, then parameterize the whole line. If the table requests differ on more then the output line, create 3 procedures, and only include the appropriate procedure.

Just my thoughts.

dhagen,

You will not see the following in the documentation either, but I'm sure it's perfectly valid:

-SET &verb = IF &FRUIT EQ 'APPLE' THEN 'PRINT' ELSE 'SUM';

TABLE FILE CAR
&verb
SALES
BY COUNTRY
END

Since the -REPEAT in the INLCUDE is executed several times it would seem to make send to have & in the label.

You can't always rely on the documentation. For instance, it's perfectly fine to use several of the functions in Dialog Manager, but I've not found any documentation that shows that.

dhagen,

The reason I'm looking into this is that the user is attempting include a couple of fex's within a repeat loop to create one single compound report for distribution. This procedure also includes multiple sql passthru calls.

My suggestion to use &vars in labels was to ensure that uniqueness is maintained in the entire procedure (as opposed to creating several modules that are executed separately within a larger process), because we all know the fun you have when you try to run a procedure with the same label in muliple locations. Creating multiple focexecs in this case would absolutely result in having to maintain several reports whenever on needed to be changed.

Ken

For each label encountered, Dialog Manager memorizes the label and the fex name and line number. That enables it to avoid reading forward to locate a label that occurred earlier in the fex.

Label conflicts only arise when two fexes with common lables are -INCLUDEd in the same parent fex. It is perfectly ok to -INCLUDE a fex multiple times, or in a loop, even if it contains GOTO's (and their labels). The second time around, Dialog Manager recalls that it encountered that label at a particular line of that fex and proceeds directly there, which is fine.

And in fact that is what you were doing, successfully, when you used -IF ... GOTO.

No substitution is performed in labels. The "&" in "-EXL&CNTR" is just another character; it does not trigger the substitution mechanism.

Dialog Manager performs substitution in the target of a bare GOTO statement if it contains an &, but (for whatever reason) not when the GOTO is part of an IF statement. So in the inner fex, the label ":END&CNTR" in the construct

-IF &OUTPUT EQ 'PDF' THEN GOTO :END&CNTR ;
. . .
-:END&CNTR

is a constant, and might as well be simply :ENDLOOP.

As discussed in an earlier thread, conflicts may arise if the fexes are stored in MR; but if the inner fex is stored on the WFR server and referenced with MRNOEDIT, there should be no problem.

Jack, wouldn't a .EVAL first evaluate the & and then DM takes over?

Wouldn't
-IF &OUTPUT EQ 'PDF' THEN GOTO :END&CNTR.EVAL ;

Become

-IF &OUTPUT EQ 'PDF' THEN GOTO :END1 ;

yes (actually, DM doesn't "take over" from there - DM is in charge of dealing with the .EVAL in the first place)

-- but then a label of
-:END&CNTR
or
-:END&CNTR.EVAL
isn't seen by DM as
-:END1
when searching for the target line, so the GOTO fails.

This is very interesting.

Is this the only instance where Dialog Manager ignores the amper variable and/or the .EVAL?

If so, it is very odd.

There is a certain logic to it: Labels are literals, not executable code.

DM is scanning the lines to find a matching label, not to execute them -- so no substitution takes place, until it finds the matching line. Since it is not (yet) attempting to execute the lines, & and .EVAL have no special significance at that point in the process.

& is also treated literally in -DEFAULT values (but .EVAL will force evaluation). Thus:

-SET X0=123;
-DEFAULT &X1=&X0, &X2=&X0.EVAL
-? &X

yields:

CURRENTLY DEFINED & VARIABLES STARTING WITH 'X':
&X0 = 123
&X1 = &X0
&X2 = 123
> >

Jack, I know that .EVAL will force evaluation for a -DEFAULT, I assumed it would the same way everywhere.

Thank you for your fine clarification - it explains why I've had to find work-arounds in the past.

Francis.