We are definitely not in Kansas, anymore!

OMVS resource limits which relate to MVS limits are:

the maximum amount of CPU which can be used by each process - RLIMIT_CPU
the maximum amount of virtual storage which can be used by each process - RLIMIT_AS

There are two limits associated with each resource - a soft limit (the current limit) and a hard limit. A "super user" can alter the hard limit; a normal user can alter the soft limit to any value less than the hard limit. The hard limit value is set in the BPXPRMxx parmlib member. For instance, MAXASSIZE establishes the upper limit for RLIMIT_AS and MAXCPUTIME sets the upper limit for RLIMIT_CPU. Values from the OMVS user profile supplied by the security product can be used to set upper limits for specific users: ASSIZEMAX for RLIMIT_AS and CPUTIMEMAX for RLIMIT_CPU.

Note that RLIMIT_AS values, MAXASSIZE and ASSIZEMAX take into account the total of above and below the line storage, so a RLIMIT_AS value of 74M could correspond to 64M available above the line and 10M below.

Initial Values for Limits

If an OMVS process is started from an existing MVS address space, the soft limits are set using information from that address space. If the MVS values exceed the specified hard limit, then the hard limit is set to the soft limit. If the MVS process is not started from an existing MVS address space, then the hard limit values from BPXPRMxx are used.

The RLIMIT_AS and RLIMIT_CPU values are set from the step limits when an OMVS process is started from an existing MVS address space. Under OS/390, OMVS did not take the CPU TIME limit at the step level into account, which could result in unexpected results when _BPX_SHAREAS=YES since two different CPU limits could be applied to the same job step. This problem was corrected in z/OS.

Controlling Resource Usage

The _BPX_SHAREAS environment variable can affect resource limit handling. For example, normally, the RLIMIT_CPU value applies to each process. This would mean that each process could use up to RLIMIT_CPU seconds of CPU time. However, if _BPX_SHAREAS=YES, resources already consumed by non-OMVS activity in the same address space may limit the resources available to an OMVS process.

REXX EXECs GETRLIM and SETRLIM on the OMVS REXX page can be used to display or change resource limits for a process. Changing the limit values may alter the MVS limits for the existing address space in a _BPX_SHAREAS=YES environment.

SMF exits such as IEFUSI and IEFUTL may need to be reworked to take OMVS work into account. If IEFUSI alters the REGION limits for OMVS work, then the hard limit value for ASSIZE in BPXPRMxx will be ignored.

When the CPU resource limit is exceeded in a shared address space, the behaviour will be different depending on whether or not the OMVS process is in control at the time. For an OMVS process, SIGXCPU is sent to the process and a small extension is allowed. If this is also exceeded, the process is killed. This may not appear as an S322 abend. An SEC6 abend with reason code FD1D indicates that a process was killed due to an unhandled SIGXCPU signal.

Note: Due to a Unix System Services defect, the CPU limit can be calculated incorrectly in CPU timer units rather than CPU seconds. This can lead to a discrepancy of approximately 5% from the z/OS CPU limit.