Re: Attempt at pure ILE

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Hi,


On Mon, 19 Jun 2000 Contractor1@Parkdalemills.com wrote:

> I am working with a client that wants to move to ILE programming. We are
> very busy and do not have the time for formal education. We take
> opportunities to learn ILE when we can. So far we've been taking baby
> steps. First, we compiled single source modules and bound them into
> programs. Then, we created programs binding multiple modules. We created an
> export subprocedure to center text and it works great.
> 
> After reading an ILE concepts manual I saw were pure ILE expects modules to
> made of nothing but procs. So, I converted one of our model programs to use
> nothing but subprocedures replacing all subroutines and the main logic. It
> compiles but will not run.

One of the modules needs to have a "main" procedure.   Without it, the
program is not runnable. :)   I think what the ILE concept manual is
trying to get across is that you should not be calling other modules'
main procedures, but rather only calling subprocedures within those 
modules.

Personally, when I'm writing a larger or more important application
(as opposed a 10-minute test program) I like to seperate things a
little differently than you are.

The idea is:

-- procedures to be used (now or in the future) by many 
     different programs are in a service program, this makes them easy to
     maintain.  The prototypes for these should be in a "header" (/COPY)
     member, so each program can easily include them. 
 
     Example:  If I were writing an inventory application, I might have
        subprocedures to put things into inventory, remove them from 
        inventory, look up their status, etc that might be called from
        a dozen or so programs.  I'd put these into a service program.

-- procedures that relate to the actual business logic of the program
        itself goes into the main source member.  

-- procedures that relate to do input/output to a report, user, display,
        etc, I put into a seperate bindable module.  This way if I ever
        wanted to make this a client/server program, or have a program
        "act like" a user, etc.  I can simply write/bind a different
        module.

> 
> Attached is the code. We are looking for some good criticism. Feel free to
> be as critical as possible. We are wanting to learn as much as we can from
> experts like yourselves from dissecting this code.
> 
> (See attached file: I2_0020R.txt)
> 
> Thank you,
> 
> Patrick Conner
> www.ConnecTown.com
> (828) 244-0822
> 

If you really want criticism....   your program basically looks like an
OPM program with subprocedures in place of subroutines. :)  The input and
output to each procedure REALLY should be given as parameters, not global
variables.  The procedures should be set up to clearly illustrate (via
the use of const and value) which parameters can be changed by the
procedure, and which can't.

The idea is to be able to make your routines reusable... you can't do that
if you're relying on global variables!

You're using WAAAAAY too many indicators!  :)  If you use the AID byte to
determine what function key is pressed, it'd eliminate a lot of those.
Then you can actually check things like "if funckey = KEY_F3" instead of
"if *IN03" (Actually, I prefer the *INKx indicators for command keys, but
I'd be ridden out of town on a rail if I suggested them on this list!
The reason That I like them is because when I see *INKC, I know its F3.
When I see *IN03, I have to either _know_ that the programmer follows the
03=F3 standard, or I have to look.  The problem with indicators is that they
don't have meaningful names -- and *INKC is a meaningful name!) 

I also avoid using any indicators for display errors.  Pass a field to
your display for the error message, and make it blank if theres no error.  
If you have conditional attributes (you need to make it flash sometimes,
but not always, or you need to make it reverse image sometimes, but not
always) you can pass a variable to the DSPATR keyword, rather than use
indicators.

I haven't found a good way to avoid the subfile indicators, tho.. :(

Otherwise, it looks good.  Your style of spacing & commenting is very
clean looking, and makes the code quite easy to follow.  I like the fact
that you're using standards for how to name your variables, it also helps,
even though its different than my standard.

For some reason, every time I see something like "$Company" or "$Title",
I think I'm reading perl code... :-)   (But thats probably because I was
working in perl this morning...)

HTH


+---
| 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
+---