MUF abends because of a SC22 in DBIOSPR

Products

• CA Datacom - DB
• CA Datacom
• CA Datacom - AD
• CA Datacom - Server
• 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

Issue/Introduction

Description:

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:

X_IO_OS_THRESHOLD

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.

Solution:

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

Environment

Release:
Component: DB