Hi Folks,
Let me begin by saying that this forum is great, thank you!

I've been at WebFOCUS for about 8 months now. I like it, but I just can't exaplain some of the stuff I see.

I've inherited some code and we've discovered a bug where some calculations are incorrect. The CNT_OCCS column isn't being calculated correctly. So I'm trying to teach myself how it is being calculated.

TABLE FILE OCCURRENCES
SUM
...
COMPUTE COUNTER/I9 = COUNTER + 1; NOPRINT
COMPUTE CNT_OCCS/I9 = CNT_OCC + 1; NOPRINT
BY LOWEST RECENCY NOPRINT
BY OCCURRENCES.FACT_OCCURRENCE.OCCURRENCE_NUMBER AS 'Occ #'
BY OCCURRENCES.FACT_OCCURRENCE.OCCURRENCE_SOURCE_KEY NOPRINT
...

My first issue (and I don't think any of you can solve it without seeing all the code) is that I have no idea where CNT_OCC is coming from. I've searched every fex file for that string with no success. The synonym doesn't have that string either. Anyway... don't worry about it... my biggest gripe is with the following...

What is really blowing my mind is that
COMPUTE CNT_OCCS/I9 = CNT_OCC + 1; NOPRINT
line.

If I output the value of CNT_OCCS I get 35. So that would mean that CNT_OCC is 34... right? Wrong... have a look at the lines below:

COMPUTE CNT_OCCS/I9 = CNT_OCC + 1; -*results in 35
COMPUTE CNT_OCCS/I9 = CNT_OCC + 2; -*results in 70
COMPUTE CNT_OCCS/I9 = CNT_OCC + 10; -*results in 350
COMPUTE CNT_OCCS/I9 = CNT_OCC - 1; -*results in -35

So what I can deduce by this is that CNT_OCC is 35, and that its calculating the product not the sum. I'm aware that 2(35) = 70, but why on earth does 35+2=70?

Can anyone explain that behaviour?

I'm just venting now... Can't I rely on the basic logic/arithmetic I learned in grade 1 (rhetorical question, but right now I'm thinking no)? That kind of logic where "+" means ADDITION and not MULTIPLICATION.

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

Without reading ALL of your post, the first thing to consider is that CNT_OCC is CNT_OCCS. The default behaviour of WebFOCUS is to find the real column if a column (field) name is truncated. This is controlled by the SET FIELDNAME command. I don't think this default behaviour is helpful to developers.

So, most likely CNT_OCC is CNT_OCCS, and it's a simple counter of the number of rows in the output.

COMPUTE CNT_OCCS/I9 = CNT_OCC + 1;

This adds one to the current value of CNT_OCCS, for each row in the output.

Try this:

TABLE FILE CAR
PRINT
COMPUTE CNT_OCCS/I9 = CNT_OCC + 1;
BY COUNTRY
BY CAR
BY MODEL
END

Thank you very much for your response.

Wait what? CNT_OCCS is CNT_OCC? Ok... I'm taking a breath... calming down...

That code you posted is a great example. But geez who wrote this FOCUS language? That's crazy. Stuff like that shouldn't be allowed. The only reason they are the same is because the right side happens to have the first few characters of the left side? That's not ok. We've seen i=i+1 in programming for years, but now iThisIsRidiculous=i+1 is equivalent.

To be clear, if the code read out like CNT_OCC = CNT_OCC + 1 I'd understand it to be incrementing a counter, but those are different names! That's so crazy!

Seems like every couple of weeks I find a new FOCUS-ism that defies logic (I think it does). GRRRRR...

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

I think the missing piece is in some training I seem to remember that covered what happen internally from reading the data to outputting the report.

It gives perspective of why things don't seem to work as expected.

quote:

CNT_OCCS is CNT_OCC?

WebFOCUS will check that the field name is a shortened longer name, and use that field.

Great for lazy programmers like me.

Like... wow... I don't know what to say... I'm baffled that WedFOCUS works like this. Is this behaviour considered a feature? I've read above that it can be explained and that there is a reason for this, but its stupid behaviour for a programming language.

X = X That makes sense

XAASEVASRGASEVASVE = X Makes no sense

And hey why stop there... Let's make...

green = grey 'cause they both start with g

52 = 48 'cause they are both even numbers

eggs_benedict = french_toast 'cause they are both made with eggs

Wow...

A bit of fun, try this...

ET GREEN = GREY
DEFINE FILE CAR
GREY/A10 = 'GREY' ;
END
TABLE FILE CAR
PRINT GREEN
BY COUNTRY
END

Shingles,

There are many more "features" to be found!

LOLZ, Waz.

quote:

Originally posted by Waz:

WebFOCUS will check that the field name is a shortened longer name, and use that field.

Great for lazy programmers like me.

Great until a later release and IBI decides to "tighten" their code and all the previous lazily written fexes break.

quote:

IBI decides to "tighten" their code

Depends on whether its a bit of Gerry code....

Shingles

All this field name truncation aside, I would like to explain an important concept. When you COMPUTE a field the name you give it is a virtual name it doesn't have to exist anywhere else like in the synonym, you are creating it on the fly. Additionally when using DEFINE the calculation happens as each record is read but a COMPUTE is done after all the records have been read and they are in memory so you can get different results especially rounding differences. When you are truly doing a calculation you always want to use a COMPUTE to get the most accurate result. When you are doing a counter I think a DEFINE is the best way. My 2 cents...

SET FIELDNAME = NOTRUNC

Allowing unique truncations (of an existing fieldname to guess what the developer meant) is in my book a candidate for the worst ideas in ICT ever.

The problem is that it has a tendency to mask real errors caused by typos, incomplete renaming actions or lack of coffee.

Unfortunately, once introduced in a product, you can't simply get rid of it without breaking backwards compatibility.

quote:

a candidate for the worst ideas in ICT ever.

Agreed. A new column could be added to a table with the same set of beginning characters, and WebFOCUS would select it instead of the original column. - Correction after clarification by jgelona.

This message has been edited. Last edited by: Francis Mariani,

Shingles, green will not equal grey because green has no 'y' after the first e in green. Also, to be valid, a shorter, truncated, field name has to match only 1 real field otherwise there is an error. For example:

COMPUTE CNT_OCCS/I9 = CNT_OCC + 1; NOPRINT
COMPUTE CNT_OCCD/I9 = CNT_OCC + 1; NOPRINT

Since CNT_OCC is not a real or virtual field, this will give an error because CNT_OCC now matches 2 fields.

On thing you'll learn is there are lots of SET commands (not -SET) that control how the FOCUS/WebFOCUS language works, like SET TRUNCATE. I've been using FOCUS/WebFOCUS since 1985 and this has always been a "feature" of the language.

quote:

Originally posted by jgelona:
Shingles, green will not equal grey because ...

I'm aware, I just took the ridiculousness up a notch. I don't really think that eggs_benedict = french_toast because they are both made with eggs.