On 12-Aug-2014 13:14 -0500, Steinmetz, Paul wrote:
I'm upgrading a 3rd party tool later today, RXS 2.71 to 3.11.
The upgrade is simple, RSTOBJ from a savf to the RXS library, about
70 objects. Takes about 10 seconds.
The issue is we have no easy way of knowing what programs of ours
should be stopped/started
The main RXS object is RXSSV *SRVPGM, which is part of BNDDIR RXSBND
1) Is there a command or tool that would show any reference or call
to this program?
I would hope that tooling that delivers an /upgrade/ in that manner
would have provided a Work Object Lock (WRKOBJLCK) or some other means
to determine what processes are actively using the feature *if* they
intended to allow for a non-dedicated install\upgrade.
2) If an RPGLE program is in memory, but not currently used, if this
object is replaced by the upgrade, the reference to this program
will probably result in failure, correct?
If active on the stack, the process will terminate when the next
instruction is executed. If not on the stack, then the effect depends
on whether access is dynamic or static for the process. For dynamic
calls, the old code will be entering new code that may or may not be
compatible so the results are unpredictable. For static calls wherein
the invocation is by address, the error will be a MCH3402 due to the
object at that pointer having been destroyed previously.
If the calls are static\by-address, then knowing what programs are
active is not an issue. Whereas the executable objects on media would
effect a destroy\delete of the objects on disk as part of /restore/ of
those objects, those objects can be proactively moved and\or renamed
[much like /replace object/ (QRPLOBJ) processing] to ensure the address
is not destroyed, and any old code will continue to invoke the old code
that is since relocated. Of course if the tooling has any feature that
depends on the object name being unchanged [e.g. relative call stack
entry messaging using a /name/ to identify invocation level], then only
moving is better. Less likely that they would have any dependencies on
where the code is located, but even that is a potential issue.