MAINFRAME > Tips & Techniques > Application Development

Monitor 64-Bit Storage Allocations

My RXSTOR64 REXX program can be used to see the MEMLIMIT and MEMLIMIT source for every address space even if there is no 64-bit usage.

My RXSTOR64 REXX program can be used to see the MEMLIMIT and MEMLIMIT source for every address space even if there is no 64-bit usage.

64-bit virtual storage first became available in z/OS V1R2. This storage is also known as “above the bar” storage. The “bar” refers to the 2 GB line which was the 31-bit virtual addressing limit since 370-XA was introduced and was the virtual addressing limit for MVS OSs starting with MVS/XA and continuing through MVS/ESA, OS/390 and z/OS V1R1. The initial 64-bit virtual support in z/OS V1R2 was for private storage only, but in z/OS V1R5 IBM introduced 64-bit shared virtual storage as well.

64-Bit Memory Overview

Starting with z/OS 1.5, the 64-bit address space memory has an area that’s reserved between 2 GB and 4 GB and isn’t used by z/OS even though it’s supported by z/Architecture. This was a convenient (and very wise) design that the developers came up with so the OS could avoid misinterpreting 31-bit addresses as 64-bit addresses in 64-bit programs processing 32-bit address words that had the high order bit set on either unintentionally (leftover garbage) or intentionally for something meaningful. Call this a lesson learned from the 24-bit to 31-bit XA jump. Trying to use an address in this “dead zone” will result in an 0C4 abend since the addresses are never valid in z/OS. In essence, the “bar” is really 2 GB thick in z/OS.

Memory Objects

z/OS 64-bit virtual memory is organized as memory objects which programs create and manage using the IARV64 macro. The memory objects are allocated in 1 MB increments and are on a 1 MB boundary. The memory is intended to be used for data only at this point, not executable instructions. There is no RMODE=64 binder support (and may never be).

Private memory objects can allocate usable virtual storage and an additional area called the guard area. The guard area is also specified in 1 MB increments on a 1 MB boundary. Storage in the guard area isn’t usable until IARV64 CHANGEGUARD is requested. In z/OS V1R5, IBM added support for multiple guard areas in addition to shared 64-bit memory.

Shared 64-Bit Memory

The amount of 64-bit shared virtual memory available in a system is defined by the installation’s system programmer in the IEASYSxx parmlib member with the HVSHARE parameter. The default HVSHARE setting is 510 TB (yes, terabytes—a very large number!) but can be specified anywhere in the range from 0 GB to 1 exabyte in 1 GB increments for lower numbers. There’s no guard area with shared memory objects. While 510 TB may seem like a large number, I see no reason to change the default since there are plenty of those 64-bits left to go around.

Mark Zelden is a senior software and systems architect for Zurich North America with more than 20 years of experience providing solutions for corporate IT organizations. Mark has authored utility programs that have been included on the CBT tape, articles for various industry magazines and has his own Web site, Mark’s MVS Utilities, at http://home.flash.net/~mzelden/mvsutil.html.


comments powered by Disqus

Advertisement

Advertisement

2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

A Beginner's Guide to the REXX Programming Language on z/OS

Reading and Writing Files in the REXX programming language on z/OS.

MAINFRAME > TIPS & TECHNIQUES > APPLICATION DEVELOPMENT

Application Management is Important to the Entire Process

MAINFRAME > TIPS & TECHNIQUES > APPLICATION DEVELOPMENT

Application Testing: Giving Users What They Need

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters