|
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Tuesday, October 02, 2007 4:48 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: MVC in RPG?
One thing I'm pretty sure of is that my manager probably
think I spend to much time on this :).
If you change a field from length of 20 to 50, I don't see
how you can just update the DB layer service program and call
it the day. Are you going to just assume that all existing
programs that use the getter method would work just fine even
though the receiving variable is still declare as 20 in length?
. . .
If you have the following type of DB getter:
D getMyFileNextRec pr likerec(MYFILEFmt)
Or
D getMyFileNextRec pr N
D piResultDs likerec(myFILEFMT)
Without recompile the caller that uses above type of getter
method might result in corrupt data.
. . .
There is a big different between RPG's chain/read.. and your
own getMyFileNextRec(). Chain/read normally does not share
access path between program (Unless specifically override by
program). Your own
getMyFileNextRec() is global (Unless implement special code
to prevent it. Not going to be easy). For example if
program A has a Dow
getMyFileNextRec() and within the do loop it calls program B.
If program B happens to execute getMyFileNextRec(), the Do
loop in program A is likely to get mess up.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joel Cochran
Sent: Tuesday, October 02, 2007 3:13 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: MVC in RPG?
On 10/2/07, Lim Hock-Chai <Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote:
uses the DB
3. If you still have to do research on all programs that
layer when changing attribute of a field, you are reallynot gain much
from it. As far as adding new field, it is only true ifyour DB layer
does not have procedure that allowed caller to get the entire DS of
the file. Unfortunately, getting the entire DS is a pretty useful
function to have.
OK, let's look at this another way. Using "Classic I/O", you
would have to find all the code that references the field
anyway, so you aren't losing anything there.
With the database layer, you have the option of updating the
consuming code, but it isn't required: you could leave the
original procedure intact, so that preexisting code continues
to function, and add a new procedure for the updated length
of the field. You could even change the code of the original
procedure to call the new one behind the scenes, making
whatever adjustments are necessary to make the two compatible.
If you need to add data integrity checking, you only add it
ONE TIME to the database layer. Let's say the business rules
for a field change, whether the field definition changes or
not: in option A, implementing that business rule requires
you to find every instance in your code that references that
field, updating the behavior, and then recompiling all the
*MODULES, and updating or recompiling all the programs. In
option B, using a database access layer requires changes to
only one code
source: it gets compiled, and an UPDSRVPGM command is issued.
From a maintenance standpoint, I like option B a lot better. Andhow often are you changing the attributes of existing fields?
honestly,
As for the DS issue, I'm not sure I follow: retrieving the DS
from the Service Program would simply return whatever the
current definition is.
If your code does not consume new fields, then what is the issue?
4. There are several ways to go around the problem, the point being
that are you really gaining anything from DB layer? Whyreplace RPG
io functions that all RPG developers are familiar with withyour own
io functions that no new comer can understand without additionaltrainings?
The functions are no more difficult than any other call to
any other ILE procedure. And you aren't REplacing the IO
functions, you are DISplacing them. I wouldn't hire a
programmer who couldn't grasp this quickly. If anything, you
are making their job easier because they only need to knwothe
interface, not the entire database. It is definitely not
rocket science.
--
Joel Cochran
http://www.developingfor.net
--
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.
--
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.
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.
midrange.com
