Previous Topic: 2.5.5 Case Study

Next Topic: 2.5.5.2 Inquiry Panels

2.5.5.1 Problem Description


Virtual storage resource usage should be monitored on an
ongoing basis.  Unlike CPU time or DASD space consumption,
use of virtual storage is much more subtle.  More and more
storage is quietly consumed until some limit is reached with
serious results, such as IMS Control region ABENDs or the
system being quiesced and no new work being permitted to
start.  Also, depending on the allocation and subpool being
used, expanding the use of virtual storage may also impact
the use of real storage, as some subpools are defined as
non-pageable.  Finally, although some virtual storage
constraint relief has been obtained through the introduction
of the MVS/XA operating system, it is often necessary to
modify applications and/or install new levels of software,
such as IMS, to take advantage of the extended capabilities.
Even though MVS/XA provides some virtual storage relief, it
must be realized that not all applications can take advantage
of the extended capabilities, and, therefore, virtual storage
constraint will remain an issue.

The purpose of this study is to review the virtual storage
usage of a system running IMS, TSO, and batch workloads.  The
site has a single 3090-400 system, operating in partition
mode as two 3090-200 processors.  Over the past several
months the workloads have been shifted between the two
systems in an effort to better balance the CPU requirements.
We are using the VSM software to analyze the virtual storage
requirements on the production system.

In particular, it must be determined if the Common Area
allocations, such as SQA and CSA, are properly sized, what
sort of growth patterns, if any, are present in the Common
Area allocations, and what tasks are significant users of the
Common Area storage.