Re: bnddir *SRVPGM *IMMED vs *DEFER

Slightly off-topic but related to previous comments about compile behavior:
the relatively-recent DCLPRCOPT is handy in that it can (among other
things) override the activation group specified on the compile command or
make a CL(LE) program run under the owner's authority, also a compile
option.

On Thu, Aug 26, 2021 at 8:23 AM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Don,

I advise against any "one size fits all" or "blanket" recommendations such
as changing ALL of your binding directory entries to specify "*DEFER" ...
and then re-binding all of your applications programs and service programs.

There is some (minimal) amount of extra overhead when using *DEFER --
because a small "dynamic loader stub" is bound into each program in place
of the dynamic linkage to each "target" service program. At runtime, when
the application calls any of the procedures or functions (entry points) in
this "stub" -- the "stub" code invokes the APIs needed to dynamically load
the actual "target" *SRVPGM needed, and then updates all of the procedure
pointers in an internal storage table so that any subsequent calls will
route directly to the target service program routines, and the stub then
transfers control to the desired procedure that caused this stub to be
invoked in the first place.

Applying *DEFER "everywhere" in a large application with many *SRVPGMs may
not be "a good idea" for the following reasons:

#1. Consider the impact of "testing" such as massive change. The "test"
team would need to re-test the ENTIRE application suite, after making such
a massive change to the code base.

#2. how will your team deploy and install such a massive change,
especially if you have the applications running on multiple "live"
production systems or LPARs, or if you distribute software to one or more
customer or client sites?

NOTE: do not attempt to change the way the IBM-supplied runtime routines
are bound.

"BEST PRACTICES" -- USE CASES:

In my opinion, *DEFER is best used only for certain situations, such as
for "error handling" routines that are only used when certain error
situations arise; that way, applications do not need to incur the overhead
of loading those "error handling" *SRVPGMs and initializing their static
storage, etc., for the majority of cases where those error situations never
occur or do not arise.

I hope that helps.

All the best,

Mark S. Waterbury

On Thursday, August 26, 2021, 01:54:30 AM EDT, Don Brown via RPG400-L <

rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

I have just had a look at our binding directories and all are *IMMED

Many were created long ago and I think new service programs have been
added just copying.

I also notice when doing a dspsrvpgm <service_program> that the IBM
service programs are also *IMMED

Example

Service
Program Library Activation
QRNXIE QSYS *IMMED
QRNXIO QSYS *IMMED
QRNXUTIL QSYS *IMMED

So from what I have read I should have no concern in changing our
application binding directory entries to *DEFER and recreating our service
programs ?

Is that correct ?

Thanks

Don
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com