Closing the cursor on the last iteration would release the implicit
allocation, wouldn't it?
The user would have to anticipate that the ALTER might have to wait to
acquire the exclusive lock. The application would need to release all
such explicit or implict allocations any time it went in to a wait
state. The ALTER would work in these gaps. I agree that there would
probably need to be some notification method to the application that
would induce it to enter a wait state and drop all allocations of the
file.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, May 11, 2009 7:12 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Stupid question of the century
Dan Kimmel wrote:
The way to do this is straightforward.
One. Redesign your application so it doesn't hold a lock on the file.
The key verb is "hold". Your application acquires a lock when it needs
one and releases it as soon as it can.
Two. Redesign your application so it is insensitive to changes in the
file.
With this done, an ALTER table or CHGPF can be done and your
application will wait while the change takes place (the change will
have an exclusive lock) and then resume.
Several ways to keep from holding a lock: CLOSE the file within your
program after every use and OPEN it only when needed. Use SQL SELECT
statements which don't hold a lock.
Use SQL CURSOR for read only.
To make your application insensitive to changes: Specify LVLCHK *NO on
compile and be careful not to change existing fields when adding a
field. Use embedded SQL with naming the individual fields (no *) in
the SELECT statements.
A read-only cursor is of no assistance because an /open file/ is an
implicitly allocated file, preventing an exclusive allocation of the
file by an ALTER request. There is no SQL SELECT that will avoid that
implicit lock; the alluded timely close is still the goal. Besides, a
database application is unlikely to be limited to inquiry-only, except
in a DW\BI setting; unlikely to be such a limited scope\concern of the
OP.
The application would effectively need to be able to effect
full-close for every data access which likely would be prohibitively
expensive. It would be better to code the application to receive a
signaled event to effect close; await a semaphore of /OK to open/ as
established by the changer, which in theory, could be the open-wait
timer set at the *FILE level in the *FILE object or an override.
The pseudo-close activated by the database SQL would be acceptable, if
not best, to implement such an event. An event would be effected by the
ALTER attempt due to its effective ALCOBJ CONFLICT(*RQSRLS).
However due to timing of new opens by the application, that would
probably require coding to the QDB_... SQL close event exit program to
effect some delay or other discouragement of the application to perform
any new opens, before all pseudo-closed across the system are completely
full-closed; i.e. coding to the exit program establishes the semaphore.
Of course the exit program is a feature of SQL access only; i.e. RLA
does not, can not, close its file in response to the SQL database close
event.
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
