>I recall a previous announcement that said that FB3 would not contain
>GOSUBs or GOTOs (apologies if my recollection is incorrect).

I don't recall hearing that. IMHO, there _is_ at least one good reason 
for a GOTO; the familiar "GOTO MAIN" at the top of the code, which lets 
me skip watching every function name pass by (including include files) in 
the debugger before getting to the "real" code. If FB^3 completely 
"globalizes" functions, so that the "main" code can be at the _top_ of 
the program, that may be irrelevant, however.

I'll admit there are _other_ places that I use GOTO as well, such as in a 
"retry loop" - it's just an "easier" way to code that, rather than making 
it a WHILE loop, when the "retry" condition is rare. The GOTO in that 
case just jumps less than a page of source backwards; easy to follow, and 
not the typical "spaghetti code" causer that GOTO originally got a bad 
rap for.

OTOH, with functions, I see no reason for GOSUB in FB other than a small 
amount of increased speed; rarely all _that_ important.

Since in my "day job" I am sometimes forced to look at 
multi-thousand-line COBOL programs, littered with GOTOs and GOSUBs (well, 
PERFORMs) I am _quite_ familiar with untangling spaghetti. But frankly, 
it's easier to untangle a poorly-written COBOL program than it is a 
poorly-written C program, even if the C version _doesn't_ have GOTOs and 
GOSUBs! And since most of my own work is done in Cognos PowerHouse, which 
has no GOTO (or even a generic "looping" mechanism!) I'm aware of all the 
ways to get around such a lack. Still, GOTO has it's place; as long as 
it isn't as an "easy fix" for bad program design!

Bill
.