Hello,
We are currently upgrading from 7.6 to 8.0.05 and created this document for our users. It is a list of syntax in our codebase that does not work in version 8, but worked in previous version. Hope it can help somone else.

Have a great day
___________


WebFocus 8 Code Tightening
WebFocus upgrades usually comes with code tightening, where syntax that may have not given an error before will error out in the new version. This version is no exception, and the following is a list of issues we found:

FOCEXEC=NONE
FOCEXEC=NONE used to be part of the standard stylesheet on older code. The FOCEXEC= portion of the stylesheet creates a drilldown report. When this was set to NONE in previous version, it would do nothing. In Version 8, FOCEXEC=NONE adjusts the style to look like a URL link. In a report with a PDF format, this underlines all the data the FOCEXEC attribute is applied to. The fix is to remove the FOCEXEC=NONE code from the stylesheet. All existing instances of this code have been removed in production 7.6 and will migrate to version 8. An example of the old code is:
TYPE=REPORT, FOCEXEC=NONE, FONT=ARIAL, SIZE=8, COLOR=BLACK, BACKCOLOR=NONE, STYLE=NORMAL, $

Where statements not allowed on simple joins
Where statements are not allowed on simple JOINs. If you have simple JOINs with WHERE statements, they will return the following error in WebFocus 8:
(FOC376) SYNTAX ERROR OR MISSING ELEMENT IN JOIN/COMBINE COMMAND:
An example of a failing JOIN is:
JOIN CLIENT_ID AND INVOICE_GRP_NBR IN ALLDATA
TO CLT_CPNY_ID AND CLT_ACCUGRP_ID IN VACCUCLT AS J1
WHERE CLT_CPNY_ID IN FILE CPNYIDS;
END
Simple joins (fields before files) are the most common joins, and cannot include where statements:
JOIN field1 [AND field2 ...] IN file1 TO
Field1 [AND field2 ...] IN file2 [AS joinname]
END
Conditional Joins (files before fields) need to have WHERE statements to avoid having a Cartesian product:
JOIN FILE file1 AT field1 TO FILE file2 AT field1 [AS joinname]
[WHERE expression1;
[WHERE expression2;
...]
END

Compound BYTOC reports

Compound reports that have a report followed by a BYTOC report, now require the CLOSE command after the BOTOC.
TABLE FILE file1
…
ON TABLE PCHOLD FORMAT fmt OPEN
END
TABLE FILE file2
…
ON TABLE PCHOLD FORMAT fmt BYTOC CLOSE
END

AND removed from ON TABLE/ ON FIELD lines

The word AND in subtotal and summarize lines is no longer allowed. Code will return the following error:
(FOC002) A WORD IS NOT RECOGNIZED: field2
Examples of old code:
ON TABLE SUMMARIZE field1 AND field2 AND field3
ON field1 SUBTOTAL field2 AND field3 AND field4
ON TABLE COLUMN-TOTAL field1 AND field2 AND field3
Revise to work in version 8:
ON TABLE SUMMARIZE field1 field2 field3
ON field1 SUBTOTAL field2 field3 field4
ON TABLE COLUMN-TOTAL field1 field2 field3

Semicolon errors
We got a couple of errors with extra semicolons in the code.
(FOC003) THE FIELDNAME IS NOT RECOGNIZED: ;
This error happened when we had double semicolons after a define field and when we had a semicolon at the end of an ON TABLE COLUMN_TOTAL line.
(FOC160) THE OPTION AFTER THE WORD 'FORMAT' IS INVALID: ALPHA;
The error occurred when we had a semicolon at the end of an ON TABLE PCHOLD line.
In both instances removal of the semicolon or duplicate semicolon fixed the code.

Single quote errors

Two single quotes are needed to show an apostrophe in a column heading. We received this error:
(FOC003) THE FIELDNAME IS NOT RECOGNIZED: ,Comp'
Old code:
FIELD1/P14.2M AS 'Workers',Comp'
Changed to work with WF 8
FIELD1/P14.2M AS 'Workers'',Comp'
We had to add the extra ‘ to print the s’ on Workers’ Comp.

We also had issues where a single quote was missing on an AS name. AS names do not require quotes; however, if single quotes are used or the AS name includes spaces, WF 8 requires both the opening and closing quotes.

Invalid date formats
We received a (FOC253) INVALID FORMAT SPECIFICATION ON LEFT HAND SIDE error with the following defined fields:
DATE1/MtRYY
DATE2/MtR
Adjusting the formats to all capital letters MTRYY and MTR allowed the report to run.

IF statement errors

WF8 will return an error if you have an IF statement without the ELSE command.
Previous code
-SET &var = IF ‘&flag.EVAL’ EQ ‘Y’ THEN 1;
Returns the following error
(FOC266) IF .. THEN .. ELSE .. SYNTAX ERROR
Code needs to be changes to include and ELSE statement.
-SET &var = IF ‘&flag.EVAL’ EQ ‘Y’ THEN 1 ELSE 0;

We also has an issue with the following defined field
_VALUE/D12.2M = (IF GROUP_CD EQ 1 AND CODE_ID NE 423 OR 424 OR 76) THEN AMOUNT ELSE 0;
The use of an AND along with NE/OR in the same IF statement caused the issue. Adjusting the syntax to the following worked:
_VALUE/D12.2M = IF CODE_ID IN (423,424,76) THEN 0 ELSE IF GROUP_CD EQ 1 THEN AMOUNT ELSE 0;

Dynamic formatting no longer allowed

We had several reports that used dynamic formatting on fields by creating a field that will then be used as the format for the field. This is no longer allowed and we had to change the code to use the FPRINT function instead.
Previous code:
COMPUTE D_FMT/A8 = IF PERCENT_OR_DOLLAR EQ '%' THEN 'P9.2%' ELSE 'P9.2M'; NOPRINT
AMOUNT/D_FMT AS 'Amount'
Updated defined field for version 8:
AMOUNT_FMT/A15 MISSING ON = IF AMOUNT IS MISSING THEN ''
ELSE IF PERCENT_OR_DOLLAR EQ '%' THEN FPRINT(AMOUNT, 'D12.2%', 'A15')
ELSE FPRINT(AMOUNT, 'D12.2M', 'A15');

Could not get error message

The most frustrating issue we came across on running reports that worked in previous versions was getting the following message with no further details:
Error code is: 32027 Could not get error message
Solving these issues is just a matter of troubleshooting to see how far the report will go before it returns the above error, and then finding the piece of code causing the problem. We had three reports with this issue. The first was the use of dynamic formatting on fields; we switched the code to use the FPRINT function to fix it. The second report had a MULTI-LINE on the subtotal line; changing MULTI-LINE to MULTILINES fixed the error. The third report was a text formatted import that had many defined fields that were then combined into one very large defined field that was then printed on the report. There was no error on any of the defined fields; however the report would fail if all defined fields were included. Never figured out what the issue was, but held half the defined fields in one file, then created the rest of the defined fields in a second held file, and that worked.

Case sensitivity in OR statements

When an “or” is not capitalized in the where statement, it will cause the report to fail. Capitalizing the “OR” will resolve the error.

Previous code:
WHERE FIELD1 NE 'a' or 'b'
Code functional in WebFOCUS 8:
WHERE FIELD1 NE 'a' OR 'b'

Font Arial Unicode MS unrecognizable

WebFOCUS 8 gives an error when using the Arial Unicode MS font.

Previous Code:
FONT='ARIAL UNICODE MS'

Code functional in WebFOCUS 8:
FONT='ARIAL'

Multiple ENDSTYLE statements invalid

WebFOCUS 8 does not recognize multiple ENDSTYLE statements. The report will not generate and an error will be displayed when running the report. (Note: style1.fex and style2.fex do not contain ENDSTYLE in the code.)

Previous Code:
ON GRAPH PCHOLD FORMAT PPT OPEN
-INCLUDE style1.fex
ENDSTYLE
-INCLUDE style2.fex
ENDSTYLE
END

Code functional in WebFOCUS 8:
ON GRAPH PCHOLD FORMAT PPT OPEN
-INCLUDE style1.fex
-INCLUDE style2.fex
ENDSTYLE
END

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

Wow, you are brave to go from 7.6 to 8.

This looks pretty comprehensive.

Thanks for the detailed list Emily. Most of the issues you mention make sense as they seem to comply with what's documented about syntax and usage, regardless of more lenient rules in previous versions.

The only one that comes as a shocker to me is Dynamic formatting no longer allowed as that has been quite a useful feature presented by IBI at previous user forums. The workaround to use an ALPHA field to represent the different formatted values as strings works but does not seem as "elegant" as the previous feature. In many cases it will also require adjusting the JUSTIFY clause in the StyleSheet section as ALPHA fields are left-justified by default whereas numbers (regardless of dynamic format) are right-justified. Not a big change but an extra step to keep in mind.

I tested this code on our current reporting server 7.7.05M and it worked as expected.

TABLE FILE CAR
PRINT
COMPUTE FMT/A8 = IF COUNTRY EQ 'JAPAN' THEN 'D10.2' ELSE
                 IF COUNTRY EQ 'ENGLAND' THEN 'D8.1%' ELSE 'D10'; NOPRINT
        CAR
        MODEL
        SALES/FMT  AS 'AMOUNT'
BY COUNTRY
END

We wre told at Summit last year that a 7.7.05M Reporting Server was the same one behind WebFOCUS 8.0.0.3 at the time so it deeply surprises me that the functionality was removed in 8.0.0.5

First: Thanks for the info, nice work.

I can understand it might a big issue...
...but I'm glad it is done. WF is way to 'loose'. Code tightning is good.

And if I read through this, non of these items should cause problems for us. ( Lucky us that we learned Focus through the documentation... )

Njesden:

quote:

The only one that comes as a shocker to me is Dynamic formatting no longer allowed as that has been quite a useful feature presented by IBI at previous user forums. The workaround to use an ALPHA field to represent the different formatted values as strings works but does not seem as "elegant" as the previous feature. In many cases it will also require adjusting the JUSTIFY clause in the StyleSheet section as ALPHA fields are left-justified by default whereas numbers (regardless of dynamic format) are right-justified. Not a big change but an extra step to keep in mind.

According to the documentation on FPRINT the extra JUSTIFY is not needed:

The output of FPRINT for numeric values is right-justified within the area required for the maximum number of characters corresponding to the supplied format. This ensures that all possible values are aligned vertically along the decimal point or units digit.


We recently had a look at version 7.7.06 and there it seems already tightened. The reporting server does not give an error when using dynamic formatting, but we got frequent crashed agents because of it.
So for now we decided to remain on 7.7.05M but the FPRINT is a useful alternative we will also look into.

Martin.

I was surprised by some of these findings, so ran some tests on 7.705 and 8.006.

quote:

Dynamic formatting no longer allowed

Using 7.705/8.006 dynamic formatting is working fine.

quote:

Where statements not allowed on simple joins

Does not work in 7.705/8.006. This was never documented as an option, though it used to work.

quote:

-SET &var = IF ‘&flag.EVAL’ EQ ‘Y’ THEN 1;

Using 7.705/8.006 this is working fine, though bad coding.

quote:

_VALUE/D12.2M = (IF GROUP_CD EQ 1 AND CODE_ID NE 423 OR 424 OR 76) THEN AMOUNT ELSE 0;

Fails in 7.705/8.006. However, moving the incorrect placement of the '(' this works:
_VALUE/D12.2M = IF (GROUP_CD EQ 1 AND CODE_ID NE 423 OR 424 OR 76) THEN AMOUNT ELSE 0;

quote:

ON TABLE SUMMARIZE field1 AND field2 AND field3
ON field1 SUBTOTAL field2 AND field3 AND field4

Using 7.705/8.006 the AND causes no issues. AND is documented.

quote:

ON TABLE COLUMN-TOTAL field1 AND field2 AND field3

This does not work in 7.705/8.006, note that AND is not documented to be used.

Sample test:

DEFINE FILE CAR
_VALUE/D12.2M = IF (SEATS EQ 2 AND SALES NE 12000 OR 4800 OR 7600) THEN RCOST ELSE 0;
END
TABLE FILE CAR
PRINT
COMPUTE FMT/A8 = IF COUNTRY EQ 'JAPAN' THEN 'P10.2' ELSE
                 IF COUNTRY EQ 'ENGLAND' THEN 'D8.1%' ELSE 'P10.2M'; NOPRINT
        CAR
        MODEL
        _VALUE/FMT  AS 'AMOUNT'
       SALES
       RCOST
BY COUNTRY
ON COUNTRY SUBTOTAL _VALUE AND SALES
END

One that bit us regularly after our migration from 7.6.11 to 7.7 was that you now get a syntax error with joins like this one:

JOIN COUNTRY IN CAR TO COUNTRY IN CAR AS J0 END

You have to either leave out the END statement or put it on a next line. It boils down to JOIN not accepting an END statement unless the JOIN is a multi-line statement. Seems a bit of a silly change, as there doesn't seem to be any harm in putting the END-statement at the end of the line (and other languages such as SQL allow it too).

The good news is that according to the IBI tech support guys that visited us yesterday, there exists a syntax checking tool that you can run over your reports before an upgrade to see where you will encounter problems. Apparently it isn't "official" (or part of the release), but that promises to help a lot! I'm sure none of us like surprises like the ones in this thread.

Alan, thorough as usual!

With dynamic formatting, it used to be the case that the format specifier had to be exactly A8 - no less, no more. Is that still the case?

I can understand that the format string can't be shorter than 8 characters, but it can be rather surprising that it isn't allowed to be longer. I, for one, wouldn't mind a bit more flexibility there!

A8 still seems to be the limit for dynamic formatting, although it can be defined bigger, anything passed 8 is ignored.

Thank you for the posting. Valuable as we got caught in a lot of code tightening with FOCUS. Question: Do any of you know if the code changes are downward compatible to Webfocus V7.6.12? V8 is in our future, maybe we can get a heads-up on the changes?

I tested a bit with FPRINT as alternative for dynamic formatting, and I need to adjust my earlier remarks a bit:

quote:

The output of FPRINT for numeric values is right-justified within the area required for the maximum number of characters corresponding to the supplied format. This ensures that all possible values are aligned vertically along the decimal point or units digit.

FPRINT is 'right-justified' in the sense that it has leading spaces in the ALPHA field. However if you print a report with a variable length font numbers in the string are longer than spaces, so a A15 with 10 spaces and 5 digits is longer than A15 with 14 spaces and 1 digit.

So, as Njesden indicated, you would still need additional styling to make it JUSTIFY=RIGHT.

In testing 7.7.06 I also found that dynamic formatting gives only a crash if you use it 'too much' and PDF crashes earliest. If you only use it a little it does work. It only gives problems thought in the final TABLE request making the report. I did not find problems in dynamic formatting in making intermediate hold files.

One more piece of code tightening. I found out recently that when creating procedures to be used in a drop down, you must default all of your variables within the procedure now. Before you could just turn off the prompting on the fex and it wouldn't matter. Now the dropdown won't populate if you do not default your values first. I tested this on 8006.

quote:

Question: Do any of you know if the code changes are downward compatible to Webfocus V7.6.12?

All of these changes were downward compatable. We are in 7.6.12 in Production and had no problems with pushing the updates through.

I tested much with FPRINT as alternative for dynamic formatting today. With the additional JUSTIFY=RIGHT it works well in most cases.

However as soon as you have any totals (sub/row/column) it does not work anymore as FPRINT is alphanumeric.

Does anyone have an alternative for this?

quote:

Originally posted by eric.woerle:
One more piece of code tightening. I found out recently that when creating procedures to be used in a drop down, you must default all of your variables within the procedure now. Before you could just turn off the prompting on the fex and it wouldn't matter. Now the dropdown won't populate if you do not default your values first. I tested this on 8006.

Or you can turn off prompting in the fexes manually (right click and uncheck the prompt option) and then for the html pages by going to:

 administration console >> configuration >> MRE >> and setting IBIMR_prompting to OFF 

While I am at it, we also had issues with EXL07 solved by:

 administration console >> configuration >> client settings >> general >> erase the value in IBIF_excelservurl 

and Graphs in document composer:

 administration console >> configuration >> client >> graph >> erase the value in IBIF_graphservurl 

J,

Thanks for the update. I didn't think to look at the IBIMR_prompting setting. I think for the time being I'm going to leave that setting on and Default my values (I feel that its cleaner to default the values anyways). Luckily, my report set to convert is small enough that it shouldn't be much of an issue.

For the setting of the IBIF_excelservurl and IBIF_graphservurl, what issues was it that you were experiencing?

IBIF_excelservurl - none of our exl07 reports would run (new or old)
IBIF_graphservurl - graphs just wouldn't work correctly in document composer

@Emily, I just tested the code below for dynamic formatting in a 8.0.0.7 testing environment and it worked providing similar results as those in 7.7.05M.

TABLE FILE CAR
PRINT
COMPUTE FMT/A8 = IF COUNTRY EQ 'JAPAN' THEN 'D10.2' ELSE
                 IF COUNTRY EQ 'ENGLAND' THEN 'D8.1%' ELSE 'D10'; NOPRINT
        CAR
        MODEL
        SALES/FMT  AS 'AMOUNT'
BY COUNTRY
END

Release:

EDA8007 Release * Current Software:
EDA8007 Release RELEASE = M728007D
EDA8007 Release GEN_NUM = 144
EDA8007 Release SOURCE_DATE = 01/08/2014 18:25:54
EDA8007 Release BUILD_DATE = 01/15/2014 20:39:15

I wonder what exactly caused the issues you reported when trying dynamic formatting in 8.0.0.5.

Emily, Thank you very much for compiling and sharring this document with the focal point community. Very informative...

quote:

Originally posted by Wep5622:
One that bit us regularly after our migration from 7.6.11 to 7.7 was that you now get a syntax error with joins like this one:

JOIN COUNTRY IN CAR TO COUNTRY IN CAR AS J0 END

You have to either leave out the END statement or put it on a next line. It boils down to JOIN not accepting an END statement unless the JOIN is a multi-line statement. Seems a bit of a silly change, as there doesn't seem to be any harm in putting the END-statement at the end of the line (and other languages such as SQL allow it too).

The good news is that according to the IBI tech support guys that visited us yesterday, there exists a syntax checking tool that you can run over your reports before an upgrade to see where you will encounter problems. Apparently it isn't "official" (or part of the release), but that promises to help a lot! I'm sure none of us like surprises like the ones in this thread.

Do you know how we could get our hands on this "syntax checking tool" you speak of? Do you have a copy at all? I would like to get a copy if possible.

END should always be on a line by its self. for TABLE/DEFINE and JOIN. I think its in the documentation.

Its the one thing that stops the single line query.

I am a little alarmed by the "WebFOCUS Upgrade Considerations Release 8.1 Version 05" document - I can't believe the URL to run a fex changed from v8.0 to v8.1.

It used to be that they were so cautious about changing default behaviour, so that when new features were added, you had to turn them on via a SET command.

Now we have to perform code remediation for minor version upgrades.

Francis,

Actually, IBI is sort of lying to everyone there. They say it's the new way to reference files, but they should of stated it is "a way" to reference files. The new way they discuss there is only applicable to those sites that have bought and enabled the Web Services Enablement add-on for their licensed products. We haven't. I go in and try their newly discussed method of referencing and it does not work. Why? Because that functionality doesn't exist. Not unless we buy another add-on that should just be a part of the product. IBI loves to nickel and dime everyone. It's really old.

Francis,
You mentioned the document:

quote:

"WebFOCUS Upgrade Considerations Release 8.1 Version 05"

I am unable to find that document. Can you attach a link?
We are looking at upgrading to 8.1.05 or possibly 8.2. We currently have 8.0.0.8 and are wondering what has deprecated from 8.0.0.8 and what conversion looks like.
Thanks!
Marilyn

Thank you for the quick response!
Marilyn