Re: SQL0904 - Resource limit type 18 exceeded with reason code 1088611284.

On 17-Apr-2015 08:57 -0500, Needles,Stephen J wrote:

On Thursday, April 16, 2015 2:17 PM CRPence wrote:

<<SNIP>> that said, I think the issue likely is related to the
three-part naming specified for the table-reference as target of
the INSERT statement being prepared. From the string to be prepared
'insert into remote_machine.local_db.local_table', does the Entry
REMOTE_MACHINE actually exist in the Work With Relational Database
Directory Entries (WRKRDBDIRE) with a valid\functional Remote
Location (RMTLOCNAME) on which a SQL Package (SQLPKG) can be
created implicitly.?

<<SNIP>>

FWiW: In the following quoted joblog snippet, the headings were not also included, thus we still are uninformed of the release; a snippet of what the expected headings might look like had they been included, is included preceding the quoted JL snippet, here:

57xxSS1 VxRyMz yymmdd Job Log
Job name . . . . . . . . . . : XYZ User . [...]
Job description . . . . . . : ABC Library [...]
MSGID TYPE SEV DATE TIME [...]

SQL0904 Diagnostic 30 04/17/15 07:38:49.714266
QSQROUTE QSYS *STMT QSQROUTE QSYS *STMT
From module . . . . . . . . : QSQROUTE
From procedure . . . . . . : NORMEXIT
Statement . . . . . . . . . : 23998
To module . . . . . . . . . : QSQROUTE
To procedure . . . . . . . : NORMEXIT
Statement . . . . . . . . . : 23998
Message . . . . : Resource limit exceeded.
Cause . . . . . : Resource limit type 18 exceeded with reason code
1088611284. <<SNIP>>

So in a symptom string form:
msgSQL0904 LT18 [RC18] rc1088611284
f/QSQROUTE fm/QSQROUTE fp/NORMEXIT stmt/23998

Hardly revealing, despite my allusions that having provided proper /context/ for the errors [as provided from the snippet from a spooled joblog], could help a reviewer of the failure to better understood :-(

In that scenario, both lacking a previously logged error [being left in the job message queue] and lacking any other indication of the source of the error other than a /normal exit/ from the SQL router, about the only other assist [from other than IBM; apparently a PMR already opened] likely requires some job trace output [tracing just the failing prepare]. There likely would be a message either visible in the trace data and\or an INTXHINV [¿or is that just INTHINV?] in the trace flow preceding the progression towards manifesting the SQLCODE -904 via the QSQROUTE; probably, the incident recorded in the trace [not manifest visibly] as a msg or an exception handler invocation, would be seen within the QSQPREP processing of the trace flow.

The remote_machine is properly defined.

I still suspect the issue might be related to the three-part naming and thus related to the implicit CONNECT [¿and implicit package creation?]; i.e. probably the underlying origin for the issue. If I were to attempt to further review the issue, I might try to create the program in different ways possibly with some source modifications, and test for the effect from the implemented changes; e.g.:
• compiled the same [presumably RDB(*LOCAL)], but with the three-part naming specifying the local RDB in the table-reference rather than naming remote_machine
• compiled the same [presumably RDB(*LOCAL)], but with the three-part naming specifying the RDB(MYSELF) in the table-reference rather than naming remote_machine; pre-requisite action: ADDRDBDIRE RDB(MYSELF) RMTLOCNAME(loopback *IP) PORT(*DRDA) TEXT('LoopBack: Redirect DRDA rqs to local DB')
• compile with RDB(remote_machine), but having removed the three-part name in the table-reference
• compile with RDB(MYSELF), but having removed the three-part name in the table-reference; pre-requisite action: ADDRDBDIRE RDB(MYSELF) RMTLOCNAME(loopback *IP) PORT(*DRDA) TEXT('LoopBack: Redirect DRDA rqs to local DB')

FWiW I actually found an APAR with a PTF SI46720 on C2279710 that seemed to match quite closely to the described scenario for two important details, PREPARE and -904, but the APAR lists different from-program and no RC\LmtTyp information; APAR SE51853 OSP-DB-QSQPREP-MSGSQL0904 WHEN PREPARING 3 PART NAMING STATEMENTS

FWiW: latest available r710 PTF from three distinct PTF chains [including the aforementioned PTF SI46720], each having potential applicability per the failing code path or having recorded a -904: SI55525 SI55614 SI55619