Re: ILE Conversion -- RPG400-L

Although I, myself, have not read this book nor this chapter, by the 
descriptions
you're talking about I'm 99% positive I know what it's talking about, and I 
agree
that it works for large applications.

I had one system I had written on a PC that started out small (inventory 
control)
then got added to and added to over the years til it was fairly large, 250+
programs, but not humongous.  I found that it took me forever to add or change
anything, as I then had to hunt all over the place to find other referances.

By using procedures in a logical fashion, I was soon able to add/change or 
maintain
anything in one spot and not have to worry about the consequences.

One of the things I did, that I considered novel, was to add all related user 
I/O to a certain
file in one spot, one procedure in fact.  Such as the customer file, had a 
procedure
called CustomerFile that accepted a number of parameters.  One of the parameters
was what was to be done to the file, Add, change or delete.  Then one parameter 
was
the customer number and so on.  This one procedure then showed the customer 
entry
screen and enabled/disabled editing based on Add/Change/Display or Delete, and 
called up the
customer if it needed to.  I then found it was extremly simple to change my 
customer
file by adding a field to the customer file itself, and then adding the field 
to this one procedure,
then changing the few programs that would use this new variable.  So, with 3 
changes, I was
able to change the whole system.  I recompiled 2 objects (the program and the 
library with
the customerfile call) and was done.

The users loved it, because now I could make any changes they wanted in nothing 
flat.

This might be a little problem in RPG, however, as in RPG you would have to 
recompile every
program that used the customer file.  Unless you did the only read logical 
approach, then it
would work the same way.

And, you would soon find that it is now extremly easy to call up the customer 
screen anywhere
you wanted by making one simple call.  You would then find yourself adding 
promptable fields
wherever the customer number was required.

IMO, it is definately the way to go if you can.  It is a bit difficult to do to 
existing full blown
packages, although it can be done.  I wound up retrofitting my system, and then 
a few years
down the line someone else's system who I was then working for.  They loved it 
too, this being
a comercial software package that just saved them so much money every year on 
maintaining
code.

Regards,

Jim Langston

Jon.Paris@hal.it wrote:

>  >> I read the chapter in the Redbook about it and it seems interesting
> however it also seems like a lot of work to implement.
>
> I guess it is but it is very much in the "pay me now or pay me later"
> category.  Since you'll be doing a full functional decomposition anyway I
> doubt that it would be much more work.  The intent is to improve
> maintainability and simplify the testing part of development.  You finish
> up with a mainline that "reads" much like a pseudocode definiton of the
> program - much easier to maintain.
>
> One company we came upon reduced their maintenance load by 50% by adopting
> these kinds of approach.

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