Re: Level check question

On 16-May-2017 20:19 -0600, Mike Cunningham wrote:

I have a project coming up where I need to expand a character field
in a physical file, but for now I don’t want to increase the field
length in any associated logical files. I created a test physical
file and test logical with the field length set at the current size,
compiled them and looked at the file identifier in the logical and
recorded the value.

As already alluded in other response(s), the File Level Identifier and the Record Format Level Identifier are quite distinct. Which of those identifiers is being reviewed, and about which the comments are being made, must be made conspicuous to a reader, to ensure clarity.

The logical file listed all physical file fields and the logical had
blanks for the length so it would use the physical length. I then
changed the logical to specify a length that matched the physical,
like below, and compiled the logical and the file identifier did not
change (as I expected).
I then change the length of LNAME to 50 in the physical and did a
CHGPF, recompiled the logical with LNAME at 18.

Had the Change Physical File (CHGPF) request [with Source File (SRCFILE) specified] effected the re-create, or had a new Create Logical File (CRTLF) been issued as a recompile/re-create? If the CRTLF vs CHGPF was used to "recompile", then the explicit length specification is required for the field in the LF DDS source, such that the new file will match the original; without that change to the DDS source, the FmtLvlId would _necessarily change_ due to the change to the layout of the underlying physical, because no length specification implies the length attribute should come from the changed PF.

Since the layout of the logical did not change I expected the file
identifier to not change but it did. Is this normal behavior?

The RcdFmt LvlId should not change per use of the CHGPF SRCFILE(specified). But the File LvlId would necessarily change, if a new CRTLF had been issued, instead of allowing CHGPF SRCFILE(specified) to do the work; the ALTER leaves the original File Level Identifier [creation date], despite the file gets re-created, because the file should be "the same" file from the perspective of the user and programs.

I was hoping I could do this and not need to recompile a lot of RPG
applications that use this logical.

The following is not valid DDS-LF source; given an added PFILE spec, then the LF originally created using the following source [even without the "18" specified] would be expected to result in an unchanged LF record format after only the CHGPF was used. The LF source would "need" to be changed to ensure that any future re-create of the LF similarly resulted in an unchanged LF record format; for the effective ALTER TABLE per CHGPF, the LF is re-created from/with the existing record format, not re-created from the DDS source [which may not even exist], so the DDS source would be irrelevant.

A R PERDTA
A SSID
A LNAME 18
A MNAME
A FNAME
A LFNAME
A LNAMELC
A MNAMELC
A FNAMELC
A LFNAMELC
A ADDR1
A ADDR2
A CITY

As I understand what is described, the Record Format (RcdFmt) Level Identifier (LvlId) for the Logical File (LF) should *not* change. There should not even be any requirement for explicitly specifying the original column-length in the original LF creation, because just the explicit listing of the columns should have achieved the logical independence; i.e. any LF capable of allowing the effective ALTER should re-create the same as the original [excepting defect corrections whereby an LF with a defect is created without the defect], as the effect of CHGPF SRCFILE(specified) -- and irrespective, that length specification being present in the source. Of course, again, the source changed to explicitly set the 18 as length is /required/, so as to ensure any future create-from-source [i.e. Create Logical File (CRTLF)] activity that occurs to regenerate the Database File network would have the same effect as what the CHGPF [as effective ALTER TABLE] had effected.