DC015007 SOS messages for a storage pool that is neither full nor marked SOS
Article ID: 23904
Updated On:
Products
Issue/Introduction
DC015007 SOS messages are being issued for a storage pool that is neither full nor marked SOS.
The message can be issued when the pool is not very full, due to pool fragmentation. This condition does not increase the SOS count.
The messages are like this:
DC015007 Vnnnn POOL nnn: SOS CONDITION 0, SZ=nnnnnn, T=taskcode, P=pgmname
When the pool stats are displayed, it shows that it has never gone SOS and the High Water Mark is not close to pool size.
How can this SOS message be produced for a pool that shows it has only ever filled around 50-60%?
Environment
IDMS, all supported releases.
Resolution
Message DC015007 can be produced for two different conditions.
CONDITION 0 means a storage request was satisfied that took the currently allocated storage amount into the pool's cushion. This condition will increase the SOS count. (Note: it is recommended that for all storage pools, the cushion should be 10% of the size of the pool).
CONDITION 1 means that there was not sufficient contiguous storage in the pool to satisfy the request. This can happen even when the pool is not very full, due to pool fragmentation. This condition does not increase the SOS count.
A common reason for fragmentation is the use of both USER and USER KEPT storage types by pseudo-conversational online applications, especially if users will be in the applications for long periods of time and/or the RESOURCE TIMEOUT INTERVAL is excessive.
ADS applications are pseudo-conversational by design but clients can write pseudo-conversational applications in languages such as COBOL as well. When such an application issues a mapout the database transaction and the task are ended. When the user subsequently hits a control key, a new task is started to resume processing.
When the task ends, all USER storage allocated during processing is freed, but the USER KEPT storage which is necessary to resume processing when the user responds, remains allocated, and is anchored in the Logical Terminal Element (LTE) rather than in the Task Control Element (TCE) which is only present when there is an active task.
When both USER and USER KEPT storage is allocated from the same pool, applications like this can fragment the pool.
USER KEPT storage allocations are only freed when the user on a given LTE signs off from the CV or if the RESOURCE TIMEOUT INTERVAL forces the signoff and freeing of resources when no active task has been executed on the LTE for longer than the interval.
Many cases have been seen where a DCMT DISPLAY ACTIVE STORAGE nnn shows a pool map indicating many small allocations spread over the entire pool, with many free pages in between, BUT often the number of contiguous free pages is severely limited and can cause failures for large storage requests.
Reducing RESOURCE TIMEOUT INTERVAL can reduce such fragmentation to a certain degree, but the easiest and most effective way to avoid this kind of pool fragmentation is to define separate pools for USER and USER KEPT storage rather than having them both in the same pool.
If the storage pool having the SOS only has storage types TR and DB then the pool will only contains DB (Database) storage because TR storage is not used anymore. Database type storage is used for Variable Subschema blocks (VB50), Transaction related blocks (TBKs, TBXs, DSIBs) currency blocks, etc. An SOS in database storage is usually due to a lot of run-units open at the same time. Perhaps the program is doing multiple BIND RUNUNIT without doing a FINISH.
Additional Information
Feedback
