Re: I/O routines in HLL

Joel,

I'd say the "best practice" is to use embedded SQL instead of native I/O. Definitely don't use OPNQRYF in new programs!

But, if you're maintaining existing applications, and don't have the resources to rewrite them (and I don't blame you for that!) then I'd take it on a case-by-case basis. Most of the time, I would recommend encapsulating the logic into a subprocedure as much as possible. (I would never use subroutines for this.)

We could debate about the difference between a "priming read" vs. coding an extra 'if' in a loop. But, after endless debate, ultimately, it doesn't amount to much. You say poTAYto, I say poTAHto. It really doesn't matter.

-SK


On 6/7/2012 9:43 AM, Stone, Joel wrote:

In an HLL on Iseries (RPG or COBOL or other) is there a "best
practices" method to build an I/O subroutine?

For example to read a customer record, should the i/o routine contain
ONLY a read, with any positioning/accept/reject logic outside the i/o
routine?

Or should the i/o routine be a black box which returns ONLY records
that the program is interested in processing? >
Or is either approach equally accepted?

Or a better approach?

This would be AFTER an SQL or opnqryf or LF does its own filtering of the cust file.



Also, is a priming read widely used to start sequential processing of a file, or is there a better method?

(at my current job, priming reads are avoided, but that seems to add lots of complexity and layers - but maybe its just that Im not used to it)


I know these are basic q's, but my new job is challenging stuff I thought was standard!

Thanks!