Re: when to use a function or file for information

Rob,

Actually I didn't mention the SQL option.

I was only talking about new and existing RLA access.

I'm a big fan of SQL, but that doesn't mean I'm ready to rewrite every
existing RPG RLA program. :) Or even use it exclusively in new
programs.

Charles

On Tue, Mar 23, 2010 at 1:21 PM, <rob@xxxxxxxxx> wrote:

My thoughts are the subprocedure sounds neat, however, sooner or later the
subprocedure is going to have to look up the information, unless it can be
derived from some of the provided values.  So, if all the subprocedure is
doing is deciding to look in the same file, or extension files I don't
believe I'd go that route.

Charles was close to my opinion on a solution.  Stop using RLA and use SQL
to access the files.  Then there is no concern about record format level
checks.  We did this for an internal product that had to support multiple
versions of a vendor product.  Correlarry:  Never use "select * from...".
Always specify the columns desired.

Where I lost Charles was in his discussion about the various logical
files.  My belief is that you would not need the logical files unless you
wanted to stick with RLA instead of SQL.  Then each xxxL0# could be a
revision of the underlying table and no RLA should touch the underlying
table of  xxx directly.

I've seen one vendor product rename the table and use a logical named the
same as the old table to get the same record format.  And all the old
stuff would continue to use the new logical.  Twas a Y2K solution.


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:   David FOXWELL <David.FOXWELL@xxxxxxxxx>
To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:   03/23/2010 10:43 AM
Subject:        when to use a function or file for information
Sent by:        midrange-l-bounces@xxxxxxxxxxxx



Hi all,

It seems that every day a file somewhere is being modified which causes a
lot of problems as we are many developpers on the same LPAR. Unit tests
are carried out in a test library. The program being tested may use other
programs already in production (ie outside  the test library ) and crash
because another developper has changed a file used by that program.  I
often wonder if the information being added to the file is really
necessary.

For example : if I have myclientFile with ClientNumber and ClientType.
Then I modifiy the file and add a flag : ClientLikesBiscuitsWithCoffee.
So, I'll add a Y or a N to each client record. That information may be
required once a week, although the file is being accessed all day 24/7 by
multiple applications. If the value of the new flag could be revealed by
examining clientType, eg clients must be red or purple, wouldn't this flag
be better left out of the file and a service program used instead to
return the value of the flag?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.