RE: [EXTERNAL] Re: Expanding a field in a file or adding a new field to the file

No. All wrong.

Let's say your original table (MYTAB) looks like this
R MYTABR
COLA 2A
COLB 2A
COLC 2A
COLD 2A
...
So you copy this to NEWTABLE.
Change the record format to NEWTABLER
Add your new column
COL23 2A
Now you create a logical file called MYTAB over NEWTABLE. You use the record format MYTABR and specify all the fields listed in NEWTABLE except the new one. You give it the record format name of MYTABR.
This new logical file will have the same record format id that the old table MYTAB did. No programs which aren’t using COL23 need to be recompiled.
Instead of accessing NEWTABLE a better practice would have you create an additional logical file, sample MYTAB01. This would contain the new column, COL23. You would use this in the programs which need COL23.
A better practice is creating a logical file which only contains the columns needed by the programs which need COL23.
A better practice is foregoing all these concerns about record format level id's and trash using F specs in your programs and convert to SQL. If you increase the size of a column then your only concern is to match work fields in your programs to the new attributes. Well, that and output columns.

Never use SELECT * in SQL. Always select the columns individually.

InforLX never uses the same record format in their logicals as their physicals. Their logicals pick the columns individually. Their RPG never accesses the physical tables directly. I have added columns to the base physical and never had to recompile their programs, or their logicals. Makes it real nice to add temporal support to their base physical files. As much as I think they could improve their database with primary key constraints, check constraints, referential constraints, etc this part works out nice. I guess the only thing nice I can say about no key on the physical is that it discourages people from coding to that directly.

Rob Berendt