Alan,
I think the key point you may have missed, in that last article I posted, and this is crucial, is that you must always list all the fields you want to include in each LF, and not simply list the "keys" ...
Otherwise, when you change the PF, e.g. add a new column/field, whether using CRTPF and then recreating all of the LFs using CRTLF, or by using CHGPF to do the equivalent of "SQL ALTER TABLE ..." under the covers, the effect will be that all of the LFs will now have a different record format level ID, because the new column will automatically be included in every one of those LFs. :-o That is NOT what you want, in this case.
Also, you need to rename the original PF, before you have added any new columns, and then create a brand-new LF that has the same name as the original PF, with exactly those same columns, so that it also has the same Record Format Level ID ... you can verify this with DSPFD. Then, once you have created those LFs, with all the fields listed, (you can just use SEU split-screen and "CC-CC" from the original PF DDS source), then, and only then, can you go back and make changes to the now renamed PF, e.g. to add a new column.
And then, you will create one or more new LFs that also include that new column -- but the only programs that should ever use those new LFs are the ones that specifically need to deal with that new column.
Read that article again, and see if it makes more "sense" after reading the HINT above.
Hope that helps,
Mark S. Waterbury
On Wednesday, July 31, 2019, 3:48:55 PM EDT, Alan Shore via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
Thanks for the reply Mark
Now that this idea has sunk in a little more, here is where I am having a problem
Tell me where I am going wrong
I change the physical to add a new field (called - NEWTOKEN)
Create new logicals - defining all the fields in the physical (including NEWTOKEN) and use these logicals where the new field NEWTOKEN is required
Here is the point I need to make
The logicals that are already built - but do NOT define ANY field - will be recreated to include the NEWTOKEN field and will have an new level identifier - correct?
That means the programs that use these logicals will still need to be recompiled
OR
Change the level check on these logicals to *NO
Im not saying that this is a showstopper for this process - just trying to cover all bases BEFORE work is started where I end up saying - HMMMMMMMMMMMMMMMM
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
‘If you're going through hell, keep going.’
Winston Churchill
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Mark Waterbury
Sent: Wednesday, July 31, 2019 3:38 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: [EXTERNAL] Re: Expanding a field in a file or adding a new field to the file
Alan, and Charles,
Do not force the issue of converting from DDS to SQL DDL ... at least, not "right away" ...
In this case, for "legacy" applications, you can still use DDS to create a Logical File that has the exact same record layout, record format level ID, and it will have an index and so "native" Record I/O (e.g. RPG SETLL, READE etc.) will all work just fine.
This technique has been available since the days of the System/38 and CPF, and I am very surprised that more people are seemingly not aware of this method to avoid having to recompile all of the programs that use the "base" physical file, every time you want to add or change a single field or column in a database physical file.
Hope that helps,
Mark S. Waterbury
On Wednesday, July 31, 2019, 3:07:22 PM EDT, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:
Sure it will...
Assume you have 100 programs that access the table now.
But only 10 actually do anything with the CC token column...
Instead of recompiling and testing 100 programs, you need only recompile and test 10.
Only catch is RPG programs that use RPG record level I/O through an SQL index (instead of a keyed logical file) Those would also need to be recompiled and tested as explicitly including columns in an SQL index changes the record layout...but that would only be needed this time. (Time time you change the table, you're golden.) I thought I had an RFE to change this...but guess not..
Charles
On Wed, Jul 31, 2019 at 12:19 PM Alan Shore via MIDRANGE-L < midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
Thanks Sam
That article definitely helped
However, Im still not 100% sure this will help in what I need
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On
Behalf Of Sam_L
Sent: Wednesday, July 31, 2019 2:08 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: [EXTERNAL] Re: Expanding a field in a file or adding a
new field to the file
This article *might* help understand what Charles is suggesting:
https://www.mcpressonline.com/programming/rpg/use-a-logical-file-layer
-to-minimize-recompiles-from-field-additions
Sam
On 7/31/2019 2:00 PM, Alan Shore via MIDRANGE-L wrote:
Hi Charles
Im not too sure I have an understanding on this
I tried to create some type of diagram, following what you suggested
- but its NOT working out Any chance you could make it simpler for a
simpleton like me?
Alan Shore
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
