The latest version of IBM z/OS (3.1) was made available in September 2023. One of the features introduced was the ability to configure Dedicated Memory for specific address spaces, including MQ for z/OS.
Dedicated Memory provides a way to assign memory directly to the application at job-step start, while ensuring the memory remains with the job step until it ends. Even if the system is in a frame shortage, Dedicated Memory is not paged. Logically, Dedicated Memory is defined at the top of Central Storage to take advantage of systems configured with large amounts (>4 Terabytes) of memory that may otherwise be managed as part of the 2G LFAREA.
LFAREA is storage set aside at IPL that is used to satisfy fixed 1MB and 2GB page requests. Currently MQ for z/OS does not use LFAREA.
The Dedicated Memory overview provides the following description:
“The installation defines the amount of Dedicated Memory at system initialization time in IARPRMxx and memory is then assigned to applications based on SMFLIMxx specifications. SMFLIMxx has a broad set of filters to determine which applications are to be assigned Dedicated Memory including Sysname, Pgmname, and Jobname.
At job-step start, the specified amount of memory in 2G units of real storage is assigned to the address space where the job step is about to run. Once the memory is assigned, Dedicated Memory is locally managed within the address space, minimizing system overhead. Dedicated Memory is restricted to High Virtual private but can be used for all frame types: 4K, 1M fixed, 1M Pageable and 2G. While the job step is running, the system passively reforms 1M frames, but not 2G frames.”
One benefit of Dedicated Memory is that specific applications can be assigned specific amounts of Dedicated Memory, unlike the LFAREA which is a pool available to any application requesting fixed 1MB or 2GB pages, such that a greedy application using all the LFAREA could prevent other applications from starting.
Ideally a system would have sufficient memory such that frame shortage does not occur, but it is recognised that it is not always possible to avoid this situation. The use of Dedicated Memory for key applications can minimize performance impact to those applications in the event of frame shortage, and this is also true for MQ for z/OS.
The use of Dedicated Memory with MQ for z/OS is currently limited to 4K frames.
Setting up Dedicated Memory:
To allocate the memory, the system needs an IARPRMxx member where a specific amount of dedicated memory is reserved at IPL.
This would take the format of:
[DEDICATEDMEMORY(mmG|nnT)]
[PROMPT(NO|YES)]
The updated IARPRMxx member is then referenced by the RSM=xx parameter in the IEASYSxx member as indicated in the following diagram.
Following an IPL, the command “/F AXR,IAXDMEM DMEM” can be used to confirm how much storage has been allocated, for example:
IAR067I DEDICATED MEMORY V1.0
16.0GB : TOTAL SIZE
0.0GB : OFFLINE SIZE
14.0GB : UNASSIGNED
2.0GB : SYSTEM USE
If the system has not yet been configured and IPL’ed with Dedicated Memory, the above command will report 0 values for each of the attributes.
Dedicated Memory and LFAREA
Prior to configuring Dedicated Memory, one of our LPARs was configured with 144GB of real memory and 20% of that storage was set aside for LFAREA, as represented in the diagram:
Note: To confirm the allocation and current usage of LFAREA, use the following command: /D VIRTSTOR,LFAREA
Following the configuration of 16GB of Dedicated Memory, the memory from the resulting IPL can be represented as follows:
Note: Retaining the original allocation of 144GB of real memory whilst adding 16GB of Dedicated Memory means that:
- the LFAREA reduced from 28GB to 24GB.
- the remaining real memory reduced from 116GB to 104GB.
General use of Dedicated Memory and LFAREA
If an application is eligible for Dedicated Memory and LFAREA storage, it will initially allocate from the Dedicated Memory pool and then excess will be allocated from LFAREA. If the LFAREA does not have sufficient storage, the application may terminate.
If the application is only eligible for Dedicated Memory, insufficient Dedicated memory will result in the “regular” storage being used for the additional requirements – the application will continue to start but may be at risk of frame shortage for the storage assigned outside of the Dedicated Memory allocation.
Assigning Dedicated Memory to specific address spaces
On a system configured with dedicated memory, a PARMLIB(SMFLIMxx) member can be configured to reserve the dedicated memory to specific job names, for example we created USER.PARMLIB(SMFLIMMQ) as follows:
/* To pick up default plus this version: /T SMFLIM=(00,MQ) */
/* */
/* Give MQ subsystems VKW1 and VKW2 each 4GB dedicated memory */
REGION JOBNAME(VKW1MSTR,VKW2MSTR)
DEDICATEDMEMORY(4G)
This will reserve 4GB of Dedicated Memory to each of the job names specified.
As the comment in the PARMLIB suggests, we would enable this using the command:
/T SMFLIM=(00,MQ)
Specifying multiple options using “00,MQ” allows the system to pick up the default system-wide settings and then override with our specific options.
To revert to our system default we would issue:
/T SMFLIM=(00)
Notes:
1. On a system with the SMFLIMxx option enabled but without any dedicated memory, the queue manager(s) may fail to start, reporting:
IAR063I NO DEDICATED MEMORY WAS ASSIGNED. DEDICATED MEMORY REQUESTED=4G, AVAILABLE=0G
2. If the SMFLIMxx option specifies more Dedicated Memory than is available on the system, the application may fail to start, reporting:
Step cancelled due to insufficient Dedicated Memory value (00004G,00004G) by policy - SMFLIMxx
3. It is necessary to start the application after it has been Dedicated Memory has been assigned using the SMFLIMxx PARMLIB.
How much Dedicated Memory to assign?
In the MQ queue manager, Dedicated Memory can be primarily used by buffer pools defined with PAGECLAS(FIXED4KB) and Shared Message Data Set (SMDS) buffers (DSBUFS).
The MQ queue manager is also able to use 64-bit storage for other uses as documented in MP16’s “Virtual Storage usage” section, including queue indices, thread storage, security information, Intra-Group Queuing (IGQ), and CHLAUTH cache.
All the above listed storage uses within the MQ queue manager are able to use Dedicated Memory.
Consider the amount of storage allocated to the queue managers’ buffer pool and SMDS buffers and allow sufficient Dedicated Memory to ensure that subsequent changes are capable of being contained within the specified storage.
From MQ for z/OS 931 CDR, 64-bit channel initiator storage used for server-connection channels connections is also able to use Dedicated Memory.
When using Dedicated Memory, it is suggested that sufficient storage is allocated for each application. For applications using 1MB or 2GB pages that can use LFAREA, insufficient Dedicated Memory allocation will result in the application attempting to use storage from LFAREA.
In this instance, insufficient LFAREA may result in the application failing to start.
Using SMF 30 data to determine size of Dedicated Memory for MQ
The Dedicated Memory documentation suggests calculating Dedicated Memory requirements using the following SMF 30 data:
- SMF30HVR – High water mark of the number of real storage frames that are used to back 64-bit private storage.
- SMF30HVA – High water mark of the amount of auxiliary storage that is used to back 64-bit private storage.
- SMF30_InUseAs2GHWM – High water mark of the number of 2G frames in use by the job step.
((SMF30HVR+SMF30HVA)*4K + SMF30_InUseAs2GHWM*2G) is a rough upper bound on memory usage for a particular job step and can be used to estimate the amount of Dedicated Memory to assign.
Note: If Dedicated Memory is already assigned to your MQ queue manager, the calculation above will identify any shortfall in Dedicated Memory allocation.
Does Dedicated Memory help performance?
Our systems are intentionally oversized such that we are not affected by instances of frame shortages, so for our performance measurements we do not see any benefit from Dedicated Memory being assigned to the MQ subsystems.
On busier systems with a more variable workload, frame shortage may occur resulting in paging. This is still normal behaviour, but both Dedicated Memory and LFAREA provide mechanisms to reduce the impact of paging in high priority applications and subsystems that allocate page-fixed storage.
Why use Dedicated Memory?
For applications that use large amounts of page-fixed memory that might previously have been allocated from LFAREA, using Dedicated Memory means that there is less risk that another application might have allocated so much memory from the LFAREA pool that this application may fail to start.
For applications such as MQ for that use page-fixed memory that is allocated in 4K pages and cannot taken from LFAREA, the primary benefit is that the storage assigned will be less likely to suffer from fragmentation but Dedicated Memory is also a good way to ensure the memory required by MQ is available prior to queue manager start.