RE: CRTDUPOBJ an ILE program

[Scott Klement <klemscot@xxxxxxxxxxxx>]

How about we change our philosophy to be the "top-level ILE program"
instead of merely the "top-level program"?


On Wed, 12 Mar 2003, Buck Calabro wrote:

> >> *CALLER puts us in the DAG under these scenarios.  I don't
> >>see that as desirable, but perhaps I'm operating under
> >>more obsolete assumptions?
> >
> >I guess I'm confused now, Buck.  How in the world did the DAG
> >get in the picture?  We were talking about an all ILE
> >environment, *NEW for top level, *CALLER for everything else.
> >Where does the DAG come from?
>
> My very first line was: "How about this?  First step into ILE.  Programmer
> adds her first subprocedure to an RPG IV program.  There's literally only
> one ILE program in the application."
> The DAG comes into play because the entire application is OPM _except_ the
> very first RPG IV ILE program.  After all, there's a first program for us
> all...
>
> Carrying on the idea of evolutionary change (as opposed to constructing an
> all-ILE application from the ground up) I added "Time passes.  Our intrepid
> programmer has become comfortable with subprocedures and has written her
> first service program.  She hasn't had to touch the top level of the
> application; just a dozen programs at different stages throughout the
> application."
>
> So now, the entire application is OPM/DAG with the exception of a few
> scattered ILE programs and a single supporting service program.  Again,
> moving incrementally, creating the first service program in the company.
>
> The picture is one of slow acceptance of ILE, converting individual programs
> as maintenance is required.  In such an environment, it seems difficult to
> be able to pick good candidates for *NEW/*CALLER.  It seems to me that most
> RPG shops are in this position, rather than being all-ILE.  I might be
> reading too much into the original question, but it seemed like the original
> questioner is in this situation.  OPM programs requiring support of
> recursive calls.
>