RE: What bugs you about KLISTs in RPG IV? -- RPG400-L

Free form file i/o expressions sounds great.  I would give up KLISTs for:
Read FileName *eq (kfld1:kfld2:kfld3:kfld4)
where *eq for chain, *ne for reade and *pe for readpe.  Also what would be
nice would be able to skip one or more fields in the key i.e. Read FileName
*eq (kfld1::kfld3:kfld4)

I have several files keyed on multiple fields with selection screen.  The
users usually don't use all continuous key fields, or even know they should.
So I usually reade on as many continuous fields as I can and test for the
rest with the read loop.  Sure would be nice and perhaps faster if the data
base manager did it for us.  Yes I know a lot of IO could be involved and is
involved in some of my rpg programs.  For the most commonly used combination
I create additional access paths and decide which ones to use in the
program.  I have also resorted to using opnqryf for my record selection
which can run faster then skipping in rpg.  Any chance of adding this
functionality to rpg directly?

Christopher K. Bipes            mailto:ChrisB@Cross-Check.com
Sr. Programmer/Analyst          mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.                        http:\\www.cross-check.com
6119 State Farm Drive           Phone: 707 586-0551 x 1102
Rohnert Park  CA  94928         Fax: 707 586-1884



-----Original Message-----
From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com]
Sent: Tuesday, June 15, 1999 6:50 AM
To: RPG400-L@midrange.com
Subject: RE: What bugs you about KLISTs in RPG IV?




Thanks for your input on this issue!

Here's a bit more background:  We understand fully why people
want to be able to define KLISTs in D-Specs.   However, while
a KLIST does define a klist name, the key fields are somewhat
awkward on the D-Spec.  For example, although you can  define
fields on the KFLD opcode, you can also  code indexed arrays,
which are not allowed today in positions 7-21 of the D-Spec.

Someone raised the idea of a "KLIST Data Structure".  That is
an interesting idea which I'll pursue further.   But, I don't
think it would be able  to fully replace the functionality of
of the KLIST.

One person came close to another idea that we've been playing
with here in the lab.  As you know, there are rumors floating
around about a new free-format calc spec.  Let's assume for a
moment  that these rumors are true.  This would give new ways
to enhance old opcodes.  The main thing  that has bothered me
about KLISTs is that they are necessary at all! If we weren't
limited to 14 chars in Factor 1, we would be able to list the
keys directly in the CHAIN opcode.  Imagine for a moment:

     cf   chain (custno: acctno: date) mastfile

or even:

     cf  chain (prodno: 'X' + subcode(n+14)) mastfile

In other words, full expressions coded directly as key fields
for the keyed I/O operations!

So todays questions are:  Would you take advantage of this if
available?  Would you still use KLISTs?

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *