Re: Full Free and Input specs

From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of SReeves@xxxxxxxxxxxxxxxxxx
Sent: Tuesday, September 26, 2017 9:11 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Full Free and Input specs

I have a file that has multiple records; basically combining two other files together, each of which have different field names for the same things. This file is a part of our ERP, so it isn't something I made or can change, however we often have to reference it in our programs.
Normally we would use the input specs to rename the fields of one of the records to match the other record. Such as.

IRECORDB
I BFIELD1 AFIELD1
I BFIELD2 AFIELD2


This allows us to chain the file and find/retrieve information from either record without having to check each separately.

I'm trying to get more of our programs done in full free format, and from what I'm reading their is no 'input' specs in free and they should not be used. So I'm trying to see if there is way to accomplish the same thing without the 'I' specs.

I don't bother trying to go to **free with programs using files like this.
I use /free, keep the I-specs, and write the rest of the specs in fully free.

With an architecture firmly rooted in the 1970s, it's more work on the
programmer (mental workload, not typing) to stuff that old style of
I/O into **free syntax than the benefit gained by doing so. Put
another way, the entire point of **free, of modern syntax, is to
reduce the cognitive burden on the programmer, and by the time I'm
done bodging together all the weird looking pieces, it's harder to
comprehend than the older way was. Reasonable people will differ, but
that's how it's played out for me after almost 40 years of doing this.

For a thought experiment / proof of concept, consider an ERPds =
getERPRecordA(key) sub-procedure. Keep /that/ in the form you're
accustomed to, I-specs and all. Yep, it'd still be ugly, but the ugly
would be in one place - the service program. All the consuming
programs would be **free; no F, I, or I/O specs referring to this
file. The ERPds could be in the /copy for the service program
prototypes, so you could even have standard names for the fields.
--buck