Re: Defining Files locally in Sub-Procedures - What advantages has everyone found doing it that way?

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Andy,

I like it because it helps encapsulate the logic.  You can designate 
that a particular procedure is responsible for reading a particular 
file...  and not have to worry about other procedures "accidentally" 
changing the file's cursor, or modifying the contents of one of the 
variables.

It's all encapsulated into one routine. If the logic behind the routine 
changes, you only have to worry about changing it in one place. You only 
have to worry about re-testing that one place, etc.  Nothing else is 
affected.

On the other hand, I've been finding myself doing much, much more of my 
file logic in SQL, so I haven't used it too terribly much.  If you had 
asked me 5 years ago, I'd say "sure, I'll use that constantly..."  but, 
due to SQL, I only use F-specs (in or out of procedures) when I want to 
load/write one record at a time, and only when performance is critical. 
Everything else is SQL.

-SK


On 7/27/2012 1:52 PM, Andy Hautamaki wrote:
> Our shop is going to be moving from V5R4 to V7 in a few months so I can
> finally start using the enhancements in V6 and V7.
>
> The idea of being able to define the files in Sub-Procedures instead of
> globally in a module I was thinking would be very cool. Then I got to
> thinking when would I really need to do that? When has everyone else been
> finding it was a better idea to define the files in a sub-procedure?
>
> I was reading about how the file will be closed without it having the
> static keyword. When would it be better to use the static versus not? If
> your using the sub-procedure repeatedly the open and closing of the file
> seems like a reason to be using the static. Interesting idea that you could
> be getting different records for the same file in different sub-procedures.
>
> Thanks
> Andy