Limiting the use of private memory objects

Start of change

While there is no practical limit to the virtual storage above the bar, practical limits exist to the finite real storage frames and auxiliary storage slots that back the virtual storage. Limiting the virtual storage that an address space can consume will directly limit its real frame and auxiliary storage usage. In addition to limiting the virtual storage usage to control real frame usage, your installation can limit an address space or set of address space's real frame usage by classifying the address spaces to a WLM resource group with a real storage memory limit. However, the amount of auxiliary storage cannot be limited by resource group. For more information about WLM resource groups, see z/OS MVS Initialization and Tuning Guide and z/OS MVS Planning: Workload Management.

Conceptually, the aggregate of the unlimited virtual storage for all concurrently active address spaces must fit into the amount of real storage and auxiliary storage defined on a given system. The fixed virtual storage, which is not pageable, must fit in the available real storage, and anything else can potentially be paged out to auxiliary storage. However, WLM controls system resources such that when resources are limited, WLM attempts to control address space consumption by taking actions such as altering dispatch priorities, swapping out address spaces, and so on. Even so, there are conditions under which the system may run out of these resources (such as when real storage is constrained) and require the system to start swapping or paging, which can unacceptably impact system performance. For more information about real frame and auxiliary storage resources and how to determine your required auxiliary and real storage requirements, see Auxiliary storage management initialization in z/OS MVS Initialization and Tuning Guide.

The amount of virtual storage that an address space can use for private memory objects at any given time is controlled by the MEMLIMIT (memory limit) specification. However, note that authorized users of IARV64 GETSTOR who specify the MEMLIMIT=NO or MEMLIMIT=COND parameters may request that the storage obtained for that specific GETSTOR request not be subject to the MEMLIMIT; they may use other means of determining whether or not the storage associated with the allocation will have an impact on the system. The MEMLIMIT for an address space can be set via the IEFUSI installation exit, an SMFLIMxx parmlib member specification, a JCL specification, the system's default MEMLIMIT (specified in the SMFPRMxx parmlib member), and other means if under the control of z/OS UNIX Systems Services (z/OS UNIX).

It is recommended that you review the requirements for your applications and use those requirements as a guide to setting the MEMLIMIT for those application address spaces. In many cases, JCL, SMFLIMxx, or z/OS UNIX (also known as OMVS) controls would be recommended based on the expected workload demand and configuration. For all other ad hoc types of address spaces, the system-wide default would most likely apply.

z/OS UNIX address spaces have additional MEMLIMIT controls (such as the MEMLIMIT parameter in the RACF OMVS segment, the SETOMVS MEMLIMIT command, and others) that control dubbed address spaces that are also under its control. The default MEMLMIT specified in the SMFPRMxx parmlib member may still apply to those address spaces. Before proceeding, see z/OS UNIX System Services Planning for more information.

After an address space is started, its MEMLIMIT can only be changed if its MEMLIMIT is currently assigned via the SMF default or it is a dubbed z/OS UNIX address space.

Determining the effective MEMLIMIT value

Outside of z/OS UNIX controls that can take precedence over all other controls, the MEMLIMIT that is used at the start of a job step is based on the following conditions, in order of precedence, as shown in Figure 1. The first condition that is satisfied determines the MEMLIMIT value. (The numbered blocks in the figure refer to the numbered steps in the detailed list that immediately follows the figure.)

Figure 1. Order of precedence in determining the effective MEMLIMIT value
How the system determines the MEMLIMIT value
The following sequence describes the order of precedence, as shown in Figure 1, for determining the MEMLIMIT value to apply:
  1. A matching MEMLIMIT specification is found in the SMFLIMxx parmlib member.
    • SMFLIMxx provides a broad set of filter keywords with wild card capabilities, such as JOBNAME, JOBCLASS, USER, SUBSYS, and PGMNAME.
      Note: It is possible to use SMFLIMxx REGION MEMLIMIT(nn) to set a MEMLIMIT for all job steps that do not contain a more specific SMFLIMxx filter specification.
    • The NOHONORIEFUSIREGION attribute in the program property table (PPT) for the job prevents SMFLIMxx from altering the MEMLIMIT.
    • See Using SMFLIMxx to control the REGION and MEMLIMIT in z/OS MVS Initialization and Tuning Guide for more information.
  2. A specific MEMLIMIT for the job is specified via the IEFUSI exit.
    • The IEFUSI exit can override SMFLIMxx, if requested.
    • The NOHONORIEFUSIREGION attribute in the program property table (PPT) for the job prevents IEFUSI from altering the MEMLIMIT.
    • See Using exit routines to limit region size in z/OS MVS Initialization and Tuning Guide, and IEFUSI — Step initiation exit in z/OS MVS Installation Exits for more information.
  3. The MEMLIMIT is determined from JOB or EXEC statement specifications.
    • When the MEMLIMIT parameter is specified, it is used. Specifying MEMLIMIT on the JOB statement overrides MEMLIMIT on the EXEC statement.
    • When REGION=0K, REGION=0M, or REGIONX=(0M,0M) is specified, the MEMLIMIT is set to NOLIMIT.
    • If REGION=0K, REGION=0M, or REGIONX=(0M,0M) is specified and the IEFUSI exit or SMFLIMxx member limits the REGION size but does not set a MEMLIMIT, MEMLIMIT is defaulted to the REGION size above 16 MB.
    • See z/OS MVS JCL Reference for more information.
  4. A system-wide default SMF MEMLIMIT value has been specified in the current SMF option.
    • The SETSMF command can be used to change the current default SMF MEMLIMIT value from the one specified in the active SMFPRMxx parmlib member.

      By contrast, the SET SMF command can be used to change the active SMFPRMxx parmlib member, which may specify a new default SMF MEMLIMIT value.

      You can use the D SMF,O command to display the SMF options and values that are currently in effect.

    • The SETSMF and SET SMF commands temporarily change the options that are in use on the system on which they are issued; the changes are lost upon the next IPL of the system. To make the changes permanent, update the SMFPRMxx parmlib member that is used during IPL.
    • See Setting the system-wide default SMF MEMLIMIT value, Altering the default SMF MEMLIMIT value, and SMFPRMxx in z/OS MVS Initialization and Tuning Reference for more information about using the SET SMF and SETSMF commands.
  5. If no default SMF MEMLIMIT parameter has been specified in the active SMFPRMxx parmlib member and no SETSMF command has been issued to specify a default SMF MEMLIMIT value, the system uses a MEMLIMIT value of 2G.

Setting the system-wide default SMF MEMLIMIT value

You can set the current system-wide SMF MEMLIMIT default in the following ways:
  • The MEMLIMITparameter in the active SMFPRMxx parmlib member, where the active SMFPRMxx member was established either at IPL time or changed via the SET SMF=xx command.
  • The SETSMF MEMLIMIT(nn) command on a specific system or systems without changing the active SMFPRMxx member.

The default SMF MEMLIMIT does not apply to all address spaces; thus, you cannot use the SET SMF or SETSMF commands to change an address space's MEMLIMIT value that was last set by any means other than the default SMF MEMLIMIT.

Note that a MEMLIMIT value can be set for all job steps through a generic REGION MEMLIMIT(xx) specification in the active SMFLIMxx parmlib member. However, for the purpose of this documentation, this is not considered the SMF default; rather, it is an SMFLIMxx specification match, which differs in the following ways:
  • An SMFLIMxx specification always takes precedence over the SMF default value.
  • An SMFLIMxx specification only takes effect at the start of the next job step, whereas the SMF default takes effect immediately even for currently running job steps.

Altering the default SMF MEMLIMIT value

Before altering the default SMF MEMLIMIT, keep in mind that only address spaces that are currently using the default SMF MEMLIMIT or will use it on the next JOB step start will be affected.

  • Before increasing the default SMF MEMLIMIT, you must consider how it might impact real and auxiliary resources, especially when many address spaces might be affected. How applications manage their memory restrictions can also have unexpected, and perhaps unpredictable, impact. Some application behavior conditions to consider are:
    • An application might never approach its MEMLIMIT, so increasing the MEMLIMIT would have no effect on that application.
    • An application might conditionally allocate virtual storage based on its MEMLIMIT at the start of a job step and, thus, might allocate more storage at the start of the next job step.
    • An application might attempt to allocate virtual storage on a periodic or demand basis and, thus, would increase its memory usage at some future time or without starting a new job step.
    • An application might allocate more virtual storage if it detects a change in its MEMLIMIT.
  • Before decreasing the default SMF MEMLIMIT, consider the following points:
    • The effect that the change may have on job steps that previously allocated or required more 64-bit high virtual storage than the new lower MEMLIMIT.
    • The dynamic affect that the change will have on currently running job steps that are were assigned the default SMF MEMLIMIT.
      • Their effective MEMLIMIT is always the maximum of what the last job step started with and the current MEMLIMIT. As such, their highest previous allocation amount is not taken into account.
      • Their current allocation may be higher than their effective MEMLIMIT. In such cases, they continue to run, but they cannot allocate any 64-bit high virtual storage because they are beyond their limit.
The MEMLIMIT for job steps that use the SMF system default limit is always the higher of the current SMF system default MEMLIMIT or the SMF default MEMLIMIT at job step start. Thus, if a SET SMF or SETSMF command changes the default MEMLIMIT for an address space that is already created, the following changes occur:
  • If the command increases the current default MEMLIMIT, all address spaces whose MEMLIMIT values are set through SMF run with the new, higher default.
  • If the command decreases the current default MEMLIMIT, all address spaces whose MEMLIMIT values are set through SMF use the higher of the new (lower) default MEMLIMIT and their original (higher) system default that was assigned at job step start time.

    Lowering the default MEMLIMIT makes it possible for address spaces to have more allocated virtual storage than their current MEMLIMIT. Their deallocation of high virtual storage will bring their allocated storage down, but new allocations are restricted by their current MEMLIMIT and not the previously attained highest allocation level that they achieved at any time in the past.

MEMLIMIT and the 64-bit high virtual services

The system enforces the MEMLIMIT on the IARV64 REQUEST=GETSTOR, IARV64 REQUEST=CHANGEGUARD, and any other 64-bit high virtual services that allocate virtual storage. Note that guard areas and memory objects allocated by authorized programs that specify the MEMLIMIT=NO attribute are not subject to MEMLIMIT restrictions. As guard areas are never backed, they do not consume real frames or auxiliary storage, but MEMLIMIT=NO areas do. The SMF 30 field SMF30HVH provides the high-water mark for high virtual allocations for a given address, which includes MEMLIMIT=NO and MEMLIMIT=YES but not the GUARDAREAS. When an unconditional request for new storage (either for a new memory object or for more usable storage in an existing memory object) causes the MEMLIMIT to be exceeded, the system abends the program. IBM recommends that programs use the COND parameter to make a conditional request and check the return code to ensure that the storage is available.

Using SMF type 30 records to track real and auxiliary storage usage

SMF type 30 (common address space work) records provide several fields related to 64-bit, high virtual private storage, real frame, and auxiliary storage usage. Note that SMF30HVH, the high-water value for the number of 64-bit high virtual bytes, includes MEMLIMIT=NO and MEMLIMIT=YES allocated storage but not guard areas, so it is useful for noting potential real and auxiliary storage usage. However, since it includes MEMLIMIT=NO allocations, it is not exactly what is compared to the MEMLIMIT.

End of change