We are considering upgrading to 7.7.02. How has your experience with it been so far?

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

Fieldtesting it today. ( incl. lastest hotfixes ) ( we come from 7.6.9 )

No real issues, just some configuration trouble.
( needed new Java-engine & according JDBC drivers : iSeries )

I don't have the 7.7.0.2 studio yet.

Only thing is that 7.7.0.2 seems to ( and I think it has been metioned before here ) more strict considering syntax.

And we found something weird with parameter...

Greets,Dave

We found that there was some syntax regarding using save files that was supported in 7.6.11 that they are no longer supporting in 7.7.


This works in 7.6:

TABLE FILE CAR
PRINT COUNTRY
ON    TABLE SAVE AS AASAVE01
END
-RUN

TABLE FILE CAR
PRINT COUNTRY CAR
WHERE (COUNTRY EQ (AASAVE01));
END
-RUN
 

7.7.02 requires that you use:

TABLE FILE CAR
PRINT COUNTRY
ON    TABLE SAVE AS AASAVE01
END
-RUN

TABLE FILE CAR
PRINT COUNTRY CAR
WHERE (COUNTRY IN FILE (AASAVE01));
END
-RUN
 

The product division is currently determining if they want to address this or not...

That is not exactly true.
The syntax for using the contents of a file in a WHERE is officially WHERE field IN FILE (file).
And the official syntax for doing the same with an IF statement is IF field EQ (file).
And that works, also in the 7.7 releases. So this piece:

TABLE FILE CAR
PRINT COUNTRY CAR
WHERE (COUNTRY EQ (AASAVE01));
END

is a mixture of two syntaxes which apparently was allowed in previous releases. In 77 it should be either what you found, or

TABLE FILE CAR
PRINT COUNTRY CAR
IF COUNTRY EQ (AASAVE01)
END

I guess "supported" might not be the best word to use...

We do have code that uses the

WHERE COUNTRY EQ (AASAVE01);

logic in 7.6.10&.11 that didn't work in 7.7.02.

IBI confirmed that they are tightening the code and are unsure if they will be addressing or not.

The point of my post was that if Fernando, or anyone else uses similar logic, it isn't going to work in 7.7.02 without modifications...

Oh, here we go again!

We've just spent considerable effort migrating from 7.1 to 7.6.11, finding that we had to make a lot of changes because syntax that worked in 7.1 (but maybe wasn't to the spec in the manual) no longer worked in 7.6.11.

As a consequence we had to test every program.

And of course because WebFOCUS allows you to generate code in flight, it can't have a syntax checker.

So not only did we have to test each program, we had to test it for a variety of conditions that might affect generated code.

We don't want to have to repeat this exercise. I'll be referring your post to our Account Manager!

New feature request?

When I save or press "run", either in GUI or text-editor.

run a syntax-check?

Syntax check when you press save? Maintain does that and I find it very very very very annoying. I always switch that 'feature' off. When you press Run, it will indeed do a syntax check. That's the part where you get the error messages .... I find that very helpful ....
BTW: Did you know you can also press F5 to run a fex from within DevStudio?

AND,

SET XRETRIEVAL = OFF

to run a syntax check?

Yes, I agree, WebFOCUS does check syntax. But it checks it at run-time.

So, when you're doing an upgrade, since Information Builders do not guarantee compatibility with the previous version, you need to test every program, and, if you've used parameter substitution in your syntax, then test every program with a variety of cases.

For some languages, I'm sure you can just supply a set of source code files to a process that reads every file and validates the syntax. For example, type "html syntax checker" into google and see how many answers you get! Not so with WebFOCUS for the reasons described above.

Hence the request that IB should maintain compatibility of code in new releases whether or not the code conforms to the official standards.

quote:

Hence the request that IB should maintain compatibility of code in new releases whether or not the code conforms to the official standards.

Bob,

This would open up all sorts of problems. You're basically asking to disregard syntax rules because someone, some where, some time coded something that "worked" even though they knew it was undocumented syntax?

Don't get me wrong, I would love to have a "syntax checker" or "function completion" built in, and finding that the code someone wrote two versions ago no longer works because of "code tightening" is frustrating
at best, not least because I would have to check everything else that the individual (or myself!) had manually coded (been there, done that, got the T shirt). However, over the (too many) years that I've been in IT I've gotten used to coding to the documented standard and accept that if I choose to abandon documented syntax then I (or someone ) will pay the price during an upgrade down the line. I guess that the best scenario would be to have the syntax so tight that you couldn't code outside the documented syntax, but when is that going to happen?

Another aspect is that, as the GUI becomes more and more sophisticated the generated code should always conform and be forward compatible.

Just my "tanners" worth.

T

Agree totally with Tony.

A good approach when developing, to help with this area, is peer reviewing. Two heads are always better than one and it does help break bad habits.

GamP: LOL, yeah I know, I use it all the time ( it was new in version 6.9 I believe ).

Tom Flynn:
SET XRETRIEVAL = OFF works, but if you have HOLD with a MATCH later on, it fails because the HOLD is empty.

Tony B: indeed...

Alan B:
That's what we do here since we've started with WF. One developer, one checker.


Found another one yesterday:

WHERE COUNTRY in ( 'JAPAN', 'ITALY')

Used to work, doesn't anymore. ( can you spot the error ? )

I think i spotted the error
WHERE COUNTRY in ( 'JAPAN', 'ITALY')

'in' is in lower case

I had similiar issues with joins which used to work in 7.6.2. Changed to upper case and it works!


JOIN
RESERVE_CELL.ACTUARY_CODE IN reserve_cell TO
RESERVEPRO_ACTUARY.ACTUARY_CODE IN reservepro_actuary AS J0
END

We have always used the following to get the current time in HH:MM format.

-SET &NOW=HHMMSS('A5');

It has worked all the way back to FOCUS HP-UX ver 6 and maybe it has worked forever.

We are migrating from 7.1.3 to 7.6.11. Somewhere in between, the syntax was "tightened" because in 7.6.11 it gives an error. The documentation has always said that HHMMSS returns and A8 field, now it really does.

So we had to change the above to:

-SET &NOW=EDIT(HHMMSS('A8'),'99999');