Re: CGIDEV2 Object Lock Issue

On 3/10/11 6:58 AM, Kelley wrote:

I have a fairly simple CGIDEV2 program that reads through a file
using embedded SQL and displays information on the screen. The SQL
cursor is opened and closed in the same routine. The web page is
displayed after the SQL routine is completed.

A job that runs in the evening was not completing because the HTTP
server has a lock on the file.

Most likely the effect of a pseudo-closed cursor; i.e. the CLOSE is requested and effected as far as the program knows\understands, but the SQL leaves the query ODP [Open Data Path] for performance reasons, which is to avoid the requirement to perform a full-open again the next time the statement is performed, since the query [member] was never really closed.

Define "not completing"? The locks should be removed in most operations for which a conflicting lock is required; e.g. for RMVM, DLTF, etc.. What request could not complete; presumably for a "can not allocate" error.?

The only way to get rid of the lock is to shut down the HTTP server.

Probably not an accurate conclusion. See the ALCOBJ invocation Joep wrote about. However note that the specified lock-type must actually conflict for the CONFLICT(*RQSRLS) to effect anything. And of course as indirectly alluded by a question asked by Jack about using WRKOBJLCK after the ALCOBJ, the requester of the ALCOBJ would also want to issue DLCOBJ after whatever processing [other than RMVM or DLTF] is completed; or perhaps issued before starting processing, if no concern for the CGI job accessing and locking the file again before processing starts.

Is this normal? I'm new to CGIDEV2, am I missing a setting or command
somewhere that prevents this?

SQL pseudo-closed cursors are normal, and as enhancements to the SQL for performance are improved, more queries are able to take advantage of [thus others conflicting to be impacted by] the open [not fully closed cursor] remaining available for reuse by the SQL.

There are means to designate the scope of the open cursors. And again, most conflicting operations against a file for which pseudo-closed cursors exist will attempt automatically to remove those locks, thus the pseudo-closed cursors should not impact their activity. At least the following three exceptions exist for which the close will not or seem not to be effected:

- concurrent requests re-opening; obtaining a lock or leaving a lock from a pseudo-closed cursor
- too short of DFTWAIT() in the job performing work that conflicts with the pseudo-closed cursor lock to allow sufficient time for the close events to get processed by all of the jobs holding a pseudo-closed cursor lock
- the [unlikely] possibility that an exit point for the database SQL close event will block the close request(s) [e.g. for a specific file].

Regards, Chuck