ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

MUF abends because of a SC22 in DBIOSPR

book

Article ID: 49480

calendar_today

Updated On:

Products

Datacom DATACOM - AD Ideal CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services CA ECOMETER SERVER COMPONENT FOC EASYTRIEVE REPORT GENERATOR FOR COMMON SERVICES INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA ON DEMAND PORTAL CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET 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