Deliver - RMOPARM setting JOBCLSL=* Causing Common Storage Spike

Products

• Deliver

Issue/Introduction

One of our Deliver databases has a RMOPARM setting of JOBCLSL=*.

There was a spike in common storage which resulted in an IPL due to how badly fragmented common storage was left.

A dump found that there were over 83,000 PQE control blocks obtained in common storage, which is what filled common storage, and these blocks are obtained by Deliver. 

During this time, there were tens of thousands of UNIX related started task address spaces started. 

The RMOPARM JOBCLSL=* is set, so that Deliver is processing started tasks and TSO users.

We then updated JOBCLSL=* to  JOBCLSL=ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 (minus @ and #).

Why is "JOBCLSL=*" causing such a large spike in common storage?   Is this expected?

Environment

Release : 14.0

Component :

Resolution

A dump review showed that there were 83,000 PQE's (Priority Query Executions) created by Deliver, to pre-spool process UNIX STCs that used up CSA.

For Deliver to keep up with processing the PQE's, the RMOSTC task would requiring having the same dispatching priority as the UNIX tasks.

Changing RMOPARM JOBCLSL from "*" to "A-Z and 0-9" will change pre-spool processing of started tasks and TSO users to post-spool processing and will stop the PQE process for started tasks and, then, no dispatching priority changes would be needed.

FYI:

An IPL was not needed. If there had been an issue of "/F rmostc.OFF", that would have cleared all the PQEs that Deliver created. This would be followed by a task restart "/S rmostc".