CV encountered DC015007 SOS conditions repeatedly for pool 128 and for pool 1 (pools contain types USER, USER-KEPT, SHARED, SHARED-KEPT) when a particular Batch job was run under the CV.
The batch job in question was Binding and Finishing many Rununits in succession, each to do a small unit of work. The database records accessed in these rununits were compressed on the database using IDMSCOMP. The work storage used by IDMSCOMP and IDMSDCOM was not being freed and each new rununit acquired new work storage. Eventually the storage pool filled. This could occur for any task that is serially Binding/Finishing many rununits. In this case the originating program was batch 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.
This is documented in three places in the DATABASE ADMINISTRATION GUIDE. In the section on Schema Statements for AREA and RECORD, and also in the section on Writing Database Procedures subsection Specifying When to Call Database Procedures:
Here is the description:
If any record in the area uses IDMSCOMP and IDMSDCOM for compression and decompression, the AREA in which the records reside should have the following database procedure specifications:
CALL IDMSCOMP BEFORE FINISH. CALL IDMSCOMP BEFORE ROLLBACK. CALL IDMSDCOM BEFORE FINISH. CALL IDMSDCOM BEFORE ROLLBACK.
This ensures that the work areas used by the compression and decompression routines are freed when a rununit terminates.
DATABASE ADMINISTRATION GUIDE
Release: IDADSO00100-18.5-ADS-for CA-IDMS