Hi, Nathan:
I am (now) following this thread with great interest.
What did you specify for "Allow reinitialization" ALWRINZ on the
CRTSRVPGM command? *YES or *NO
ALWRINZ(*YES) will allow you to "re-load" and "re-initialize" a service
program so it looks like it was just re-activated anew ... read the
help text for that keyword on the CRTSRVPGM command. This allows the
system to "re-initialize" the static storage for a *SRVPGM, even though
that *SRVPGM has already been "activated" within the AG. (This might
be what Alan Campin is referring to as a "re-load"...).
Also, you should be using REPLACE(*YES) on CRTSRVPGM or UPDSRVPGM when
replacing one that might be "activated" in some jobs with a new copy,
so you don't "pull the rug out from under" those jobs. Just like
with *PGMs, the old version is renamed and moved into the QRPLOBJ
library that is normally cleared on IPL.
Review the ILE Concepts manual. There is "by design" no way to
"deactivate" an individual service program (easily), especially if they
ever get actrivated in the default activation group (*DFTACTGRP).
The whole point of an "activation group" whether named or *NEW, is to
"draw a box" around some resources, such as, for a NEP, that should
include any dynamic memory allocated from the ILE (per AG) heap, for
the NEP itself and any *SRVPGMs it uses.Then, when you "tear down" the
AG, either by exiting the NEP for a *NEW AG, or by issuing RCLACTGRP
fora named AG, or at job end, the operating system will then "free" all
of those resources allocated within that AG automatically.
You can save the pointer from the first RSLVSP, and then when you do a
subsequent RSLVSP, you can compare the two pointers for "equality" to
determine if they both point to the same object (version). If they are
equal, the object has not been replaced or recompiled, and I would
question the need or rationale for trying to "deactivate" it and
restarting it.
Rationale?
At the "application" level, what are you really trying to accomplish by
doing this? Just re-loading a *SRVPGM will not "free" all resources
(heap space, etc.) allocated by a prior incarnation of that service
program. You would still need to "tear down" the entire Activation
Group to do that.
Why do you feel you need to do a RSLVSP to each *SRVPGM and then have
to resolve the entry points (procedures) within them dynamically,
versus just using the relatively newer *DEFER option on the BNDSRVPGM
parameter of CRTPGM or CRTSRVPGM as of V6R1 and above?
The more you can tell us about the "application scenarios" (what you
are trying to do and why), the better we may be able to suggest some
real alternatives.
All the best,
Mark S. Waterbury
> On 5/8/2017 6:49 PM, Nathan Andelin wrote:
If what you are saying is true, nothing would ever get re-loaded
and the users would always have the the wrong version but that doesn't
happen. The new version is loaded and processing is done using the new
version
Your assertion that RSLVSP returns a new object pointer when services
programs are recreated and updated makes sense, intuitively. However, when
I used debug to display the code, the old code appeared instead of the new.
I should return and do more testing, based on your assurances.
midrange.com
