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



I believe one can also /include or /copy non-**free stuff into a **freesource - I can't verify it for I-specs, and it does mean maintaining an extra source member just for I-specs.

Might be interesting to try, however.

Cheers
Vern

On 9/26/2017 8:51 AM, Buck Calabro wrote:
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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.