Thanks Chuck!
Please don't take my teasing personally!
I provided all of the information at hand in the original post. There was nothing except the SQL0904 error listed in the joblog. I hear what you are saying concerning the potential differences in the presentation of the joblog data from the print screen to the printed version...so I reran it this morning...a portion of the printed version is below. The SQL7948 is from an earlier SET statement that is grabbing the current time and assigning it to an RPG variable. (exec sql set :CurrentTime = Current_Timestamp;) which is successful. There do not appear to be any previous, pertinent messages.
:
:
SQL7948 Completion 00 04/17/15 07:38:41.846478 QSQROUTE QSYS *STMT QSQROUTE QSYS *STMT
From module . . . . . . . . : QSQROUTE
From procedure . . . . . . : NORMEXIT
Statement . . . . . . . . . : 23998
To module . . . . . . . . . : QSQROUTE
To procedure . . . . . . . : NORMEXIT
Statement . . . . . . . . . : 23998
Message . . . . : SET statement complete.
Cause . . . . . : The variable was successfully set.
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. A list of the limit types follows: -- Type 1 indicates that the
user profile storage limit or the machine storage limit was exceeded. --
Type 2 indicates that the machine lock limit was exceeded. -- Type 3
indicates that the query resource limit was exceeded. For more information
:
:
The remote_machine is properly defined.
Steve Needles
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, April 16, 2015 2:17 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: SQL0904 - Resource limit type 18 exceeded with reason code 1088611284.
On 16-Apr-2015 12:27 -0500, Needles,Stephen J wrote:
On 16-Apr-2015 12:20 -0500, CRPence wrote:
I would be sure to try a fresh test, an invocation after a new
signon, to be sure no issues with the compile\debug\actgrp activity
in the same job might play any role in the origin for the error.
Repeatedly tried new sessions.
Is the actual LOG(4 0 *SECLVL) spooled joblog available,
Loglvl is as you specify...it is our default.
including from the request message that reveals the the program with
the PREPARE of the dynamic SQL being invoked, up until the
msgSQL0901 LT18 [RC18] with the [apparently uninitialized, with
apparent string value " STU", and thus bogus\] unreasonable reason
code value? Often times there will be an
accompanying\previously-listed message, and even if not, the
/context/ of a -904 condition might be more revealing than having no
context from a spooled joblog; something might be inferred from the
procedure+module+program names that issue the message or the program
to which the message, though for the PREPARE all but the sending
procedure might reveal nothing more than QSQPREP to confirm the
failing statement.
What are you smoking Chuck? The rest of your message makes no sense.
:-)
Sorry. I sometimes tend not to give much thought about whether a reader might understand what I am writing, when too little information was given in an OP; in part, because I may intend more to record the problem [with symptoms rather than message identifiers or message text] in order to make the incident more capable of being searched while also enabling omission of references that are not symptomatic, than to solicit any particular response to those comments.
In this case however, I should have concluded my question "Is the actual LOG(4 0 *SECLVL) spooled joblog available" with a question-mark; I should have written separately, with at least a blank line as a separator, all of that additional commentary.
The gist is that the spooled joblog, not having been provided, lacks sufficient detail to enable anyone properly to review the failure.
Embedded in the question of availability of the joblog are:
* An allusion to inclusion of the portion of the joblog that would include the Request Message up until the error Message ID SQL0904.
* Restatement of the error message SQL0904 in symptom-keyword-form to denote the topic is about a symptom rather than a general reference to that message identifier
* An allusion to the &n of the "reason code &n" having apparent invalid replacement text, for which &n is likely defined as *INT4, for which the replacement data is apparently the hex string 0x40E2E2E4 which is the character string " STU"; i.e. in all likelihood, the data referred to by the program filling the replacement text had incorrectly placed actual character string data instead of the intended integer data.
Following that is an explanation why the spooled joblog might be
important:
* the error message SQL0904 may have preceding error messages that diagnose the origin for the SQL condition being diagnosed
* the SQL condition being diagnosed is also known as SQLCODE=-904
* a joblog provides some "context" for the errors, because the joblog is laid out as successive messages; the Request Message is the command-line CL-request which is likely a CALL PGM(theDynSQLpgm), and the messages logged to the program-message-queues will be logged as those successive messages following a Request Message
* what defines "context" is the combination of Procedure-name, Module-name, and Program-name for both the issuer and the recipient of a message; unstated was that a Statement-number or Instruction-number might be additionally informative [to the developer owning those programs\program-sources], but not so meaningful to the diaspora; as well, a hint that a Program-name is not as useful as Procedure-names and Module-names when the executable is ILE vs OPM.
Entire contents of the message..."limit type 18" is not listed in this
or any subsequent message:
FWiW I realized an additional message was unlikely to document the
LT18 [what Rob alluded]. What I had alluded, was that the particular failure SQLCODE=-904 often is _preceded_ by another error message that will have been logged and never-since deleted by the program that issued the message SQL0904. If such a message exists, the message should be logged after the Request Message and before the following:
Message ID . . . . . . : SQL0904 Severity . . : 30
Message type . . . . . : Diagnostic
Date sent . . . . . . : 04/16/15 Time sent . : 12:20:10
Message . . . . : Resource limit exceeded.
Cause . . . . . : Resource limit type 18 exceeded with reason code
1088611284. A list of the limit types follows:
<<SNIP 1-14; conspicuously absent is "Type 18...">>
-- Type 15 indicates that the maximum size of the parameter
default area has been reached.
Recovery . . . : Do one of the following:
<<SNIP 1-14; conspicuously absent is "If this is Type 18">>
-- If this is error type 15, simplify the parameter defaults.
A copy\paste from the Command Entry [command scripting area] of an interactive session is not a _spooled joblog_; the copy\paste from there is lacking the _context_ that is important for a reader to better understand. The Request message is not included, nor are the QPJOBLOG spool file header lines that include the release information, and all of the data under the following headings are not available:
FROM PGM LIBRARY INST TO PGM LIBRARY INST
So, the copy\paste needs to be taken from the spooled joblog, in order to include all of what is desirable for a reviewer.
All 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.?
--
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
