×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.