Re: LR not turning *ON??

["Rory Hewitt" <roryhewitt@xxxxxxxxx>]

Rob,

That's what subroutines are for :-)

Seriously, the thought of doing a (simple) file read (ok, plus error
handling) in a separate subprocedure has always seemed over the top to me,
what with the potential extra overhead in creating the call stack etc.

Plus, surely this breaks the cardinal rule about loading a global variable
(a record format data-structure) from a subprocedure. I guess you could pass
the entire data-structure back from the subprocedure, but why go to all that
bother?

exsr readFile;
dow recordFound = *on;
 //processing
 exsr readFile;
enddo;
begsr readFile;
 read(e) File;
 recordFound = ( not %eof and not %errror );
endsr;
OK, you could use far more complex error/eof handling, but at least you
still have all that stuff in one place (in a subroutine). Of course my
example uses the (despised by some) priming read, but it's up to you how you
do it. The subroutine name makes it clear what you're doing, so the next
guy/girl (unless they're a *real* idiot) can decipher what's going on.

I know, I know - I really *don't* want to start the whole subroutines vs.
subprocedures argument again. And I know that a subroutine is really an
explicit GOTO in disguise (with an implicit GOTO at the end. And I know that
subprocedures have a huge number of advantages over subroutines - that's why
I use subprocedures! But subroutines have their uses, such as removing
mainline convolution, but retaining full error/eof handling and keeping
everything in a single (main) procedure.

Rory



On 3/19/07, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote:
> That would be nice, write up a DCR.
>
> I guess with the subprocedure approach you can build other stuff into it,
> like how do you want to handle errors besides EOF.  Granted, you could do
> that inline in your example, but rarely executed error handling can make a
> mainline look convoluted.
>
> Rob Berendt