Operating Systems

Private memory objects are accessible only in the address space where the program that obtained the memory object resides. All VSE tasks of the program (partition) may access the memory object. Private memory objects are freed via IARV64 services or when the creating task terminates.

Shared memory objects can be shared between programs executing in different address spaces. A program must register its interest via an IARV64 service before the system provides access to the memory object. All tasks of that program have access to the shared memory object. The interest of a program can be removed with an IARV64 service or will be removed at main task termination. The shared memory object must  be freed by using an IARV64 service. It will not be freed at task termination of the creating task.

In z/VSE 5.1, any VSE task may change the PSW key to key 9 in addition to their partition key. That allows a program to change data allocated with storage protection key 9. With shared memory objects, user programs may allocate areas with storage protection key 9 and share the area with user programs in other partitions. That provides more options for applications.

The address space layout below the bar (see Figure 1) doesn’t change. A 64-bit address space layout just adds the memory objects above the bar. The partition allocation and setup don’t change. The virtual storage size (VSIZE) as defined at Initial Program Load (IPL) now includes the size of memory objects and the sizes for data spaces, and private and shared areas. The VSIZE is still limited to 90GB.

Figure 2 shows a 64-bit address space layout. Before a program can obtain a memory object, the size for all memory objects must be defined. This occurs via the MEMLIMIT parameter of the new SYSDEF MEMOBJ Attention Routine/Job Control command. The virtual size of all private and shared memory objects is included in the MEMLIMIT specification. The SHRLIMIT parameter defines the limit for shared memory objects. MEMLIMIT doesn’t reserve virtual storage; it just defines a limit. You can change the MEMLIMIT and SHRLIMIT anytime, but they become active only if all memory objects are freed. This is a flexible way to allow storage allocations without a re-IPL or change to the storage/partition layout below the bar.

There are a few considerations for z/VSE’s 64-bit virtual implementation. As mentioned, z/VSE only implemented the HLASM support. High-level languages such as COBOL, C, RPG, or PL/I don’t provide 64-bit register or 64-bit addressing mode support. z/VSE’s load services and linkage editor don’t support AMODE 64; the program may get control in 24- or 31-bit mode and can switch into AMODE 64 during program execution. All z/VSE services such as Supervisor, VSE/POWER, VSAM, or BAM services must be called in AMODE 24 or 31. Parameter lists and I/O data areas must stay below the bar. Programs in Interactive Computing and Control Facility (ICCF) pseudo partitions can’t use IARV64 services or execute in AMODE 64.

CICS programs may use 64-bit registers, but must save the high order 4 bytes of the general-purpose register before invoking a CICS service. The program must restore them after the CICS service returns. CICS services can’t be called in AMODE 64.

Benefits of 64-Bit Virtual in z/VSE



A program can easily access large amounts of data. It must only adapt to the new IARV64 services and switch into AMODE 64, where access to data above the bar is necessary. This may require additional real storage to reduce or avoid paging, depending on performance requirements. The 64-bit virtual support programs may better exploit a larger amount of real storage.

Compared to data spaces, access to the 64-bit area is less complex. The program doesn’t need to manage access register content. The area above the bar is just an extension of the address space, which also reduces program complexity. It can be used just like a program uses GETVIS (GETMAIN) storage. In AMODE 64, the program has access to data in 24-, 31-, or 64-bit virtual storage. z/VSE’s 64-bit virtual implementation has no impact on existing APIs. Programs can manage large amounts of data in virtual storage and improve the sharing of virtual areas between address spaces.

One of the first exploiters of 64-bit virtual support is the IPv6/VSE TCP/IP product. It allocates TCP/IP buffers for IPv4 or IPv6 communication in memory objects if a MEMLIMIT is defined and enough virtual storage is available.

Virtual addressing with z/VSE has progressed rapidly in a short time; IBM customers can benefit greatly from fully exploring the continuously evolving capabilities.

 

2 Pages