Aaron,
Remember Joel Cochran? RPG-Next? He of
http://www.rpgnext.com/?
I think he still might lurk around here somewhere, and his web site is
still good, just to let him know he's welcome to pipe in if he's there
(we won't throw stones at you, Joel)
He has already expounded on the issues involved in encapsulating I/O in
this article:
http://www.itjungle.com/fhg/fhg072104-story01.html
I -think- he even has downloadable code ready-to-go for creating a
service program for any database file.
We have a bunch of files here with names like CHAR4, CHAR50, just
because they wanted to have extra fields for new purposes that came
along as they *always* do. Encapsulating the I/O would obviate level
check and record formatting issues for all the programs that use
previous file formats.
I just did some superficial, toe-in-the-water stuff. Like:
If CustFile_Found( ExternallyDescribedDS : key1 : key2 : key3 ) ;
{...process record found...}
Else ;
{...process record not found...)
EndIf ;
..where the ExternallyDescribedDS is, of course, for the CustFile
record.
I still find that a bit inelegant, because you still have to do the E_DS
ExtName( CustFile ) thing inside the caller, but the fields were already
externally described with the file anyway, just now without the baggage
that offloading the IO takes care of (in only one place). Like adding a
century field, or absolutely having to expand a company-number
field--that's happened in at least three places I've worked).
IMO, any "shop standard" that uses strict *SRVPGM IO for new
development, *absolutely* have to have accompanying rules to handle
those very issues.
Inside such a service program, native RPG might still be better for some
things (like CHAIN, even maybe SETLL/READE) inside that service program.
It's the kind of "thought exercise" I like to hobby in, so maybe I'll
come up with something. BUT
--Alan
-----Original Message-----
On Behalf Of albartell
Couple questions:
1 - What is your criteria as to whether or not a file gets an RPG
*SRVPGM IO
layer put in front of it? Or should all files potentially have a
wrapper in
your approach?
2 - How do you relay record not found?
3 - How do you return information back to your program?
4 - How would you do a SETLL, READE, DOW not %EOF loop?
5 - How do you do a READ/CHAIN for lock vs. no-lock?
6 - How do you WRITE records to a file?
Some of the above are semi-rhetorical, simply because I have already
been
down the road of what you are proposing. But I would be interested to
know
if somebody came up with a solid and reasoned implementation of *SRVPGM
IO -
I have yet to see one that is well reasoned other than going on a
case-by-case (read file-by-file) basis.
Aaron Bartell
http://mowyourlawn.com
midrange.com
