Re: ARGH!!! (was file open with LR)

["Buck" <buck.calabro@xxxxxxxxxxxx>]

Hi Booth!

> Joe, doesn't one lose the value of reusable code
> if you can not depend upon it?

Great question!  I have strong feelings on this matter so indulge me for a
moment.  I don't think that the Grail is 'reusable code,' but rather
reusable LOGIC.  Business logic.  Reusing code (especially entire programs)
can lead to scenarios like the one Brad has struggled with.  Without a
complete understanding of the intended architecture of an entire application
(which is all the programs in it), I would be very ill at ease simply
calling individual programs from that application.  I am NOT saying that
this is what Brad did, but I'm trying to make the point that an application
grew according to some design: even if that design was never discussed.
Programmers made decisions and implemented them in code.  Overrides here, no
LR there.

I'm really obsessive about this, because I see more than a few programmers
who look only at a subroutine and think they understand what it is doing.
But they have not looked at the cross reference: does file I/O modify
variables?  Indicators?  Is there a data structure somewhere?  Program
calls?  And that's just in the RPG program.  There's probably a whole job
stream, replete with overrides in CL, OPNQRYF or FMTDTA, CPYF, calls to
other programs before and after this one - you name it.  And that's just
this job.  The database files are updated by other processes; the
information has a life span (transaction file data is good until committed
at EOM or whatever.)  When those files are purged of old records can make a
world of difference to understanding why THIS run came out different from
the one last night.

Reusing code is a step toward the goal of reusing logic, but until we write
code in a way that makes the logic reusable and independent of the rest of
the code, we are going to have to do some work to get at it.  That's what I
think, anyway.
  --buck