Using a memory object

To use the storage in a memory object, the program must be in AMODE 64. To get there, a program in AMODE 24 or AMODE 31 uses the assembler instruction SAM64. While in AMODE 64, a program can issue only the IARV64 macro. The parameter lists the program passes to IARV64 can reside above or below the bar.

To invoke macros other than IARV64, a program must be in AMODE 31 or AMODE 24. This restriction might mean that the program must first issue SAM31 to return to AMODE 31. After a program issues a macro other than IARV64, it can return to AMODE 64 through SAM64. To learn whether a program is in AMODE 64, see Setting and checking the addressing mode.

Managing the data, such as serializing the use of a memory object, is no different from serializing the use of an area obtained through GETMAIN or STORAGE.

Although only one macro can be issued in AMODE 64, other interfaces support storage above the bar. For example, the DUMP command with the STOR=(beg,end[,beg,end]...) parameter specifies ranges of virtual storage to be dumped. Those ranges can be above the bar.

In summary, there are major differences between how you manage storage below the bar and how you manage storage above the bar. Table 1 can help you understand the differences, as well as, some similarities. The first column identifies a task of concept, the second column applies to storage below the bar; the third column applies to storage above the bar.

Table 1. Comparing Tasks and Concepts: Below the Bar and Above the Bar
Task or concept	Below the bar	Above the bar
Obtaining storage	GETMAIN, STORAGE, CPOOL macros and callable cell pool services. On GETMAIN and STORAGE, you can ask to have a return code tell you whether the storage is cleared to zeros.	IARV64 GETSTOR service creates memory objects; storage is cleared to zeros.
Increments of storage allocation	In 8–byte increments.	In 1-megabyte increments.
Requirements for requestor	GETMAIN cannot be issued by an AR mode caller. STORAGE can be issued by an AR mode program. CPOOL cannot be issued by a program in AR mode. Callable cell pool services can be issued in either mode.	IARV64 can be issued by a program in AR mode.
Freeing storage	FREEMAIN, STORAGE, CPOOL macros, and callable cell pool services. Any 8-byte increment of the originally-obtained storage can be freed. An entire subpool can be freed with a single request. At task termination, storage owned by task is freed; some storage (common, for example) does not have an owner.	IARV64 DETACH service. Storage can be freed only in 1-megabyte increments. All memory objects obtained with a specified user-defined token can be freed with a single request. At task termination, storage owned by task is freed; all storage has an owner and that owner is a task.
Notifying the system of an anticipated use of storage	PGSER LOAD request PGSER OUT request.	IARV64 PAGEIN and IARV64 PAGEOUT services.
Making a range of storage read-only or modifiable	PGSER PROTECT request and PGSER UNPROTECT request.	IARV64 REQUEST=PROTECT option.
Discard data in physical pages and optionally clear the pages to zeros.	PGSER RELEASE request always clears the storage to zeros. Note: PGRLSE, PGSER RELEASE, PGSER FREE with RELEASE=Y, and PGFREE RELEASE=Y may ignore some or all of the pages in the input range and will not notify the caller if this was done. Any pages in the input range that match any of the following conditions will be skipped, and processing continues with the next page in the range: Storage is not allocated or all pages in a segment have not yet been referenced. Page is in PSA, SQA or LSQA. Page is V=R. Effectively, it's fixed. Page is in BLDL, (E)PLPA, or (E)MLPA. Page has a page fix in progress or a nonzero FIX count. Pages with COMMIT in progress or with DISASSOCIATE in progress.	IARV64 DISCARDDATA service. CLEAR=YES must be specified to guarantee the storage is cleared to zeros on the next usage.
Fetch protection attributes	Apply to the entire allocated area.	Apply to the entire allocated area.
What the area consists of	System programs and data, user programs and data.	User data only.
Performing I/O	VSAM, BSAM, BPAM, QSAM, VTAM®, and EXCP, EXCPVR services.	EXCP and EXCPVR services.
Accessing storage	To access data in the 2–gigabyte address space, a program must run in AMODE 31 or AMODE 64. S/390® and z/Architecture® instructions can be used.	To access data in the 16-exabyte address space, a program must run in AMODE 64. To load an address of a location above the bar into a GPR, a program must use a z/Architecture instruction.