Renaming Fields in the D specs: why?

Troy, I've been following this thread with some interest and I'd like to
push your gray cells around a bit.

There isn't any other mechanism for selectively changing input field names.
I-specs aren't going away as long as there is one person on the planet using
RPG cycle control breaks (and I'll get flamed if I make a joke about the
last person still using matching record, so I won't).  I'm not sure it's
worth a lot of extra code (possibly confusing and more likely to contain
errors) to achieve your goal.  I-specs are the elegant solution for
selective renaming; use the prefix option to rename every data element in a
file.  I-specs are not innately bad or wrong, but then I'm one of those who
rejects controlling interactive program logic with DOU *IN03 (F3 is CA03 in
every one of my programs, so it's okay).  Don't forget what I-specs are:
they're input specifications, not data description specifications (at least
if you're using externally-defined files).  As input specs, they're related
to I/O functions and that's what you're dealing with here.

You haven't provided quite enough detail for us to understand your situation
with the duplicate field names.  If you're saying PF 1 has a field named
"QUANTITY" and PF 2 has a field named "QUANTITY", and the LF is over PF 2,
IMHO you have a design issue smellier that a stopped-up marine toilet in
August.  Database issues may be out of your control, but I urge you to adopt
and enforce a record, field, and object naming convention.  My own PF
standards include a 2-character prefix and a 4-to-6 character field name
(i.e. a record name is "FHREC" and all the fields in the file start with
"FH").  Does is result in extra coding? Maybe 1%, but your payback is
clearer logic, substantially easier debugging, elimination of the
different-sizes-for-the-same-field-name errors, and elimination of the
problem you're wrasslin' with now.  It costs you nothing up front and will
save you a substantial amount of time, effort, and heartache later.

If the LF is not a full-format (i.e. you're specifying the fields in the
LF), another solution is to create a new version of the offending LF and
rename the offending fields within the new LF (using RENAME...at least it's
not an I-spec!).  If it's a true duplicate, the access path will be shared
and there won't be any additional system overhead.  The downside is you have
to keep the files in sync to prevent application problems and to prevent the
creation of another access path.

Good luck!