We can take and generate the DB code then tweak it so that it reads the
correct master file in the correct situation.
In this case you are introducing business logic encapsulation and I doubt
anyone would disagree with that approach. And rather, IMO, this is where
you *SHOULD* be doing your DB I/O encapsulation. Like was said in another
post by Lim, it seems this approach is catering to exceptions and making it
the norm. I would be curious to know your opinion of it in two years :-)
3. When a work variable is needed, it is declared with a Like() this way on
a field change we would only need a recompile, and our CM software handles
all that.
Depends on what was changed. I think ALL the code would still need to be
reviewed, you just may not have to do as many manual changes. Obviously if
you are switching data types this approach is still going to be painful,
simply because you are most likely using opcodes and BIF's that are specific
to a data type (i.e. %int, %subst, etc). But let's say you are only
changing a character based field from 15 long to 50 long. You will still
have to check all references to that field to make sure none of the code
working with it will break (i.e. does the screen field you are moving it to
support that new length?, does the XML document you are putting it in
support that length, etc).
I do agree though that LIKE and LIKEDS are very nice to use.
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of chris beck
Sent: Tuesday, October 02, 2007 8:36 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: MVC in RPG?
Quite the contrary I believe that they can actually make life easier for the
new comer. For example we have a purchased app with over 1200 files, and the
database design absolutely sucks it has over 8 master files with names in
it. We can take and generate the DB code then tweak it so that it reads the
correct master file in the correct situation. This way as a consumer of the
procedures when I want a Resident name, I don't have to hunt around and
decide what file to use all I have to do is say getResName(resAcctNum) and
not worry about it.
3. When a work variable is needed, it is declared with a Like() this way on
a field change we would only need a recompile, and our CM software handles
all that. We have found that we actually need very few work fields since you
can just call the getter when you need to value.
4. The DB layer would signal and error. This also comes down to your idea of
a good design. I would not call a routine that loops through the file that
you are already processing.
midrange.com
