Selecting the right subpool for your virtual storage request

Conceptually, a subpool is an area of virtual storage with a certain set of attributes, created by MVS™ to satisfy a request for virtual storage. A two-gigabyte virtual storage address space is divided into multiple areas, each intended to support specific system and user needs. MVS provides subpools within the following areas of the address space:

Low private
High private
Private local system queue area (LSQA) and extended LSQA
Common system queue area (SQA) and extended SQA
Common service area (CSA) and extended CSA.

For more information about these virtual storage areas as well as information about virtual storage in general, see the virtual storage overview in z/OS MVS Initialization and Tuning Guide.

Besides being in a particular area in an address space, subpools are distinguished by other attributes, such as which programs can access them, whether the storage can be paged out, and how long the storage persists. To select the right subpool, you need to examine these attributes and determine which ones are best suited for your needs. Your choice of subpool depends on several factors:

Whether your program is authorized
How you will use the storage
What environment your program runs in.

This information discusses the considerations involved in determining the appropriate subpool for your storage request, such as:

What is your program's authorization level? (See Program authorization.)
Do other address spaces need access to the storage or will it be used only by tasks and subtasks in the same address space? (See Selecting private or common storage.)
Do you want to protect the storage area from unwanted access? (See Selecting fetch protected or non-fetch protected storage.)
Does your storage area require a particular storage key? (See Selecting the storage key.)
Is the program accessing the storage running enabled, locked, or disabled? (See Selecting pageable, DREF, or fixed storage.)
How long will the storage be required? (See Selecting storage persistence.)
Must the storage area be backed below 16 megabytes or can it be backed anywhere? (See Selecting central storage backing.)

Be sure also to read the discussion of subpools in z/OS MVS Programming: Assembler Services Guide. The information in z/OS MVS Programming: Assembler Services Guide is not repeated in this discussion.

Alternatives to Using Subpool Storage

Data spaces and hiperspaces provide an alternative means of obtaining and sharing storage. For instance, you can use a SCOPE=ALL data space to hold data to be accessed by all programs running in your address space. You can also use a SCOPE=COMMON data space to share data among programs in different address spaces instead of using common storage for that purpose. For more information about creating and using data spaces and hiperspaces, see z/OS MVS Programming: Extended Addressability Guide.