RE: More ILE 101

[Joel Cochran <jrc@xxxxxxxxxx>]

On Mon, 2004-04-12 at 21:51, Joe Pluta wrote:
> I look at things a little differently, since I'm an old application
> programmer.  I separate programs into "top-level" and "subprograms".

I try to make anything not called from a command line a service
program.  This is just a guideline, but typically if a program requires
parameters and is always called from something else, then it can live
happily in a service program, which helps with binding and maintenance
down the road.  Replace "subprogram" with "Service Program" and you are
basically there.

> Now, for tools, the only reason I have subprograms is because I don't
> use service programs, so that situation resolves to yours in the long
> run anyway.  The tool programs (ones invoked by commands) are
> ACTGRP(*NEW), and the subprograms (which -should- grow up to be service
> programs someday) are set up as *CALLER.

Yes, very similar.  You don't yet have the benefits of UPDSRVPGM or any
of the other service program goodies, but structurally we are trying to
accomplish the same thing.

> With application suites, though, it's different.  I tend to set up the
> main menu as *NEW, and let everything else live in *CALLER.  This has
> pros and cons, I'd guess, but it prevents a lot of new activation
> groups.  Of course, for this purpose, I guess a named activation group
> ("APPL"?) would be just as good.
> 
> Joe

For an application, you could use a named activation group and run
everything for the application in that group.  The only problem with
running *CALLER for programs is taht you could inadvertently run them in
the DAG, the conversation of which started this whole thread.  By
specifying either a name or *NEW then at least you know at development
time what exactly to expect at run-time.  Of course, it goes without
saying that you need to understand that behavior when you are
developing, especially anything that runs in a named group, or
unexpected results may occur.

Joel
http://www.rpgnext.com