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

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