Re: Locked and yet not locked . . . .

On Sat, Oct 8, 2016 at 2:25 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

. . .

Any of those above three cases would have experienced the same effect as

described in the OP, as if the conflicting lock had never been dropped;
i.e. as if the file had never been closed by that job. In the two former
examples, that the file was never closed is the actual scenario. In the
latter example, only "as if" the file had never closed.

But as was noted in response to the OP, what other thread [in another
process] might have held a conflicting lock is anyone's guess; that some HA
software [or similar designed sfw] is known to give rise to such conflicts
by the nature of their performing work against just-created object [usu.
per tracking T-CO . There was nothing given to indicate what the script or
the CLP did, or if what either might have done might have caused another
process|thread to obtain the lock.

Greetings from New Orleans.

As I recall, if I went to member locks, it listed a member, but flat-out
refuesd to say what job held a lock on it.

Now the based-on PF was definitely in use by other jobs (both directly and
through native logicals), but I have no reason to expect the view to be in
use.

The CL program in which this is happening (and this is the only occasion
when I've seen it do this) had just successfully deleted the view (a DLTF,
as I recall, but I'm half a continent away from the source) and rebuilt it
and applied labels (using the RUNSQLSTM I think I had mentioned in the
original post), Then it apparently just sat there for a while, before
throwing the escape.

--
JHHL