What I can see on the CA website is:
• MAXimum ERUs is external-request-unit-count
Specifies the number of EREs to allocate at system startup. External-request-unit-count must be an integer in the range 0 through 1000.
Specify a value equal to the total number of external request units you allow to execute concurrently in the DC/UCF system plus 10% - 20% of the total number of 3270-type terminals defined to the DC/UCF system.
Note: When up to 255 EREs are requested, a corresponding TCE/DCE pair will be allocated for each one during startup. If more than 255 ERES are requested, a maximum of 255 TCE/DCE pairs are allocated for these external request units.
• MAXimum TASks is task-count
Specifies the maximum number of application and transient system tasks that can be active at a given time. The system generation compiler uses this value when calculating the number of TCEs to allocate at system startup.
Task-count must be an integer in the range 0 through 255. The default is 0.
Note: For more information about Task-Count, see Task Resource Usage, and also the section "System Performance" in the System Operations section.
Could you please let me know what the theoretical impacts may be if MAX ERUS were increased from our current setting of 200 to 255 and if the Max Task was increased from our current setting of 235 to the 255 limit?
My understanding is that the CV requires 10-20 tasks itself is this reflected in the 255 limit?
At startup, the sysgen MAX TASK value is added to several other sysgen related parameters to come up with a 'runtime' value for MAX TASKS. The parameters added include, but are not limited to, MAX ERUS, system tasks for the various line drivers, one each for MASTER and DBRC, run-unit service drivers, and deadlock detection service drivers. Taken from knowledge article 000024122.
The values for MAX TASKS and MAX ERUS seem very high. Is there a task at startup that issues a DCMT VARY MAX TASK value down from the sysgen value?
If increasing the MAX TASK/ERUS values, you should monitor those things that could increase with a potential increase in work load, for example, storage pools, program pools, scratch usage, even the DDLDCRUN area as well (queues), SYSLOCKs.
You should also be mindful of RCEs and RLEs ... the CV will allocate more as it needs them but it would be a good idea to look out for DC010007 messages, and increase the sysgenned amount as needed. Also, remember that storage for the TCEs come from 24bit storage.
Most of these resources are allocated in z/OS above-the-line storage so if you overallocate, the danger is needing too much of that (note the DC390020 message at startup) and incurring more opsys storage paging.
Based on the current value, the runtime MAX TASKS are 235. This includes the MAX ERUS of 200, plus the IDMS drivers mentioned earlier. This indicates that most of the workload is coming from batch or CICS, and very little online activity.
To prevent 1473 abends, our recommendation would be to increase the MAX ERUS, but not MAX TASKS. For example, if you set the MAX ERUS to 255, this would add 255 to the MAX TASKs (55 more than you currently have), and give the CV 255 EREs for external rununits.
If you vary the runtime MAX TASKS to 200 (DCMT VARY ACTIVE TASK MAX TASK 200), the cv would never run more than 200 tasks concurrently, but will have 255 EREs for external rununit tasks, this would make it highly unlikely to get 1473 abends.
In this example, if there are 200 active tasks in the CV, say task #201 starts from batch/CICS. No 1473 abend would occur because there are still available EREs, so task #201 will wait for one of the first 200 active tasks to end. With more EREs than TCEs, it is highly unlikely that you will get 1473 abends.