|
----- Message from Mark Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>. . .
on Thu, 23 May 2019 14:37:34 +0000 (UTC) -----
To:
RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject:
Re: Service Program Limitations
Hi, Michael,
. . .
That is why, with V6R1, IBM added the *IMMED or *DEFER option to the
BNDSRVPGM parameter on CRTPGM, CRTSRVPGM, UPDPGM and UPDSRVPGM, and
ADDBNDDIRE. -- With the new *DEFER option, the IBM i system will
defer loading "A" until it is actually needed, e.g. when any of its
procedures are actually first called. And, if "A" was created with
the *DEFER option for "B", then "B" would not be loaded and
activated until actually needed, and so on, down the line, as long
as you specified *DEFER for all of them.
There is a slight overhead for the "stubs" generated to handle this,
when *DEFER is specified, but overall, this can be a big "win" when
many of those *SRVPGMs might never actually be needed in any given
job. This is a "Pay me now, or pay me later" trade-off. (Take the
"hit" when the job first starts up, vs. spreading that load across
the entire duration of the job.)
Note that *IMMED is the default, so the system continues to behave
as it always did, unless you take action to specify *DEFER as and
where needed on those binder commands.
Hope that helps,
Mark S. Waterbury
On Thursday, May 23, 2019, 10:26:07 AM EDT,
MichaelQuigley@xxxxxxxxxx <MichaelQuigley@xxxxxxxxxx> wrote:
of
While there may not be much in the way of an actual limit to the number
procedures in a service program, don't all procedures to throughIn
activation when a program with the *SRVPGM bound to it is first called?
the past I've experienced a noticeable delay to program startup when a
bound *SRVPGM had several extraneous procedures.
Michael Quigley
Computer Services
The Way International
As an Amazon Associate we earn from qualifying purchases.
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.