× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Anything of concern in here?
https://imgur.com/mUXwP37

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jay Vaughn
Sent: Wednesday, March 20, 2019 10:36 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: ACS Resource Limit Exceeded????

So i have the following query that calls a UDF... when I run in STRSQL, no problem... it works and my results are displayed as I'd expect.

When I run the same query in ACS, I get an Resource limit exceeded error with no results displayed... if I then go back to strsql and run the query I get the same error message again...

I have to recreate the UDF so that I can then run successfully again in STRSQL.

What does this mean?

Here is the query...

select borro00001
,lscnvtools.getNames(borro00001
,'FIRST')
,lscnvtools.getNames(borro00001
,'MIDDLE')
,lscnvtools.getNames(borro00001
,'LAST')
from lscnvtools.tfs0001


and here is the error from ACS regarding resource limit exceeded...

SQL State: 57011
Vendor Code: -904
Message: [SQL0904] Resource limit exceeded. Cause . . . . . : Resource
limit type 13 exceeded with reason code 423. 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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.