RE: What are the benefits of ILE?

On Tue, 10 Jul 2001 SCarter@rsrcorp.com wrote:
> 
> I guess my question sparked more debate than I really intended....
> 
> What I was looking for is when do you decide something is right for a
> subprocedure or is it just so menial that it is silly to do this.
>

I think the problem with your original post (and the reason that I didn't
reply to it) was that you didn't clearly define what you meant by 'ILE'.

IMHO, a more productive way to ask the question would be to ask it like
this:

1) When is it appropriate to use RPG IV instead of RPG III?

   My answer:  Never use RPG III if RPG IV is available.  

         Just as you never use candles to light your home when
         electric light is available, you should never use RPG III
         when RPG IV is available.

2) Under which circumstances does it make more sense to use service
     programs instead of using a (dynamic) program call?

   My answer:  I generally like to break applications down into
     'programs' and 'tools'.  Each major application will have a
     whole set of utility routines that are meant to be called from
     other programs.  For example, an inventory routine might have
     a 'add_to_warehouse' routine a 'transfer_inventory' routine,
     a 'retrieve_inventory' routine and a 'remove_from_warehouse'
     routine.   Then, I write programs that utilize these routines
     and provide a higher-level user interface.

     If I decided to change these routines to be web-driven, or
     client/server GUI driven, all I'd have to do is re-write the
     'programs', I could re-use the lower-level 'tools'.


3) If I rewrite my system, what strategy should I use for activation
     groups?

     My Answer:  I generally have the first program called from a menu
         run in ACTGRP(*NEW), and the remainder use ACTGRP(*CALLER).
         In general, I don't find activation groups to be particularly
         useful.  The only time I ever use shared ODP's is with OPNQRYF,
         and that always involves one program doing a OPNQRYF and then
         calling another program.   Never needed to do anything more
         complicated that...   I basically use activation groups to
         ensure that the service programs that I called get ended when
         my programs end (even if they crash)  that's about it.


4) Should I use /copy members with prototypes to standardize the calling
     interface for programs and service programs.

      Answer:  Yes.  This makes things MUCH easier to maintain.  It
         also helps document how to call your routines.   If you use
         binding language source correctly for your service programs
         you can always make them backwards compatable, which eliminates
         a lot of bugs created by programmers who aren't as careful as
         they should be :)

There are a lot of ways you can do things, and most of them aren't "right"
or "wrong"...   But you should DEFINITELY at least TRY using the ILE
tools.   You'll never know if they're right or wrong for you until you've
done some real applications with them.

 
> My main focus is that the higher ups are talking about doing a rewrite of
> our system.....
> Most of the code is old (many of the dates in seu are 87 88), no use of
> copy books, no vendor software (all in house).
> 
> example 1:
> 
> Payroll system we have a program that creates a list for payroll personnel
> of who is going to be paid, how much and so on.
> The actual program uses the axact same code to actually write checks but in
> a different source... Obviously the problem
> here is that when some thing changes we have to change 2 seperate source
> file and recompile blah,blah,blah.
> This seem perfect for using subprocedures/service programs in a rewrite..
> 
> example 2:
> we want to standardize interfaces across the system.  is it worth it to
> create service programs to handle the screen interface
> or is this just an extra level of complexity that would get in the way?
> 

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