RE: Statically binding multiple MAIN modules with display files

[Joel Cochran <jrc@xxxxxxxxxx>]

Joe,

Comments inline...

On Tue, 2004-01-20 at 21:32, Joe Pluta wrote:
> > From: Joel Cochran
> > 
> > By enclosing these in procedures, they become very modular:
> > 
> > <psuedo-code>
> > /free
> >   if sflOption = 2 ;
> >     invoiceUpdateScreen( myKeyValue );
> >   elseif sflOption = 3 ;
> >     invoiceCopyScreen( myKeyValue );
> >   elseif sflOption = 4 ;
> >     invoiceDeleteScreen( myKeyValue );
> >   elseif sflOption = 5 ;
> >     invoiceDisplayScreen( myKeyValue );
> >   endif ;
> > /end-free
> > </psudoe-code>
> 
> Sure, but you could do that just as easily with a prototype with EXTPGM,
> couldn't you?

Yes you could.  That's why I said this could be replicated with Dynamic
Calls.

> > Can this be replicated with Dynamic calls?  Sure, but so can almost
> > anything on an academic level.  This just makes sense to me in this
> age
> > of modular design.
> 
> It's always been my contention that programs *are* modular.  There are
> places where procedures are better suited, but this doesn't seem to be
> the place, to me.

Tomato, Tomahto.  Programs are modular in the sense that anything
anytime anywhere can call one.  That doesn't technically make them the
building blocks of a program.  I guess when I say modular I mean pieces
bound together to create a program object.

I think that most anything I'm not going to call from a menu or a
command line is well suited to a service program :-D .

> > Naturally you can include whatever kind of return
> > value suits your needs which makes it nice in embedded statements:
> > 
> > <psuedo-code>
> >   /free
> >     if invoiceItemDeleted( myKeyValue );
> >       // do additional stuff
> >     endif ;
> >   /end-free
> > </psuedo-code>
> > 
> > Necessary? No, just nice and fairly clean.  And of course, with
> *CALLER
> > activation group the service program is pretty fast.
> 
> This is the only real benefit of a procedure - the fact that it can
> return a value.  But given the bidirectional nature of parms, it's not
> much different:
> 
> >     rc = invoiceItemDeleted( myKeyValue );
> >     if rc;
> 
> It does require the extra data definition, though, and from that
> standpoint I can see the issue.  So I guess it's just a matter of taste
> at that point.

I don't know if this is the *only* benefit of procedures, at least not
ones in service programs.  For one thing, if the signature of a service
program changes, you get a signature violation from the calling program
if you haven't updated it.  No such safeguard with a dynamically called
program.  To be fair, you can likewise cause a problem if you DON'T
change the signature of a service program either but you do alter the
procedure in question. I'm not picking on the compiler guys, but I think
this is a major flaw right now - signatures could be significantly
improved - but I digress.

I still think there will be a performance hit if you use a dynamic call,
certainly if the called program is created using ACTGRP(*NEW).  If it is
named it wouldn't be so bad, it might even be an improvement over
*CALLER.

All that being said, I would probably agree that it is largely a matter
of preference.

> Service programs are a different animal, anyway.  I was asking about
> static binding, which to me just doesn't make sense.  If you have the
> same program statically bound into 15 calling programs, then you have 15
> different copies of the program in your PAG, and potentially 15
> DIFFERENT copies.

I was responding mostly to Scott M.'s statement that putting them into
service programs didn't make sense to him.  

Yes, static binding sucks.  I would rather live on a diet of rancid pork
and lumpy milk than maintain a lot of programs statically bound with
multiple modules.  
> 
> Joe

A pleasure as always, Joe!

Joel
http://www.rpgnext.com