Simplify mainframe storage management with IBM SMFLIMxx

By offering a more flexible, rule-based approach, SMFLIMxx can help mainframe programmers get a better grasp on virtual storage.

To cope with an aging computer mainframe workforce, IBM is attempting to appeal to younger developers. The vendor is adding web-based administrative tools that should look familiar to millennial graduates. The same logic applies to Rational Developer for z Systems, which brings modern development tools to legacy languages like COBOL and PL/1. Lastly, IBM wants to reduce the amount of custom Assembler code required to run a mainframe.

SMFLIMxx -- a parameter library (PARMLIB) member -- is a step in that direction, and also helps simplify virtual storage management. A PARMLIB is where mainframe OS configuration information is typically held.

The role of SMFLIMxx in mainframe storage management

It can be a challenge to manage virtual storage on a mainframe. A mainframe address space is broken into user, system, common and private areas, each of which could be above or below "the line" or "the bar."

User storage starts at the bottom of a private region and grows upward. Conversely, the system gets storage from the top of the region and works downwards. This works unless something -- usually the application program -- gets greedy.

Abends can occur when the upward growing application storage meets the downward marching system memory. In some cases, an address space doesn't even have enough memory to process an abend, resulting in some nasty recursive error recovery scenarios.

To set private area boundaries, an application needs enough storage to work efficiently, but the system needs sufficient space to act on the application's behalf. In the past, controlling private region size was a tug of war between a user's job control language (JCL) and the job initiation (IEFUJI) or step initiation (IEFUSI) exits. With z/OS 2.2, the battle continues, but now there's a new PARMLIB member taking over for the exits.

Naming conventions for system modules

IBM gives system modules a three byte prefix, followed by a description of their function. For instance, job management modules start with IEF, utilities with IEB and CICS modules with DFH. Therefore, in the older style exit names, the first three bytes name the component, the fourth byte is "U" for user, and then there is the description of what it is. Thus, the SI from IEFUSI stands for Step Initiation and JI for Job Initiation.

SMFLIMxx offers a more flexible, rule-based method for mainframe storage management.

Each statement in the PARMLIB member begins with the word REGION, followed by a series of filters that describe the address spaces to which the rule applies. Among the filter keywords are specifications for job name, job class, subsystem and user. Each filter contains up to 8 values. The filter values may be generic, with an asterisk that masks zero or more characters, or a question mark that masks one character.

The system applies OR logic to multiple filters on the same REGION statement. Since more than one rule may apply, the last applicable rule controls the job's storage.

SMFLIMxx offers a more flexible, rule-based method for mainframe storage management.

The attributes, which follow the filters, present a great amount of flexibility. The simplest attribute, MEMLIMIT, controls the maximum amount of 64-bit storage available to the address space, which overrides MEMLIMIT in the job's JCL, as well as the value in IEASMFxx. MEMLIMIT can be expressed in megabytes, gigabytes, terabytes or petabytes.

Options for mainframe storage management below the bar

Below the bar, mainframe storage management is a little more complicated. Systems programmers can take the traditional route and explicitly limit the storage available to an application program above and below the 16 megabytes line with the REGIONABOVE and REGIONBELOW attributes. Alternatively, the attributes SYSRESVABOVE and SYSRESVBELOW set aside an amount of storage for the system's use.

REGIONABOVE and REGIONBELOW set absolute limits so you can control exactly where an application program will run out of storage. On the other hand, if set too high or to NOLIMIT, a hungry program may consume all available private memory, which could lead to unintended consequences.

SYSRESVABOVE and SYSRESVBELOW are more flexible in that an application program can use all the storage not reserved to the system. This also means the storage available to an application could expand or contract without requiring any changes to JCL, system exits or SMFLIMxx's REGION parameters. If set too high, however, some system memory, which a hungry application could use, may remain unused.

Check parameters, settings with SMFLIMxx

IBM recommends being careful with SMFLIMxx's settings. An iterative approach may work best, especially since you can change the parameters dynamically with the SETSMFLIM command.

Set the SYSRESV parameters and specify NOLIMIT for REGIONBELOW and REGIONABOVE, which should reserve enough storage for the system to do things such as open data sets, manage tasks and track storage usage, and let the application have the rest. It provides flexibility in that more storage will automatically become available to an application program if the private area should grow.

SMFLIMxx does not totally replace IEFUJI and IEFUSI because both exits have other things to do besides manage virtual storage. In the future, we may see new PARMLIB members that enable customers to get rid of them altogether.

Next Steps

IBM tries new tools to attract millennials to the mainframe

Monitor mainframe performance with these tools

New mainframe workforce emerges

Dig Deeper on IBM system z and mainframe systems