How To Limit The Number Of Host Server Jobs (Connections)

The host servers use prestart jobs and most of them run out of the QUSRWRK subsystem.  So it isn't practical to limit the maximum number of active jobs for the subsystem because that would impact other server jobs rather than just the one that we want to limit. Prestart jobs are controlled and limited by their prestart job entry that is part of the subsystem description. So we start by setting the maximum number of jobs for the QZDASOINIT prestart job entry in the QUSRWRK subsystem:

So now we have a limit of 2000 QZDASOINIT prestart jobs active in the QUSRWRK subsystem at a time.  You might believe that the work is complete but it isn't quite that simple. The host servers were designed to be able to work even if the subsystem that the prestart jobs normally run in is not active or cannot start any more prestart jobs. When that an incoming connection request cannot be attached to a prestart job, the default behavior for the host server is to create a batch immediate job in the subsystem that the request comes from. Normally that subsystem would be the one that the host server daemon job runs in. That's because the requests for new connections are usually coming through the daemon (see note 1).  If this is the only change made, the system might get up to 2000 QZDASOINIT prestart jobs active at a time but the next request for another database connection would not result in a rejection. It causes the daemon to create a QZDASOINIT batch immediate job in the QSERVER subsystem and you have 2001 active QZDASOINIT jobs.

To prevent the daemon from accepting the requests when prestart jobs are not available, we must modify the host server behavior by using Navigator for i. Expand the Network section:

Then "Servers" and "IBM Host Servers". Select "Database", then "Actions" and "Subsystem Routing". Set "Allow Rollover" to "Reject".

If you open "Subsystem Routing" and find that it is customized and the 'Specific client' option is selected, then it becomes more complicated.  In this case, there are multiple subsystems in which the prestart jobs are defined and each of those prestart job entries need to be limited.  Every entry listed under 'Specific client' including the <public> entry must have the "Allow Rollover" option set to "Reject".

With these modifications made, you have now limited the total number of QZDASOINIT jobs allowed to be active on the system at any one time.

1 - The exception to this rule is when the connection comes from an application running on the IBM i that is using the toolbox JDBC driver to make a connection to the local system. In that case the batch immediate job starts in the subsystem that the job running the JVM is running in...there is no way to prevent this from happening.

Instructions for the deprecated Heritage version of Navigator for i:

Expand the Network then Servers options and then click 'IBM i Access Servers.

Click the checkbox next to Database then select Properties from the Actions list (see Fig.1)

Fig. 1

In the properties pane, click the Subsystems tab on the left side and again, select 'All clients' and change the value for 'Alternate action' to Reject (see Fig. 2)

Fig. 2