Thanks Frank,

Our FRF's provide a single size definition for each field used in the
module of the application.

And out field naming all references back to the base definition.

So as an example we have a base definition of say COY 3P0 for Company

All files (PF, LF, DSPF, PRTF) will reference back to this base
definition.

So if we changed COY from 3P0 to 5P0 and recompiled the only issues
requiring manual intervention would be DSPF and PRTF

We have identified a subset of data in the FRF that can logically be moved
to a new FRF and will free up about 5000 bytes which does not solve the
problem but does give us considerable breathing space.

Cheers

Don





From: "Frank Kolmann" <Frank.Kolmann@xxxxxxxxx>
To: "Don Brown via RPG400-L" <rpg400-l@xxxxxxxxxxxxxxxxxx>
Date: 26/05/2022 07:23 PM
Subject: Re: Field reference file record length exceeded
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx>



Hi Don

Perhaps you are generating many reference fields all having the same
properties eg Anumb P 5,3

You could have created a basic set of fields with specific properties,
then in your actual file you refer to the field with the properties you
need.

The idea here, is, if you ever need to change a fields size you need to
only change it in one place then recompile all other PF and LF and
programs.
This idea rarely works mainly because of size constraints on screens and
reports, and work fields in programs,
because rarely are related work fields in programs referenced based on a
files fields.
Also there may be many fields with attribute P 5,3 that you dont want to
change.

So people tended to put the entire set of fields for a new PF in the FRF
and bingo you run out of space.

So one needs to asks what is the point of Field Reference files?

I cant think of one scenario where say a 15 byte part number needs to be
extended to say 18 bytes and you need to identify ALL part numbers to be
extended, and reference files help.

Whenever I needed to do such a job I needed to find ALL 15 byte fields
to change to 18 bytes and check if they were part numbers. Pathfinder
could show all fields 15 bytes long, but mainly I needed to work from
the field-where-used-listings from program compilations.
So in this case you could easily have a generic 15 byte field in the FRF
and there would also be a generic 18 byte field in the FRF and you would
then change the PF LF DDS to refer to the 18 byte field.

This rather destroys the concept of having a field in the FRF that
defines the attribute of part numbers. However as I tried to mention
already this concept of a FRF does not really work.

In summary you need to consider the question,
What are we trying to achieve with having a FRF, and how will it help,
if we ever need to change a fields size?

IMO FRFs are a concept that never really worked as expected.

Regards
Frank


On 26/05/2022 8:57 am, Don Brown via RPG400-L wrote:
We have a field reference file and the latest enhancements we are making
have caused the record length to exceed the maximum of 32766

I am not aware of any way around this except to try and split the field
reference file into two files.

Has anyone else had this problem and how did you resolve it ?

Thanks

Don

--
This email has been scanned for computer viruses. Although MSD has taken
reasonable precautions to ensure no viruses are present in this email, MSD
cannot accept responsibility for any loss or damage arising from the use
of this email or attachments..


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-2022 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.