|
Found the following in archive, I wonder that is the answer to your question: * Subject: Re: Compile error when using field in a subfield data structure * From: Hans Boldt <boldt@xxxxxxxxxx> * Date: Wed, 12 May 2004 08:26:49 -0400 * List-archive: <http://archive.midrange.com/rpg400-l> * List-help: <mailto:rpg400-l-request@xxxxxxxxxxxx?subject=help> * List-id: RPG programming on the AS400 / iSeries <rpg400-l.midrange.com> * List-post: <mailto:rpg400-l@xxxxxxxxxxxx> * List-subscribe: <http://lists.midrange.com/mailman/listinfo/rpg400-l>, <mailto:rpg400-l-request@xxxxxxxxxxxx?subject=subscribe> * List-unsubscribe: <http://lists.midrange.com/mailman/listinfo/rpg400-l>, <mailto:rpg400-l-request@xxxxxxxxxxxx?subject=unsubscribe> Lim Hock-Chai wrote: I wonder why the restriction on klist. Our shop does not allow free-form. Is there is more modern way to do a klist in non-free format? Why the restriction on KLIST? It's not just KLIST. It's all opcodes that use the old-style calcs that use Factor-1, Factor-2, and the Result-Field. These entries only allow "simple qualified names". That is, names of the form A.B or A.B(X). Fully qualified names can only be coded in the Extended-Factor-2 entry, or on (almost all) opcodes coded in free-form calcs. It's only on those entries that you're not limited to 14 characters. Is there are more modern way to do KLIST in non-free-form calcs? No. The more modern way to code search arguments is to use free-form calcs and code the search argument using either %KDS() or the list syntax. Either approach allows you to avoid completely the old opcodes KLIST and KFLD. %KDS() is a close match to KLIST, and provides functionality that works like a sort of externally described KLIST. The key list syntax allows you to specify all elements of the compound key directly in the indexed I/O statement. Either way, you also get the benefit that the search argument only needs to match the corresponding key in type - length and format may differ, just like in an EVAL statement. Actually, I find it strange that your shop standards would disallow free-form calcs but allow other even more recent functionality like fully qualified names. If you want to fully take advantage of deeply nested data structures, it would seem that free-form calcs is pretty much a co-requisite. You might want to reconsider your shop coding standards one way or the other. That is, either allow free-form calcs or also disallow defining subfields with LIKEDS or LIKEREC. Cheers! Hans -----Original Message----- From: rpg400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx [mailto:rpg400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx]On Behalf Of Tim Kredlo Sent: Tuesday, February 01, 2005 7:39 PM To: RPG400-L@xxxxxxxxxxxx Subject: Qualified data structure use O Brilliant Ones: I am at V5R2 and can't seem to find much information about where one can and/or cannot use a fully qualified data structure field, except from compile errors. The manual says: "Fully qualified names are allowed in any free-form calculation specifications" and SvCYMD = TvRtrvOP.TvRecd.TvCYMD; is okay and Test(DE) *YMD TvRecd.TvCYMD; is okay but Test(DE) *YMD TvRtrvOP.TvRecd.TvCYMD; and (stuck parenthesis around as a WAG for solution) Test(DE) *YMD (TvRtrvOP.TvRecd.TvCYMD); Both give the compile error "RNF0623 - The qualified name is not specified correctly." First of all, I don't understand why one shouldn't be able to use them anywhere they "fit". Secondly, if one can use a qualified name in a situation, why not a "fully" qualified name in the same situation? Any direction to pertinent resources would be greatly appreciated. TIA Tim Kredlo -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
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.