|
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!
As an Amazon Associate we earn from qualifying purchases.
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.