Let's take a look at a VMDSS usage scenario to see how both VMDSS and CP react to changing circumstances.
Assume that the system is initially lightly loaded. There is an abundance of real storage available for use, and the database is brought up. Of course, the database storage usage starts small - less than the TARGETWS value. At this point, assume that there is light usage of the database. So, data space pages are referenced, paged in, moved to the local buffers and NOT RELEASED (assuming the Working Storage Residency Priorities are all 3).
As time passes, the storage size of the database increases. In this unconstrained environment, CP may bring in extra pages (beyond those requested by the database). CP will not be stealing pages; there is still free real storage available and no contention for it. Eventually, the database storage size exceeds the TARGETWS value. Now, VMDSS begins to release NEW data space pages as they are used, but it cannot release any of the previously used pages. Note that, at this point, the database storage size still exceeds the TARGETWS, and nothing will be done at this time to reduce this. VMDSS cannot release old pages, CP is not stealing them, and CP may still be bringing in extra pages (there is still free real storage available).
So the storage size continues to increase and continues to exceed the TARGETWS. Eventually the amount of free real storage becomes scarce, and this causes CP to do two things. First, CP will reduce, and finally stop, bringing in extra pages when a page is requested by VMDSS (and will also begin ignoring REFPAGE requests by VMDSS). Second, CP will begin stealing pages away from the database, so that real storage page frames can be reused by other data space pages needed by the database (at this point, the database and the VM system are handling light loads).
However, these actions all have no overall effect on the database storage size. It still greatly exceeds the TARGETWS value, even though VMDSS has been doing RELPAGE's for quite a while now. In general, VMDSS is releasing pages as fast as it requests them, and CP is only stealing away pages as fast as the database needs new ones. The net effect is to simply maintain the database storage size at a constant value, which still exceeds the TARGETWS value.
Now, let's assume that the VM load starts to increase. More real storage will be needed for other users besides the database. CP will begin stealing away more and more of the database's storage for use by other users. Therefore, the database storage size finally begins to decrease. CP is stealing pages and VMDSS is releasing pages faster than VMDSS is requesting them. Eventually, the database storage size will decrease until it is less than the TARGETWS value. Therefore, VMDSS stops releasing pages. At this point, VMDSS is requesting pages and CP is stealing others.
If the VM system load remains relatively constant, the database storage size will remain close to (but usually exceeding slightly) the TARGETWS value because CP will be stealing away pages about as fast as VMDSS can request them.
However, if the VM system load continues to increase, CP will be stealing away pages faster than VMDSS can request them. The database storage size will continue to decrease and will now remain below the TARGETWS value because VMDSS cannot request pages faster than CP can steal them. Eventually, some minimum database storage size will be reached where the rate of CP stealing pages equals the rate of VMDSS page requests, which will be below the TARGETWS.
In certain storage-constrained environments, CP never seems to be able to prevent VMDSS from taking "too much" storage. In this context, "too much" simply means that other VM users must wait for storage and thus their response time suffers. In these cases, the only solution (without adding extra real storage) is to issue the CP SET SRM MAXWSS n% command to set a system-wide storage size restriction AND to remove the QUICKDSP option from the database user ID. This is a fairly drastic measure because removing QUICKDSP will degrade the database user's response times. If QUICKDSP is not removed, then the "SET SRM MAXWSS" setting will NOT affect the database machine's real storage usage.