I'm having a hard time following the passive tone, but I think you're
saying that the locks I'm seeing are the result of leaving cursors open.
That is not the case. This issue happens when cursors are closed, and
we've also taken the added precaution of using the following parm in our
CRTSQLRPGI - CLOSSQLCSR(*ENDMOD).
Many of our users stay logged in for days at a time, and if you wish to add
a field to a file, you need exclusive access to the file, or so I thought
until just now (reference next paragraph). There may be no one in the
program, but they used it once some time ago, so there is this ODP lock and
an exclusive lock cannot be obtained.
I did not know about the extended parm on the ALCOBJ command for CONFLICT
(*RQSRLS). I did a quick test, and it does appear to release the lock in
another job where the lock is due to the SQL ODP, so that gives me
something interesting to play with. Perhaps the ODP can be cleared without
ending a job? That's a new concept to me.
From: CRPence <crpbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 10/29/2015 02:46 PM
Subject: Re: ILE program with ACTGRP(*CALLER) called from *DFTACTGRP
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
On 28-Oct-2015 12:21 -0500, darren wrote:
As to the *INLR closing files, yes the files will be closed in any
activation group, however, I've found that if you use SQL, there are
persistent access paths that leave low level locks on files you've
referenced after a program ends. For this reason, I prefer to
actually live in the 7th sin listed in Charles's link, ACTGRP(*NEW).
Presumably that would be the effect of pseudo-closed cursors. Thus
to clarify, rather than each being an Access Path, each is an Open Data
Path (ODP) that was left open [remain\persistent], instead of having
been closed. And, the locks would be the /normal/ locks, as for any
other Open. By not closing, both the use of temporary addresses and the
actions of the creation and the destruction of the temporary object(s)
that constitute each ODP could be additional resources that will not be
consumed, for each time the ODP is later reused. Anyhow, and if so:
That is a strategy [i.e. choosing to use ACTGRP(*NEW)] that is quite
capable of defeating attempts by the SQL to achieve better performance
for the /repeated/ query requests performed by the program.
Some might prefer instead, just to code an occasional request within
their programs to perform open_then_close(array_of_files) in order to
mimic a similar effect ;-)
There are others however, who understand that those locks are almost
never of any consequence, and in situations where they may be of concern
[of note, that should be restricted to only non-SQL requests], the
simple request to Allocate Object (ALCOBJ) using the Request Release
(RQSRLS) as the Lock Conflict Action (CONFLICT) [followed by the
respective Deallocate Object (DLCOBJ) request] can effect the removal of
those locks [by effecting the full-close] from within the job that wants
to access the file.
--
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
