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.?
midrange.com
