The big problem I have with anybody suggesting this approach is nobody is
saying _when_ this methodology should be implemented. I think somebody
would be hard pressed to make a case where MOST I/O should follow this
*SRVPGM DAO approach, because in the end we are looking to save time and be
thorough with our coding. Adding a DAO layer on top of most files isn't
going to save you time in the long run I would bet. I would say that files
changing their layout frequently could benefit greatly from this approach,
but others would not. And even then a solid change management product can
help with discovering dependencies and doing the recompiles. And if your
files are changing A LOT then you may have DB normalization issues more than
anything.
It smells a lot like trying to implement what Java/.NET has, and if RPG and
Java were similar in regards to db access then I would more agree with this
approach - but that simply isn't the case.
I think we are on the same page as far as us both saying "it depends on the
situation", but I think our median of where the "it depends" is different.
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Cassidy, Alan
Sent: Wednesday, September 26, 2007 9:25 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: MVC in RPG?
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
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
