× 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 17-May-2017 09:22 -0600, Charles Wilt wrote:
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. 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. Since the layout of
the logical did not change I expected the file identifier to not
change but it did. Is this normal behavior ? I was hoping I could
do this and not need to recompile a lot of RPG applications that
use this logical.

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

<<SNIP>> I don't think what you're trying to do will work. You may
get the record format ID to remain the same. But you'll find that
the resulting LF is now read-only.

You could add a new longer field, along with a trigger to keep them
in-sync.

Or you could perhaps make use of an INSTEAD OF trigger to allow
writes to the LF.

AIUI, in the described scenario, the LF would give access to the physical data, but only the first 18 characters of the LNAME field of the PF -- yet update capable for all of those 18 characters as well. Newer code accessing an LF with the longer length would have access to all 50 characters from the physical data -- for both read and update.

The CHGPF SRCFILE(specified) would leave the Record Format of the LF unchanged; remains so, irrespective any changes to the DDS source for that LF. The use of CRTLF, however, would be required to reference *updated source* to maintain the original\unchanged RcdFmt and an unchanged Record Format Level Identifier; i.e. without the explicit length=18 specified, the LF being re-created.from source would get the new length=50 attribute and thus get a new RcdFmt LvlId.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.