Chuck,
Thanks for explanation.
Unfortunately, WRKOBJLCK is only valid for files (PF, LF, DSPF etc,) not for programs.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, August 12, 2014 4:43 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Identifying all references to a currently active program
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.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
