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



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

Follow-Ups:

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.