• Subject: RE: Runtime KLIST change?
  • From: Ken Slaugh <ken.slaugh@xxxxxxxxxx>
  • Date: Sat, 4 Dec 1999 12:14:14 -0800

Here, Here Booth.

A most disturbing aspect of RPG/LE is rather obvious. Opinions will vary
even more than the good old RPG/36 days. No two programmers could agree
even then. The coding standards and design structure of RPG/LE
applications makes development standards hard to achieve and enforce.
Most of the time, the 'good old' way of RPG coding satisfies the
end-user requirements. I've concluded many of such arguments by stating,
"The only good programs, regards of coding technique, are the ones that
work". No ones else's opinions ever could supersede such a statement.

K.I.S.S. - Keep It Simple Stupid

Ken Slaugh (707) 795-1512 Ext 118 
Programmer/System Analyst - Chouinard & Myhre, Inc. 
Certified Network Administrator MSE
Specialist - Client Access/400 

http://www.cm-inc.com/ 



-----Original Message-----
From: boothm@earth.goddard.edu [mailto:boothm@earth.goddard.edu]
Sent: Saturday, December 04, 1999 9:32 AM
To: RPG400-L@midrange.com
Subject: Re: Runtime KLIST change?


Are you making this more complicated than needed?  Why not define KLIST1

and KLIST2 as you've described and then define KLIST3 as pointing at
NULL 
and, when you need to point to NULL, use KLIST3 as the KLIST in your 
program.

But aside from that your message struck terror into my heart.  Why, oh 
why, is RPG adopting pointers, the single greatest weak point of C++? 
Aren't the disasters of PARMs as pointers enough of a lesson to IBM?  My

initial reaction to RPGIV is reinforced every time I see a message like 
this message.  I don't know Frank at all, and I have no idea what
problem 
his program resolves, but I do know a lot of shops that would have no
idea 
of how to maintain the program he's describing.  Not only have no idea, 
but they'd be belligerent that it was even in their shop. 

I mean no disrespect, nor do I feel I am ignoring technological
advances. 
I do however remember seeing a post a few days ago from someone still 
running some Sys/36 code.  I'd bet the major reason he's still running
the 
code is because the original code was bleeding edge at the time it was 
written but now it is just a footnote of poor techniques that no one 
understands, or, if they understand it, won't admit to.

_______________________
Booth Martin
boothm@earth.goddard.edu
http://www.spy.net/~booth
_______________________




Frank Steinjan <fstone@wtal.de>
Sent by: owner-rpg400-l@midrange.com
12/04/1999 03:12 AM
Please respond to RPG400-L

 
        To:     RPG400-L@midrange.com
        cc: 
        Subject:        Runtime KLIST change?

Hallo,

as V4.4 offers more and more possibillities I would like to know if
there is any trick to handle different KLISTs in an RPG-Program. I had
the following problem:

I wanted to use file file_x1 and file_x2 within the same program.
KLIST of x1 consists of field_a and field_b while x2 consists only of
field_b.

What I wanted to do is to define field_a and field_b as pointers where
in case of file_x2 field_a points to NULL. But this doesn't work.
Perhaps someone outhere can gimme a hint.
Thanx in advance...

Frank


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to
RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| 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.