|
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 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.