× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.