Terms to understand about CICS virtual storage

Before you can work with CICS® virtual storage, there are some terms that you must understand.

The z/OS® documentation explains:

24-bit, 31-bit, and 64-bit storage and addressing

A z/OS address space has areas of storage that are described as 24-bit storage, 31-bit storage, and 64-bit storage. These names reflect the addressability of each area of the address space.

A program that runs in an address space can reference all of the storage that is associated with that address space. The mechanism used by a program to reference the storage that is associated with an address space is called addressing.

A program on z/OS can run with 24-bit, 31-bit, or 64-bit addressing. A program that runs with 24-bit addressing can reference only 24-bit storage. A program that runs with 31-bit addressing can reference both 24-bit and 31-bit storage. A program that runs with 64-bit addressing can reference 24-bit, 31-bit, and 64-bit storage.

What are the line and the bar?

In information about CICS storage, you will see reference to storage above the line, below the line, above the bar, and below the bar. What are the line and the bar?

This terminology is rooted in the history of IBM® z/OS. You can read about this in A brief history of virtual storage and 64-bit addressability.

A program's ability to reference all of the storage that is associated with an address space is called addressability.

Way back in 1970, the IBM System/370 defined storage addresses as 24 bits in length, which allowed users access to 16 MB of virtual storage.

In 1983, IBM extended the addressability of the architecture to 31 bits. With 31-bit addressing, the operating system increased the addressability of virtual storage from 16 MB to 2 gigabytes (2 GB). The 16 MB address became the dividing point between the two architectures (24-bit addressing and 31-bit addressing) and is commonly called the line. As a consequence, in older documentation, you might see 24-bit storage referred to as below the line and 31-bit storage referred to as above the line.

In 2000, IBM further extended the addressability of the architecture to 64 bits. With 64-bit addressing, the operating system increased the addressability of virtual storage from 2 GB to a potential16 exabytes (EB) in size. (An exabyte is slightly more than one billion gigabytes.) Although the potential upper limit for this virtual storage is extremely high, there are practical limits to real storage, so parameters are used to limit the amount of storage that the address space can use.

31-bit addresses finish at 2 GB and 64-bit addresses start at 4 GB. The separating area between 2 GB to 4 GB is called the bar; it conveys the invalidity of any address that has set the 32nd bit. As a consequence, in older information, you might see 64-bit storage referred to as above the bar and 24-bit and 31-bit storage referred to as below the bar. Below the bar storage can be addressed with a 31-bit address. Above the bar storage requires a 64-bit address.

See these areas illustrated in Understanding a z/OS address space.

Addressing mode (AMODE) and residency mode (RMODE)

Every program that runs in z/OS is assigned two attributes: an addressing mode (AMODE) and a residency mode (RMODE). These attributes are assigned in the assembler program or when you link to the program. In documentation, you will often see AMODE and RMODE used as short-hand for addressing mode and residency mode.

The AMODE attribute specifies the addressing mode in which your program is designed to receive control. You can switch addressing modes in the program and have different AMODE attributes for different entry points in a load module.

The RMODE attribute indicates where in virtual storage your program can reside, and as a result, where it is loaded.

Storage keys and execution keys

One way that areas of storage are protected from each other is through keys. Each KB block of storage is associated with a control field called a storage key. (You might also see this called a storage protect key.) When a request is made for storage, the key that is associated with the request must match the storage key for the request to be allowed.

There are two types of z/OS storage in which you can run application programs:

CICS-key: This is used for most CICS system code and control blocks and, at your discretion, other code, and data areas that require protection from overwriting.
User-key: This is used for most application programs and their data areas.
Read-only key-0 protected: In addition to CICS-key and user-key storage, CICS also uses key-0 storage for separate dynamic storage areas that are called the read-only DSAs (RDSA and ERDSA). These DSAs are used for eligible reentrant CICS and user application programs. See CICS dynamic storage areas (DSAs).

There are two execution modes that are associated with the different types of storage. These are described with an execution key. When the program runs, CICS passes control to it in the key that you request when you define the program. These execution modes are:

CICS key: Many CICS system programs run in the execution mode of CICS key. A program that runs in CICS key execution mode has read/write access to both CICS-key and user-key storage.
User key: By default, application programs run in the execution mode of user key. A program that runs in user key execution mode has read/write access to user-key storage, but only read access to CICS-key storage.

z/OS storage, MVS storage and CICS-managed storage

In information about CICS storage, you will see the terms z/OS storage, MVS storage, and CICS-managed storage. Like the terminology about the line and the bar, these terms come from the product's long history.

MVS was previously the name for the z/OS operating system, and MVS storage described the operating system's virtual storage address space. In 2000, IBM renamed the operating system that was previously known as OS/390 and before that, as MVS, to z/OS. Today, the operating system's virtual storage address space is called z/OS storage, taking its name from the current name of the operating system. In summary, in today's product documentation, each term assumes the following meaning and context.

z/OS storage

In product documentation, z/OS storage refers to the virtual storage in a z/OS address space.

CICS-managed storage

CICS-managed storage refers to storage that CICS obtains directly from z/OS by z/OS GETMAIN and STORAGE OBTAIN requests or their equivalents, and storage such as dynamic storage areas (DSAs) that is directly allocated to CICS by z/OS.

MVS storage

Often the term is equivalent to z/OS storage. But occasionally in CICS context, this historical term, MVS storage, persists as shorthand for “the remaining z/OS storage that is not managed by CICS”. The remaining z/OS storage supports the following storage needs:

Non-CICS activities such as the allocation of non-CICS Language Environment® enclaves.
z/OS storage requests by CICS applications, other z/OS components, or vendor products.
For example, languages and components such as z/OS Communications Server, DL/I, or Db2® issue z/OS GETMAIN requests to obtain storage in which to build their own control blocks. These requests are met from z/OS storage below 2 GB.
CICS JVM servers
If you run Java or Node.js programs in a region, both 31-bit and 64-bit z/OS storage is allocated to each JVM or Node.js application that runs under the control of CICS.

Real storage and auxiliary storage

Real storage and auxiliary storage are types of physical storage. Real storage is physical storage that is located on the IBM Z® processor itself. Auxiliary storage is physical storage that is external to IBM Z, such as disk drives or tape drives. For information, see Physical storage used by IBM z/OS .