We are definitely not in Kansas, anymore!OMVS resource limits which relate to MVS limits are:
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.
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.
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.