Version 7.2...sorry...I usually don't forget to include that.
Steve Needles
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, April 17, 2015 1:26 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
________________________________
This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies.
TRVDiscDefault::1201
midrange.com
