× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott Mildenberger wrote:

>I know your response said typical 
>I/O functions but what is your
>opinion on functions such as 
>GetCustName or ValidStation 
>that aren't obviously doing any I/O?  

Instead of including a test for %open and an open in each and every I/O
routine, it always seemed cleaner (to me) to have an explicit fileOpen and
fileClose routine.

>The user of the function doesn't 
>really know if files are open/closed 
>(nor should they care).  

I agree that this is the ideal place to be, but to be honest, I'm not sure
of the best path to Nirvana.

>I tend to take the approach
>that the files used in a service 
>program are USROPN and they 
>are opened by the first procedure 
>that uses them.  

I started that way but now I like the idea of a public fileOpen, fileClose
and fileStatus function.  That way the caller can determine when to
open/close and if it is indeed open or not.  It's a case of where do you
prefer to do the if %open: in the caller or in the procedure.  I lean toward
the former even though it exposes more of the I/O module's guts to the
caller.  I have been doing work using commitment control, and the "caller
controlled" open/close/commit seems to be more natural in that environment.

>I usually just leave the file open
>unless it is a file/procedure that 
>isn't typically used very often.  I know
>this can leave a number of files 
>open in interactive jobs but I haven't
>noticed any problems with this, 
>although that doesn't mean there 
>aren't any.

I haven't seen problems either.  Synon programs do the same thing and there
can be A Lot of open files - typical jobs have over a hundred open files at
a time with no apparent problems.  Like I said earlier, in a commitment
control environment, you really want to be aware of "pending updates."  If
you need to track the end of a transaction, you may as well track the end of
the "session" as well.  Saves yourself from uncommitted records...

Buck Calabro
Aptis; Albany, NY
"We are what we repeatedly do.
 Excellence, then, is not an act, but a habit." --Aristotle


Billing Concepts Corp., a NASDAQ Listed Company, Symbol: BILL
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.