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
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].