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


  • Subject: Re: What bugs you about KLISTs in RPG IV?
  • From: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 17 Jun 1999 13:44:14 -0500

Vijosh A <VijoshA@alfuttaim.co.ae> wrote:
> Scott, your explanation is brilliant as usual.
>

thanx :)

> But my question remains unanswered. If I use file fields directly as
>  KLIST
> variables, I believe using KLIST will make maintenance easier.

Why would it matter?

I can envision two possibilities with externally defined fields.  One
is when the externally defined field is going to change in size,
at the same time as the key -- in which case all you have to do is
re-compile in BOTH scenarios.

The other would be if the key ISNT changing, and if thats the case
you have to add code to create a temporary copy of the field in a
field thats the size of the key.   Whether the name of the field is
defined in a KLIST or not, you'd have to do exactly the same thing.

So again, I don't see what difference it makes.  Regardless of
whether you've got a KLIST or the list is given in parenthesis after
the chain statement, you've still got the SAME thing, and you've
still gotta do the same thing to make updates.  The only difference
is the added convienience of being able to list the keys right on
the chain statement.

Here's the one exception...  Hans mentioned that if the free-form
syntax were to be used, there'd be a possibility that the type and
size checking of the keys could be relaxed.   If this is done, you
wouldn't have do anything but re-compile!   In this case, its more
convienient to use free-form.

Is there something that I'm not taking into consideration?

>
> And as for F11'ng - we need to see the KLIST quite often because we
>  work on
> various projects and many a  times debugging programs written by
>  somebody
> else.
> Another doubt comes to mind  - If you define a KLIST as a data
>  structure,
> will there  be any memory overheads? And secondly if I have many dat
> structures already defined and used in the program (e.g. programs in
>  CA-PRMS
> etc.), don't you think that this new set of data structures will
>  further
> lengthen the list and make the life of a maintenance guy difficult?
>  That too
> when you are battling against time in most of the cases.

I'm not sure why there'd be memory overheads to using data structures.
a data structure shouldn't take up any more memory than its components
do...

in other words, if I have 2 fields, one is 10 the other is 15 bytes
long, if I defined them as subfields of a 25 byte data structure, its
still 25 bytes of memory, either way.

I must be unusual in that most of my files have 3 or less keys in
their keylists, and pressing F11 the two extra times really doesn't
bother me.  I also must be unusual in that I always seem to already
know what the values of the fields are in the keylist...

I don't see how adding a data structure makes program maintenance any
more difficult than adding a keylist does.   When I maintain a program
one is just as good/bad as the other.

Obviously, everyone has different programming styles, and they work
in different enviornments.   For me, being able to debug a keylist
would not be a significant improvement.   Maybe this is due to the
way that I work, and the type of work I find myself doing, as opposed
to the way others do them.

So, I guess that I'm giving my opinions on things, here.  The opinions
I express are what I've found to be true, for me.

>
> Cheers
>
> Vijosh A
> Systems & Software
> 123 , SDF-  4,  SEEPZ
> Bombay, India.
> Email : <vijosha@alfuttaim.co.ae>

Regards...

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.