Re: DFTACTGRP(*NO) ACTGRP(*CALLER) was RE: More ILE 101

Scott Klement wrote:

> My purpose in posting to this thread (which
> I'm starting to feel was a big mistake) was to
> explain how actgrps work, so that people
> can understand them and make informed choices.

And I think you've done a good job of it!

> I don't really want to get into a fight about
> which way is "the best way." Every way has
> it's pros and cons, and every way is "the
> best way" in a particular circumstance.

Yes, exactly right!  The only reason I asked about the way you've arranged
your applications is to get a perspective on your system.  I completely
agree that there is no 'right' answer, and that what you've designed is
different from what I've designed.  I don't get the chance to mix with other
developers, and I'm taking advantage of the thread to take a peek into your
environment.

In that spirit, I won't drag the thread out.  Your description of your
environment was exactly what I was looking for.  I'll comment a bit on
*NEW/*CALLER only to show why that might be difficult in my environment.

[buck talking about implementing *NEW/*CALLER]
> > We have a user-defined menu system, and I can't
> > imagine how I would be able to get that done.  Sigh.
>
> Do you normally have a lot of programs running
> behind a single menu option?

Yes, that's the norm.  We have complex tasks to begin with, and Synon
generated tens and hundreds of subprograms.  It's very likely to have a call
stack over 20 deep not counting the subprograms which can call other
subprograms, etc.  Each program opens its own set of ODPs, meaning it's also
likely that a menu option will have 200+ files open.

> > ps - another good thread!
>
> I disagree.  We've discussed this exact same thing
> at least twice before, and any time a thread is rehashed,
> it's not good.

New interest can mean that new people have started using ILE, or perhaps
that we didn't do a good job the last round.  We see it as a re-hash, but a
newcomer might not have heard rounds one and two.

> This is perhaps worse because we're not just explaining
> how things work, but we're telling people how to use them.

I think it's difficult to convey the decision points to a newcomer.  That
is, why choose design A rather than design B.  So we fall into the trap of
trying to simplofy for an email list.  Or the readers fall into the trap of
taking advice and opinion as instructions to 'do it like this.'
  --buck