Re: I/O routines in HLL

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

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!