I have a summary report. Consider the following example.

DEFINE FILE CAR
  CONV_CNT/I4 MISSING ON=IF BODYTYPE EQ 'CONVERTIBLE' THEN 1 ELSE MISSING;
  SEDAN_CNT/I4 MISSING ON=IF BODYTYPE EQ 'SEDAN' THEN 1 ELSE MISSING;
  HOT_CNT/I4 MISSING ON=IF BODYTYPE EQ 'HOTROD' THEN 1 ELSE MISSING
END
TABLE FILE CAR
  SUM CONV_CNT AS 'CONVERTIBLES'
      SEDAN_CNT AS 'SEDANS'
      HOT_CNT  AS 'HOTRODS'
   BY COUNTRY NOPRINT
   BY CAR
   ON COUNTRY SUBFOOT
"</1>TOTALS FOR <COUNTRY <27><ST.CONV_CNT><35><ST.SEDAN_CNT><44><ST.HOT_CNT></2>"
   ON TABLE SET ONLINE-FMT PDF
END

If HOT_CNT is missing for all values of a specific COUNTRY, then ST.HOT_CNT should display a '.' (the NODATA character) not zero. I can remove the SUBFOOT and use SUBTOTAL or SUB-TOTAL and it is the same, I get 0 instead of '.'

Seems to me this is a bug unless there is some setting I don't know about.

I don't believe you can set a data item to missing in a define, Think I'll try it out though.

quote:

Posted July 19, 2007 10:57 AM
I have a summary report. Consider the following example.


DEFINE FILE CAR
CONV_CNT/I4 MISSING ON=IF BODYTYPE EQ 'CONVERTIBLE' THEN 1 ELSE MISSING;
SEDAN_CNT/I4 MISSING ON=IF BODYTYPE EQ 'SEDAN' THEN 1 ELSE MISSING;
HOT_CNT/I4 MISSING ON=IF BODYTYPE EQ 'HOTROD' THEN 1 ELSE MISSING
END
TABLE FILE CAR
SUM CONV_CNT AS 'CONVERTIBLES'
SEDAN_CNT AS 'SEDANS'
HOT_CNT AS 'HOTRODS'
BY COUNTRY NOPRINT
BY CAR
ON COUNTRY SUBFOOT
"TOTALS FOR <35><44>"
ON TABLE SET ONLINE-FMT PDF
END

I learn something new you can do missing, try changing the I4 to I4S and at least you'll get blanks rather than zero.

If you change the st. in hotrod to tot. you get your .
Don't know if that is going to mess you up in the real world..
TOT.HOT_CNT

I don't believe you ever get the missing character in a subtotal/subfoot line. It may seem like a bug, but that's just the way the functionality works. If you total a numeric field, it always has a numeric value, even if it is only summing "missing" values. Leah's suggestion of using the zero-supress format (S) option would get closer to what you need.

Any reason the last define statement doesn't have a ; at the end?

Kevin

Thanks for the replies.

Leah, I'd still rather have the period, but I think blank works better than 0.

Prarie, the .TOT works, but if there happens to be data, it gives the report total, not the country total.

Kevin, nope, just a typo. I have noticed that WF doesn't seem to mind the missing semicolon in a DEFINE when the field is followed by the END.

Darin, since the .TOT will print the period, seems like .ST should as well. See the following:

DEFINE FILE CAR
  CONV_CNT/I4 MISSING ON=IF BODYTYPE EQ 'CONVERTIBLE' THEN 1 ELSE MISSING;
  SEDAN_CNT/I4 MISSING ON=IF BODYTYPE EQ 'SEDAN' THEN 1 ELSE MISSING;
  HOT_CNT/I4 MISSING ON=IF BODYTYPE EQ 'HOTROD' THEN 1 ELSE MISSING;
END
TABLE FILE CAR
  SUM CONV_CNT AS 'CONVERTIBLES'
      SEDAN_CNT AS 'SEDANS'
      HOT_CNT  AS 'HOTRODS'
   BY COUNTRY NOPRINT
   BY CAR
   ON COUNTRY SUBFOOT
"</1>TOTALS FOR <COUNTRY <27><ST.CONV_CNT><35><ST.SEDAN_CNT><44><ST.HOT_CNT></2>"
   ON TABLE SUBFOOT
"</2>GRAND TOTALS <27><TOT.CONV_CNT><35><TOT.SEDAN_CNT><44><TOT.HOT_CNT></2>"
   ON TABLE SET ONLINE-FMT PDF
END

An observation: IBI is infamous (sorry, IBI folks) for discovering and plugging holes in syntax. Meaning, it's possible that in release 8.0, no field will be definable withhout a semicolon, even if it happens to be the last field before the END statement. If that happens, how many of your focexecs are going to quit working? Never a good idea to take advantage of FOCUS syntax "oversights".

I opened this with IBI as a problem report and they confirmed it as a bug. In their words, this has been an unnoticed bug since "God made dirt". What this means is that instead of fixing it all supported releases, it is being done as an NFR.

Again, thanks to those that replied.

Interesting...

I guess since i've been using FOCUS since God made dirt, I just thought that it just worked that way.

quote:

An observation: IBI is infamous (sorry, IBI folks) for discovering and plugging holes in syntax.

. Sorry, I just can't resist:
Well, considering that in NY right now we have a MAJOR hole in the middle of 41st street, I only wish that someone had discovered it, and plugged it, because it blew up the street. . Yes, of course, we do that. The problem generally comes in that everything was programmed and tested following the rules set forth. We all take shortcuts. Experience tells us that people who take shortcuts get lost in the woods, so anytime we find such a hole, we will plug it so no one gets lost, or gets plausibly wrong results. I’d rather you get a message saying FOCUS can’t do something, than for FOCUS to make a guess as to what you want, and guess wrong.

I actually discussed this with the CSS consultant, and It was me (I take the blame) that said we should put it in as a New Feature. My reason is really that we need to make sure that we didn't have people depending on that behavior (yes, I know it sounds strange, but we have people with problems with a reformatting of a MISSING field. It used to show 0, then the programmers fixed what they (and I considered a forever bug), and made it display . (MISSING). Then, two customers who were depending on that behavior, had problems), so we re-engineered to have a SET COMPMISS . So, just in case there is anyone depending on a SUBFOOT showing zero (not missing), we better have it switchable, which means I want to have it spec'ed out and tested. Easiest way to do that, is new feature.
From Noreen (who is DEFINITELY older than dirt (but not as old as the steam pipe that blew up in NY last night ).

WEFOCUS - All releases starting at 4.3.6
MF FOCUS -- All releases starting at 3.8.68
OS/Platfor _ Predominately Z/OS, but all others as swell
Expected Output Format -- *

Noreen,

I think the comment that dwf made was in reference to the original example I pasted that showed a missing ';' on the last field in the DEFINE.

As far as the NFR on this, as I told the CSS consultant, I was fine with that. It was more of a how the reports looks thing than a major problem. I was just reporting back to the board what I was told and I thought what he said was kinda funny.

If I really, absolutely had to fix this, I could always do some RECAPing and reformatting of the totals. I just don't want to do it on 15 columns in the report. So for now, I'm just goint to use a format of I4S and let it print blank instead of 0 or period.

Yep that was an old pipe...Stay out of the street Noreen....

Well, seems like maybe I touched a nerve. Here's the point: Sytax rules are documented in the FOCUS manuals. Every once in a while, one of those rules slips by the IBI programmers and the language fails to enforce its own rules. It happens. Eventually, the failure of the sytax editor to enforce a rule comes to the attention of IBI and they do what they're supposed to do: they fix it. If you've followed the documented rules in your code, no big deal. But every program that took advantage of the hole in the sytax editor now fails, and you have a mess on your hands. IBI's fault? Well.... partly. They missed the rule in the first place. Your fault, too? Absolutely. But I don't think blame is going to make much difference when you're faced with a few dozen (or a few hundred) suddenly non-functional programs.