Re: Close SQL Cursor without Ending Module

On 05 Dec 2012 14:56, Charles Wilt wrote:

Good point about CLRPFM signaling the close event...

That means that if the job issuing the CLRPFM (or is it the file
the CLRPFM is issued against?) was configured to wait for locks...
the CLRPFM would work...

Chuck, perhaps you could expand on that as I'm guessing you'll be
able to off the top of your head whereas I'd have to look it up. :)

<<SNIP>>

The waiter is the issuer of the CLRPFM, who is the signaler of the SQL database full-close event. The wait time is either the DFTWAIT of the job or the WAITFILE for the file; I do not recall :-( If the latter, then the physical attribute rather than any overridden WAITFILE value is used. There are some oddities in the design, and although WAITFILE is designed to be used for "open", I think that value is also used for the wait timeout value elsewhere; e.g. on the lock request for the CLRPFM, pending the full-close activity that must take place in all of the jobs holding a pseudo-closed cursor. Note: many releases ago the default for WAITFILE [on SQL CREATE and CRTPF\CRTLF] was changed to 30 from *IMMED; old database files may have the old default and could benefit from change.

If the signaled job is /busy/ [masked or operating in LIC] or overly constrained [e.g. starved for memory or CPU] such that its close is effected too slowly, the requester of the full-close event must wait that much longer... and may possibly exceed its timeout value. The ALCOBJ has its own WAIT value, so its manner of operation in this regard, is conspicuous.

In another message I had alluded to a loop [in a sentence where I apparently dropped some words] being origin for a race between full close and new pseudo closed cursors. But the same race exists across many jobs; i.e. any other newer jobs or existing jobs newly hitting the OPEN and [pseudo] CLOSE to effect a new pseudo-closed cursor, just an instant after the event is signaled until the entire time the signaling job remains waiting, will introduce a new conflict :-( Any OPEN [native or SQL] that is not then either closed or pseudo closed, will properly prevent the conflicting operations the same as normal; i.e. CPF3202 or CPF3130, because the full-close event will not have any effect on the [non-pseudo-closed] open in that job. IIRC the event is signaled to all jobs with an open, irrespective of the type of open; SQL or native, no matter.