I am experiencing Short on Storage (SOS) messages like this for pool 255:
DC015007 Vnn POOL 255: SOS CONDITION 0, SZ=nnnn, T=aaaaaaaa, P=aaaaaaaa
DC015007 Vnn POOL 255: SOS CONDITION 1, SZ=nnnn, T=aaaaaaaa, P=aaaaaaaa
DC015007 Vnn POOL 000: SOS CONDITION 1, SZ=nnnn, T= aaaaaaaa, P= aaaaaaaa
These symptoms of storage pool 255 going SOS, maybe followed by storage pool 0 can be caused by the allocation of lock overflow storage. If a job requires more storage for locks than has been allocated at startup, additional storage is obtained from storage pool 255. Lock overflow storage is restricted to XA storage but once pool 255 fills, it may overflow to pool 0 (depending on the release of IDMS) causing that pool to also overflow.
Excessive use of locks is usually caused by long running batch programs which do not issue a COMMIT. There is however one type of processing that can cause excessive use of locks even with COMMITs coded in the program. An ERASE with the ALL MEMBERS option can cause many records to be deleted with a single DML verb without returning control to the program. I t will ERASE the target record and all related members. If the member record is also the owner of a set, its members are also deleted. This continues with the members of the members until all records in the network structure are deleted. This has the potential to do a massive number of deletes (and accumulate a large number of locks) without the program having the opportunity to control this with COMMITs. In this situation it is best to recode the program to walk the sets and ERASE each member individually, issuing COMMITs every so often.
You can use LOCKMON STATUS or DCMT D LOCK STAT to confirm if the SOS is caused by lock overflow storage.
Storage for locks is acquired at startup according to the value specified in the SYSLOCKS parameter in the SYSTEM statement of the SYSGEN.
The recommended value for SYSLOCKS is 100,000, increase it if it is below this value.