QZRCSRVS QUSER 582450 PJ ACTIVE 01/27/11
QZRCSRVS QUSER 497834 PJ ACTIVE 01/26/11
QZRCSRVS QUSER 423988 PJ ACTIVE 01/25/11
QZRCSRVS QUSER 350456 PJ ACTIVE 01/24/11
QZRCSRVS QUSER 310785 PJ ACTIVE 01/23/11
QZRCSRVS QUSER 256417 PJ ACTIVE 01/22/11
QZRCSRVS QUSER 181924 PJ ACTIVE 01/21/11
QZRCSRVS QUSER 102098 PJ ACTIVE 01/20/11
QZRCSRVS QUSER 019406 PJ ACTIVE 01/19/11
QZRCSRVS QUSER 942786 PJ ACTIVE 01/18/11
QZRCSRVS QUSER 885484 PJ ACTIVE 01/17/11
QZRCSRVS QUSER 847740 PJ ACTIVE 01/16/11
QZRCSRVS QUSER 793825 PJ ACTIVE 01/15/11
QZRCSRVS QUSER 719665 PJ ACTIVE 01/14/11

The QZRCSRVS job is the Remote Command/Distributed Program Call host server. It receives authenticated requests from remote systems to run commands or to call programs. IBM has a recommendation that the prestart job configuration for this server be set as MAXUSE( 1 ), and there is some sense to that. But it essentially means that every individual request be serviced in a new job.

If you have some remote app, e.g., Cisco, that’s sending hundreds/thousands of requests, each one should be handled by a new instance of the server jobs. That could give the result that you’re seeing.

You might be able to let Cisco Tidal continue to run, keep MAXUSE(1) set for the usual server instances, and also get the number of jobs under control. Maybe.

The properties of QZRCSRVS can be customized through iSeries Navigator. A particular customization for this issue would be enabled through the Subsystems tab of the server Properties. You could set requests that originated from the IP address of the remote system to run in a separate subsystem. That would allow you to set MAXUSE(100) or more for a prestart job entry, but only in the isolated subsystem.

The risk is that there are other apps at the same IP address that are communicating with QZRCSRVS. The server job cannot manage resources that are referenced by remote requests. For example, if some request sets a lock on an object and doesn’t clean up after itself, the lock will remain until that server instance finally ends. And, by reusing the same instance for multiple requests, one request may mess up the environment for a subsequent request within the same instance. Poorly structured remote apps can cause interference.

In any case, if you chose to go that route, it’s shouldn’t be particularly difficult. I’ve done it for other servers, though not yet for QZRCSRVS. It should only require having (possibly creating) a separate subsystem description, adding the QZRCSRVS prestart job entry with appropriate parameters, and changing the Remote Command host server properties to use the new settings for the identified remote IP address.

You should then be able to tune the settings just for that one application, possibly setting MAXUSE(1000) and helping the number drop way down. You should also even be able to get joblogs (if needed) for the isolated jobs by having them use a *JOBD that you copied from the original and modified. It might be worth a try.

Tom

Tom