I'm in the process of testing an application and have noticed that if a
file is locked (e.g., *EXCL during nightly backup) on a select query,
which returns an iDB2Exception with a message code of -913, then after the
file is deallocated, a subsequent query against the file results in the
QZDASOINIT job servicing the .NET data provider, placing a *SHRRD lock on
the file. The lock exists even if the connection object is subsequently
closed and then disposed of. The only way it is removed is if the .NET
application is terminated. Under normal circumstances (i.e., no previous
file lock), the select query does not result in a file lock on the part of
the QZDASOINIT job, so this issue doesn't seem to be a result of a bug in
my code.

Has anyone encountered this phenomenon? Given the sequence of events, the
likely hood of the .NET application creating a file lock is probably
remote. Nevertheless, I would like to prevent such behavior because of the
possibility of interference with backups and system maintenance is a
possibility given that the application will be in use round the clock. Any
suggestions would be appreciated. Also, I am using the 6.1 data provider
with the latest PTF.


This thread ...

Return to Archive home page | Return to MIDRANGE.COM home page