If you have set USERS=10 in your DBCVTPR macro in your CICS then TASKS parameter in MUF startup must be greater than 10. Other TASKS above 10 will be available for batches. Similarly, if you have 2 CICS linked to that MUF with both USERS=10 in their respective DBSVTPR macro then TASKS in MUF startup must greater than 20.
In a MUF running both online and batch, this value must be the sum of all USERS= counts for all concurrently active CICS regions and the maximum number of active batch regions using CA Datacom/DB.
DBOC INQ=USERS in CICS online may help you tuning the USERS= parameter.
COMM STATUS or Select * from MUF_Active_Tasks will help to tune the batch side and online side.
If the TASKS number is too low one will receive return code: RC 85 (01) - INSUFFICIENT TASKS
When increasing TASKS parameter,
- You need to update the DATAPOOL and SYSPOOL options accordingly.The number of Data Buffers ("DATANO") specified in DATAPOOL option must be equal or higher to the number of TASKS. "DXXNO" and "IXXNO" parameters of SYSPOOL option are also related to the number of TASKS. In fact, you need at least one and half DXX buffers per TASKS and "IXXNO" must be half the "DXXNO" number.
- Verify that the Force Area (FXX) was initialized with a TASKS= keyword value that is greater than or equal to this TASKS MUF startup option number.
- It will affect the MUF REGION; we recommend to use REGION=0M so that the system can manage the region as needed.
It is better to review these parameter definitions via CA Datacom/DB System and Administration Guide and the Datacom CICS Services Guide as well before changing TASKS parameter.
DBOC INQ=USERSgives an overall view of the CICS region since it started (not a current view). If any transaction was waiting on threads due to the fact that all threads (as defined in your DBCVTPR) were being used at that time, then INQ=USERS will show ** to the left of the left of the number for those users above of your DBCVTPR setting.It will also tell you how many DB requests were processed while one or more transactions were waiting to get a DB thread (user). This would be numbers that you would normally look at the end of the day and decide whether you need to increase the number thread/users.