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