Re: SQL0901: "SQL system error" and MCH2601: "Lock enforcement rules broken when trying to access object &1"

FWiW concurrent updates to an access plan in the associated space of a program is designed to /fail/ with the MCH2601 [i.e. "presumed success" or "optimistic" coding style such that the code assumes locking will not be required and then mch2601 if it transpires], yet such a failed update should be ignored versus bubbling that error. So possibly the object &1 is the *PGM itself, for the attempted update to the query access plan, such that the query engine is improperly bubbling the error. That theory could be tested fairly easily such that if no error in the scenario is a somewhat safe implication that the AP update is the problem origin; that would be done by making three distinct copies of the same program by different qualified names where each program is run concurrently across three jobs each accessing different data versus the one program run concurrently across three jobs accessing different data. Or easier, the hex data for the mch2601 showing the object type x/0201 as the last two bytes would confirm a *PGM object was not properly allocated to enable an update, and a DMPOBJ of the *PGM would show if the hex data represents the address of that program.

However... That all seems unlikely, because the failing procedure name would hopefully be named something specific like Refresh_Access_Plan versus something so generic as the Resolve_System_Pointers.

Regards, Chuck

CRPence wrote:

Dan wrote:

We have a real mind-blower on our hands. We have an application which submits several jobs to the job queue, which allows up to three jobs to run simultaneously. The jobs run a program (the
same program using different data) which uses SQL *extensively*.
SQL INSERTS are performed on tables that exist in libraries that
are unique to each job. DECLARE CURSORs are defined with "FOR
READ ONLY". No explicit locking (i.e., ALCOBJ) is used.

<<SNIP>>

msgMCH2601 F/#cfochkr x/0B10 T/QQQVAP TM/QQQVAP TP/RESOLVE_SYSTEM_POINTERS stmt/4204
The error for QQQVALID is merely the effect of a "resignal
exception"; i.e. not much interest.
The msgCPF4204 is as worthless as *FC [aka CPF9999] because that is the generic "query processing failed" for which the prior
messages, usually the first escape in a series, is the actual issue; in this case, the first incident of MCH2601 recorded.

The failure is in the general "validate access plan" processing,
apparently in the more specific [but unfortunately still too
generally, in some] procedure which "resolves system pointers" to
some objects. Presumably "resolve system pointer" activity is
being performed for various objects named in the query, to which
the plan must associate.

<<SNIP>> The following can be done to enable seeing
the address which includes the object type:
chgmsgd mch2601 msgf(qcpfmsg) FMT((*HEX 16))

Regards, Chuck