Jan 1 ’04

MVS Boot Camp: Monitoring Virtual Storage Consumption

by Editor in z/Journal

Are your OS/390 applications experiencing virtual storage constraints? If you don’t know and don’t know how you can find out, then this article is for you. Some applications, such as DB2, use a tremendous amount of “above the line” virtual storage. If the virtual storage consumption is not monitored, you could unexpectedly experience virtual storage constraints, leading to application failures. Monitoring virtual storage consumption is one step you can take toward proactive capacity planning in your environment. This article will demonstrate how you can use IBM’s RMF product to monitor the virtual storage utilization of specific address spaces running on your system.

When an OS/390 address space is created, up to 16MB of memory is allocated below the 16MB line, and up to 2GB of memory is allocated above the 16MB line. RMF provides a function to map this virtual storage. With a bit of calculation, you can quickly see how much free space is available within your address space(s) virtual storage allocation.


In order to monitor an address space’s virtual consumption, the first thing you need to do is direct the RMF product to gather the virtual storage statistics for a given address space. The simplest way to accomplish this is to issue a “modify” command to the RMF application. The following console command will tell RMF to monitor the virtual storage for a DB2 address space named PRDADBM1:


After entering the command, watch the SYSLOG for any error messages. You should see console messages similar to those shown in Figure 1. Once the RMF command has been successful, wait a few moments for the statistics to be gathered. (You should wait until at least two of your RMF intervals [or SMF intervals if you use SYNC(SMF)] have passed before proceeding to the next step.)

NOTE: You can find the SMF interval in the INTVAL(mm) statement in SYS1.PARMLIB(SMFPRMxx), and the RMF in the INTERVAL(mm) statement in SYS1.PARMLIB(ERBRMFxx).


After your RMF modify command has been active for a while, you are ready to run an RMF post processor job to obtain the virtual storage statistics for the selected address space. You will use the following RMF post processor command statement to invoke the virtual storage report: 


where PRDADBM1 is the name of the address space entered on the RMF modify command. Figure 2 shows the JCL for the post processor job. Don’t forget to change the address space name in the VSTOR control statement and the date control statement.

Notice that the post processor job does not specify the location of the RMF/SMF data via the MFPINPUT DD statement. By omitting the MFPINPPUT DD statement, you are telling the post processor to utilize the Sysplex Data Services to access the SMF buffers. Most shops have the SMF buffers protected by their security system. If you are using the RACF security system, you can provide access to the SMF buffers using the following commands: 

permit erbsds.smfdata class(facility)

     id(userid) access(read)

setr raclist(facility) refr 


You can download an example of a Virtual Storage Activity report generated by the RMF post processor job from the z/Journal Website (go to “Current Articles” and download the file that accompanies the article PDF). To determine the amount of free virtual storage above the 16MB line, perform the following calculations:

Subtract the “LSQA/SWA/229/230 Pages allocated in bytes” amount and the “User Region Pages Allocated in bytes” amount from the “Region Assigned Above 16M” amount. Figure 3 shows that there is 327MB of free virtual storage.

For DB2 address spaces, IBM published the following guidelines for virtual storage:


The RMF documentation recommends that you not leave the VSTOR data-gathering function enabled for extended periods of time. Doing so could impact the performance of your system. Once you have generated your RMF post processor report, you should deactivate the data-gathering function. To do this, enter the following command from your console: 



If you are running critical applications, such as DB2 or WebSphere in an OS/390 environment, it is in your best interest to occasionally monitor and track the virtual storage consumption of your applications. Failure of a mission-critical application due to virtual storage exhaustion can be difficult to explain and even more difficult to correct. By tracking your applications’ virtual storage consumption, you can proactively predict when trouble is headed your way. Z