Re: SQL Cursors and *ENDMOD

Alan Campin wrote:

<<SNIP>> It appears that I was not closing an SQL cursor after I
was done with it.

If the cursor were not closed, neither explicitly nor implicitly, then the CLRPFM would be expected to fail since an open file.mbr can not be cleared. The clear PFM feature when issued against an open member, can function only if the open & its locks remain as a side effect of a close which left the cursor pseudo-closed. Even so, the CLRPFM works only after a full-close removes both the open & locks, and if no new opens have been activated since starting the async close. In a pseudo-close case, the conflicting lock request [by functions like clear, drop, alcobj rqsrls(*yes), etc.] signals the close-event, which enables an asynchronous close to be performed in the jobs which are holders of the locks [if held as pseudo-closed cursors].

My question with all of that is how *ENDMOD works. My
understanding of the close SQL Cursor option *ENDMOD is that at
the end of the module, ie when I return from the call to the
procedure in the module, that any SQL Cursors are closed but it
does not appear that was what was happening.

FWiW, IIRC the function of *ENDMOD changed in some manner. A search turned up APAR SE32185 [and sysroute SE31970] for 6.1 which suggests [somewhat OT] that release SQL PREPARE processing in an SQL PROCEDURE now defaults to *ENDMOD instead of *ENDACTGRP for compatibility with the other DB2 engines. However [possibly making it on-topic] it seems that the *ENDMOD [should we infer only for SQL PROCEDURE?] for prepared statements will [since its PTF] change to re-use an ODP similar to *ENDACTGRP.

<<SNIP>>

Apologies if that just confuses things. I have only ever used *ENDACTGRP, even what little I ever played with on v6r1.

Regards, Chuck