That's a good approach...for RLA. For SQL processing I'd say just
create a view with your selection criteria and just handle ordering in
your SQL statement in the RPG program. With SQL processing you don't
really *need* a select/omit LF. Just as a side note in case someone
tries this...if you do a SELECT directly from a SELECT/OMIT LF you'll be
forcing the SQL to the CQE..which is dog slow compared to SQE...
But I have used both approaches for files in the past and they both work
great. In some client shops they do not have DB2/SQL product so I still
use the field list LF you're talking about.
Thanks,
Tommy Holden
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Friday, April 20, 2007 9:18 AM
To: Midrange Systems Technical Discussion
Subject: RE: SQL logical file equivalent
Why not do that?
I was trying to say (perhaps poorly <G>) that you SHOULD create your
logical files by explicitly specifying the fields you want. You should
NOT create the LF by omitting the field list and allowing all table
columns to flow into the LF.
I'm suggesting this approach so your 3GL RLA access is isolated from any
table changes in the base table. If you omit the field list and just
inherit the complete field list into the LF than the addition of a new
column to the base table will result in a change in the format level id
of the LF and you'll have to deal with that impact -- something I'm
trying to avoid.
Make sense?
-Walden
midrange.com
