Verify that virtual storage limits are set properly

Description

Virtual storage requirements can grow from release to release. You should review the virtual storage limits that you want to set. Generally, there are two areas of concern: common areas (above and below the 16 MB line) and individual address spaces. An increase in virtual storage for common areas reduces the virtual storage size of all address spaces. An increase in virtual storage for individual address spaces impacts only the individual address spaces.

Table 1 provides more details about this migration action. Use this information to plan your changes to the system.

Table 1. Information about this migration action
Element or feature: Multiple.
When change was introduced: General migration action not tied to a specific release.
Applies to migration from: z/OS V2R1 and z/OS V1R13.
Timing: Before the first IPL of z/OS V2R2.
Is the migration action required? Yes.
Target system hardware requirements: None.
Target system software requirements: None.
Other system (coexistence or fallback) requirements: None.
Restrictions: None.
System impacts: None.
Related IBM® Health Checker for z/OS® check: Use IBM Health Checker for z/OS to help determine whether your virtual storage limits are set properly. The check RSM_MEMLIMIT checks the current setting for the MEMLIMIT parameter in SMFPRMxx, which affects the amount of virtual storage above the 2 GB bar that is available to jobs. This check verifies that a nonzero MEMLIMIT value is in use.

Steps to take

Determine how much virtual storage use to allow above the 2 GB bar. While there is no practical limit to the number of virtual addresses an address space can request above the bar, the system can limit the amount of virtual storage above the bar that an address space is allowed to use. The amount of virtual storage above the bar is determined as follows. The MEMLIMIT parameter in parmlib member SMFPRMxx sets the default system-wide limit, which defaults to 2 GB as of z/OS V1R10 (and zero before z/OS V1R10). However, the system-wide default MEMLIMIT can be overridden by specifying REGION=0M or MEMLIMIT on JOB or EXEC statements in JCL. To set a limit on the use of virtual storage above the bar, use the SMF exit IEFUSI. For more information, see "Limiting the use of memory objects" in z/OS MVS Programming: Extended Addressability Guide.

If you want to control the use of virtual storage above the 2 GB bar, do one or more of the following:
  • The MEMLIMIT default is 2 GB. If this 2 GB default value is acceptable to you, no change to SMFPRMxx is necessary. (Before z/OS V1R10, the default MEMLIMIT was zero, and you had to specify a nonzero MEMLIMIT in an active SMFPRMxx member of parmlib to establish a system default other than zero for available virtual storage above 2 GB.)
  • You can specify MEMLIMIT explicitly in JCL to override the system default that was set (or allowed to default) in SMFPRMxx.
  • You can specify REGION=0M on the job statement in JCL to implicitly set MEMLIMIT to NOLIMIT, which also overrides the system default (from SMFPRMxx).
  • You can use IEFUSI both to establish a system default MEMLIMIT for different classes of work (for example, JOB, TSO, STC) and limit the amount of virtual storage that can be used above the bar, provided that an explicit or implicit nonzero MEMLIMIT is in effect from JCL or SMFPRMxx. As of z/OS V1R10, keyword HONORIEFUSIREGION | NOHONORIEFUSIREGION is available in SCHEDxx to identify if the region and MEMLIMIT settings specified through or otherwise affected by the IEFUSI exit are to take effect for a program. If you are overriding the attribute of HASJES20 (JES2) in SCHEDxx parmlib member, specify NOHONORIEFUSIREGION explicitly so the default of HONORIEFUSIREGION is not used for this program.

Reference information

For more information, see the following references:
Parent topic: Migration actions for everyone before the first IPL of z/OS V2R2