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