Repeatedly tried new sessions.
Loglvl is as you specify...it is our default.
What are you smoking Chuck? The rest of your message makes no sense. :-)
Entire contents of the message..."limit type 18" is not listed in this or any subsequent message:
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:
-- 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 see the previously listed message CPD4365.
-- Type 4 indicates that a journal error has occurred.
-- Type 5 indicates that the commit lock limit was exceeded.
-- Type 6 indicates that the maximum size of the table has been reached.
-- Type 7 indicates that the maximum size of the prepared statement area
has been reached.
-- Type 8 indicates that the maximum number of cursors have been opened
for this job.
-- Type 9 indicates that the maximum number of entries in the lock table
have been used for this job.
-- Type 12 indicates that the maximum DRDA communications buffer size was
exceeded.
-- Type 13 indicates that the maximum amount of blocked data was exceeded.
-- Type 14 indicates that the maximum amount of descriptor space has been
allocated.
-- Type 15 indicates that the maximum size of the parameter default area
has been reached.
Recovery . . . : Do one of the following: If this is error type 1, contact
the security officer to increase the user profile storage limit, or delete
some objects to free up storage and then try the request again.
-- If this is error type 2, then try the operation when the number of
machine locks held has decreased.
-- If this is error types 3, 4, or 5, see previously listed messages in
the job log for recovery information.
-- If this is error type 6, Some of the rows from this table must be moved
to another table.
-- If this is error type 7, issue a COMMIT or ROLLBACK without the HOLD
clause before issuing anymore PREPARE statements.
-- If this is error type 8, issue a CLOSE before issuing any more OPEN
statements.
-- If this is error type 9, issue a COMMIT or ROLLBACK without the HOLD
clause.
-- If this is error type 12, reduce the total size of column data supplied
with the SQL request.
-- If this is error type 13, reduce the number of rows in the block.
-- If this is error type 14, reduce the number of allocated descriptors
with the DEALLOCATE DESCRIPTOR statement.
-- If this is error type 15, simplify the parameter defaults.
Steve Needles
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, April 16, 2015 12:21 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: SQL0904 - Resource limit type 18 exceeded with reason code 1088611284.
On 16-Apr-2015 11:38 -0500, Needles,Stephen J wrote:
Never have I seen this before. Type 18 isn't defined in the message.
This is happening on a new piece of production code.
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.
Here is a code snippet from the debugging session:
d SQLString s 500 inz('')
<<SNIP>>
It failed at the "prepare LogInsert from :SQLString"
SQLString = 'insert into remote_machine.local_db.local_table
values(?,?,?,?,?,?,?,?,?,?,?,?,?,?)'
<<SNIP>>
Is the actual LOG(4 0 *SECLVL) spooled joblog available, 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.
--
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
