Question on "AT BREAK" statement

Hi,

What is the use of Reference Notation ® in the AT BREAK statement?

The manual says,
"By default, the final AT BREAK condition (for loop termination) is always related to the outermost active processing loop initiated with a FIND, READ, READ WORK FILE, HISTOGRAM or SORT statement.

With the notation “®” you can relate the final break condition of an AT BREAK statement to another specific currently open processing loop (that is, the loop in which the AT BREAK statement is located or any outer loop). "

Samething is true with PERFORM BREAK PROCESSING statement.

I have the following doubt.

What is this “final AT BREAK condition”?. Why it is different from other Break conditions?

Thanks,
Selva

The documentation then says:

.
Break conditions are evaluated bottom to top (and executed top to bottom!). So the final AT BREAK condition is the first AT BREAK statement.

I can only recommend one thing: Stay far away from AT BREAK and ACCEPT/REJECT statements in Natural programs; you always end up being sorry! There’s nothing like simple IFs and DECIDEs which don’t let the developer in doubt of what’s happening in the program when debugging it.

I strictly disagree! A program with AT BREAK is much more readable than a program with coded manual breaks (except if you are a Cobol junkie)

I agree with Wilfried—AT BREAK is much easier to use and understand than manually tracking old values and calculating breaks. I’ve used it many times and can’t ever remember being sorry.

Suppose I have code such as:

READ MYVIEW IN LOGICAL SEQUENCE BY CITY
*
AT BREAK OF CITY
break code, e.g. citywide subtotals
END-BREAK

The way this “works” is:

Natural reads a record from Adabas.

Natural checks to see if the new value of CITY is different than the old value for CITY. If so, Natural executes the AT BREAK logic, then proceeds to execute the logic of the READ loop. If not, Natural simply executes the READ loop.

Suppose the last city on my file is PARIS. There is no “next record” to cause the processing of PARIS subtotals. Thus, Natural “forces” a final break at the end of the loop. This is done before an AT END OF DATA clause (where I might have logic for final totals).

While it is true one can always write code using IFs to perform logic similar to that of AT BREAK, a programmer must write (and debug/maintain) code to deal with the following that Natural does automatically:

The first record (new value is different than old value, but old value is null).

System functions (computed and RESET automatically by Natural)

The final “forced” break, as discussed above.

Multiple breaks. For example, I am reading by a superdescriptor that concatenates city and state. I have two successive records with values Portland (city) - Maine (state) and Portland (city) - Oregon (state). Unless the programmer is careful, their program might only recognize the state break, not the city break. In Natural, by placing the AT BREAK OF CITY clause prior to the AT BREAK OF STATE clause, Natural knows there is an implied hierarchy, and a state break “forces” a city break.

One further note. Suppose I have a clause such as AT BREAK OF CITY. The only time, while in the AT BREAK clause, that OLD (CITY) equals CITY is during the final forced break. (forgetting about special cases like WHERE clauses, security, etc.)

steve

While I do not agree with the comment as far as AT BREAK is concerned (see last post), I do agree with the reservation about ACCEPT/REJECT.

IF … ESCAPE TOP is functionally identical to REJECT IF…

and, in my opinion, more “readable”. In addition, there are too many programmers who do not know the difference between contiguous and non contiguous ACCEPT/REJECTs. There is no such confusion with IF…ESCAPE TOP.

steve