×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On Fri, Jan 29, 2021 at 7:10 AM Larry "DrFranken" Bolhuis <
midrange@xxxxxxxxxxxx> wrote:
I do not recommend this and never have. I refer to it as the 'lazy man's
approach' though I've been told 'hey we're just letting the computer do
the work.' OK I suppose.
I agree that LVLCHK(*NO) is the lazy way...
But using it isn't letting the computer do the work, it's telling the
computer to not bother.
Rather than using it, I'd insert a logical view of the data between the
physical data and the application
- create a new PF/SQL table with the new column(s)
- create a new LF with the original PF name, and an explicit list of the
original columns
- modify all existing logicals to point to the new PF and with an explicit
column list
- new LF(s) with new column(s) for any program that need to access the new
column(s)
Now going forward, you can add all the columns you want to the new PF, just
creating new LF's with the new columns for any program that need them.
Just ensure that _no_ RPG program directly references the PF. They should
always reference a LF.
The only thing that even needs to be recompiled are the programs that need
changes to use the new columns.
Charles
midrange.com
