As suggested package those connections in a dedicated subsystem by IP address (subsystem that you can use for "bad behaved" remote connections).Then give the characteristic you want to the jobs there, number of prestart, timeslices, priority etc. Done. You can even pin them to a single core if you have multiple cores available for even better capping.
For some reason SBS are apparently an underappreciated concept in many shops, the same shop then ironically avidly using "isolation" like containers in other platforms like a panacea (subsystems are much more elegant and to be honest an abstraction at the correct layer).
On Tuesday, December 30, 2025 at 12:54:03 AM GMT+1, <smith5646midrange@xxxxxxxxx> wrote:
I agree that this is a whole lot f messed up. They think that having way too many open threads is Ok and they will not self limit. We bring the number of threads down and then they add another file and open another 5-10 threads for it. By going this route, we don't have to police things. The system will do it automatically. They will either learn to control their threads or deal with aborted connections. Either way, we are making it their problem instead of ours.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Richard Schoen
Sent: Monday, December 29, 2025 3:55 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Blocking excessive JDBC connections
This seems a whole lot of messed up.
Why can’t they just self-limit their process since they plan to put logic in to look for a 6th connect attempt to fail ?
It does sound like a combination of exit point logic and some SQL Services might be able to see how many connections open from an IP address if they really CANT limit trying to open too many connections.
Feels like super-sloppy DB coding to me. Why not just fix their app since it sounds like they plan to code to accommodate the 6th connect failure ?
Anyway:
In your exit point you would probably have to use something like an SQL Service to see how many connections from that IP address on the DB port. When could exceeds 5, kick it out.
I don’t know of any good example but Fortra, Kisco and others have commercial products you can plug in quickly.
Regards,
Richard Schoen
Web:
http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
----------------------------------------------------------------------
message: 1
date: Sun, 28 Dec 2025 16:59:31 -0500
from: smith5646midrange@xxxxxxxxx
subject: Blocking excessive JDBC connections
My client has a problem where non-IBMi applications (Windows servers) are creating MANY JDBC connections to pull data.one file is 98G and is pulled in full every day. Their app needs to finish faster so they create additional threads to bust up the file but they never talk to us about it first. Our system currently sits at over 100% CPU for hours at a time while these JDBC connections are active. Last night it was 4+ hours at 150+%. This is impacting other IBMi programs.
There is a whole lot wrong with that previous paragraph and we are actively working on the root of the problem but it is a long process getting it changed. I don't need help fixing that part of the problem so please don't offer solutions for it.
The problem that I am trying to solve is how to limit the number of JDBC connections from a single IP address. They are connecting through a job named QRWTSVR (or something close to that). When I look at the joblog, I can see what IP address did the connection. I have gotten permission to limit an IP address to 5 threads and if they try to open a sixth, it will fail. This sixth connection's failure assumes all of the first five jobs are still active. If one has ended / disconnected, the sixth connection should be allowed. My problem is how can I do it? Is there a way through an exit point? I've been looking but not finding anything. The exit points that I have found do not show me the job information.
Does anybody have any thoughts that I can research to find a way do to this?
--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
