IDMS: SOS in USER storage pool related to IDMSCOMP/IDMSDCOM
search cancel

IDMS: SOS in USER storage pool related to IDMSCOMP/IDMSDCOM

book

Article ID: 39887

calendar_today

Updated On:

Products

IDMS IDMS - Database

Issue/Introduction

CV encountered DC015007 SOS conditions repeatedly for any storage pool which is defined to contain types USER, USER-KEPT, SHARED, SHARED-KEPT.

Environment

Release: All supported releases.
Component: CA-IDMS

Cause

A batch job BINDs and FINISHes many rununits in succession, each to do a small unit of work. The database records accessed in these rununits are compressed on the database using IDMSCOMP. The working storage used by IDMSCOMP and IDMSDCOM is not being freed and each new rununit acquires more working storage. Eventually, storage pools containing user storage fills.

This could occur for any task that is serially BINDing/FINISHing many rununits. More often than not, this is a batch job, but an online task could do the same thing.

The problem occurs because the schema from which the subschema was generated called the IDMSCOMP and IDMSDCOM procedures for one or more records but did NOT call these procedures at the AREA level before FINISHing each rununit.  Since the task remained active while a large number of rununits were executed in succession the storage built up and eventually filled the storage pool.

Resolution

The solution to the problem is to ensure that if any record in the area uses IDMSCOMP and IDMSDCOM for compression and decompression, the area should have the following database procedure specifications:

CALL IDMSCOMP BEFORE FINISH
CALL IDMSCOMP BEFORE ROLLBACK
CALL IDMSDCOM BEFORE FINISH
CALL IDMSDCOM BEFORE ROLLBACK

This is correctly documented in the Record Statement sub-section (under the sub-heading "Area procedures needed for IDMSCOMP compression") of the Schema Statements section of Administrating CA IDMS Database.

It is less specifically documented at Coding Database Procedures under the sub-heading "Specifying When to Call Database Procedures", and incorrectly documented at AREA Statement under the sub-heading "Calls needed for IDMSCOMP compression".

These pages are in the process of being corrected. The correct syntax is what is mentioned above.