Re: Identifying all references to a currently active program

On 12-Aug-2014 15:48 -0500, Steinmetz, Paul wrote:

CRPence on Tuesday, August 12, 2014 4:43 PM wrote:

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.

Thanks for explanation.
Unfortunately, WRKOBJLCK is only valid for files (PF, LF, DSPF etc,)
not for programs.

I am quite aware of that as a default behavior of the OS. What I am suggesting, is that a tool-provider _should provide_ a means to detect if their tooling is active in any processes [in the described scenario].

One such means is to ensure that any activation would always update the Product Library in the job; but ever since the system value Library Locking Level (QLIBLCKLVL), that is not a /sure thing/. But their tooling could, despite that invoking program does not effect a lock of the executable [being obtained per the OS], their code could issue the Allocate Object (ALCOBJ) of the object as their primary entry point into their tooling or even lock their effective product library; or they could provide something entirely different than locking, although locks are /nice/ in that regard, because they disappear when the job does.

So... if *they* provide for an /upgrade/ that should be allowed both non-dedicated and effected with Restore Object (RSTOBJ) [instead of providing their own program that performs the upgrade safely without impacts to other processes, or using PTF apply processing that they have designed to allow *IMMED-apply], then *they* should enable *you* to avoid the problems that RSTOBJ might cause to *your* actively running system. Insisting that the upgrade must be performed in a true dedicated-state is another option, but if they say the feature can be upgraded when /nobody is using the application/, then one would hope that they can give you the means to identify that indeed /nobody/ is using the application [and users are henceforth prevented from starting the application, since that inquiry, lest the temporal condition of not-in-use could become no longer true].