MUF abends because of a SC22 in DBIOSPR


Article ID: 49480


Updated On:


CA Datacom CA DATACOM - AD CA Ideal CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware



Datacom MUF address space fails due to a SC22 abend in DBIOSPR module. This means that the address space has exceeded the threshold of outstanding I/O requests allowed by the operating system.
IBM does not allow more than 500 concurrent I/Os per address space at any given point in time.

Datacom/DB code ensures that any point in time we will not allow the I/Os to exceed 480, meaning we would keep a cushion or pad of 20 I/O requests. Once we reach 480, we stop new I/Os to be issued until the 480 number subsides below it.

The number of times this limit has been reached during a MUF execution is reported at MUF EOJ:


The count of times Datacom/DB constrained and started no I/O because the outstanding I/O was 480 or more.

However a high number of IOTASKS may cause all the IO subtasks to be issuing simultaneously and this limit is possible to be violated.


Decrease the number of IOTASKS or use SMPTASKS to evenly farm out or distribute the work on multiple CPUs.


Component: DB