gtpc3m0x | Concepts and Structures |
The TPF system defines several types of virtual address spaces, which are mappings of main storage:
These mappings are shown in Figure 21.
An application program (ECB-controlled program) uses the EVM mapping of main storage when processing. The control program uses both the SVM and EVM mappings of main storage depending on the type of service it provides at any given time.
Figure 21. Virtual Storage Layout
Main storage consists of fixed storage (in earlier versions of the TPF system, fixed storage was known as permanent core) and working storage. Fixed storage refers to those areas of main storage whose sizes are determined at system generation (that is, the sizes are not determined dynamically during system operation), such as system data records and tables. The term working storage refers to those areas of main storage that are (1) available to application programs as system resources and (2) the system control blocks used for managing an Entry.
The maximum amount of working storage in the TPF system is dependent upon the available amount of main storage minus the amount of fixed storage. The amount of working storage available to application programs depends on the number of system control blocks, common blocks, and other system resources in use at any given time.
Fixed storage is permanently allocated for specific purposes by the control program. It is not available as a system resource for use by an application program (ECB-controlled program).
Working storage is divided into distinct block types: I/O blocks (IOB), system work blocks (SWB), entry control blocks (ECB), 4K frames, and 4K common frames. These block types are referred to as physical storage blocks.
Application programs can request temporary storage in the form of logical storage blocks, which are of fixed sizes: 128, 381, 1055, and 4095 bytes.
4K frames and 4K common frames are used by the control program to satisfy requests from ECB-controlled programs for storage in a standard block size (128, 381, 1055, or 4K). The control program manages the allocation of 4K frames and 4K common frames.
A 4K frame is a 4KB block of virtual storage; logical storage blocks are allocated to an ECB from this physical block. These storage blocks are private to an ECB.
A 4K common frame is a 4KB block of virtual storage. When an Entry requests a common block, it is allocated from this physical block regardless of its size. These blocks can be accessed by all ECBs now active in the central processing complex (CPC).
Logical storage blocks are used for data records, message blocks, keypoint records, and program segments. These blocks can be private to an ECB or shared between ECBs depending on whether they are allocated from a 4K frame or from a 4K common frame. When logical storage blocks are located in an area private to the ECB (that is, a 4K frame), they are known as private logical blocks or just logical blocks. When logical storage blocks are located in 4K common frames, they are known as common blocks and can be used to pass information among ECBs. See Figure 21.
The relationship of a frame to (private) logical blocks is:
One 4K frame |
= one 4KB logical block = three 1055-byte logical blocks = ten 381-byte logical blocks = ten 128-byte logical blocks |
The relationship of a common frame to common blocks is:
One 4K common frame |
= one 4KB common block = one 1055-byte common block = one 381-byte common block = one 128-byte common block |
Notice that it is less economical spacewise to use common blocks than logical blocks. Furthermore, there is no entry protection for common blocks; these blocks are accessible by all Entries (in a CPC) and therefore risk damage by any Entry.
When an application program requests a logical storage block, the control program service routine puts the block address into one of the 16 slots in the ECB called core block reference words (CBRWs). Each CBRW is associated with a data level identified in macros as Dn (for data level n) where n is a hexadecimal number between X'0' and X'F'. For example, D3 is known as data level three.
An application program can use:
The application can also allocate variable length storage from the system heap. Unlike heap storage, system heap storage is not returned to the system when the ECB exits; the system heap can be viewed as persistent storage. The system heap storage, in this case, is persistent across ECBs but temporary from the system point of view in that it can be released.
See Figure 21 for a sample virtual storage layout.
The get core macro (GETCC) dispenses a logical storage block in a standard size (128, 381, 1055, or 4K). When the Entry requests a (private) logical block, it is dispensed from the ECB private area, whereas when the Entry requests a common block, it is dispensed from a 4K common frame.
The ECB private area is a minimum of one 4K frame plus the size of an ECB currently defined as 12K. The actual size of the ECB private area depends on the storage resource requests by an entry up to a maximum of 1MB.
The ECB private area is private to an Entry; that is, it is not accessible by other Entries. Regardless of its actual location in main storage, an Entry views its EPA as if it is located below 16MB.
Heap storage cannot be used as logical storage blocks. This means that heap storage cannot be used as I/O buffers for I/O macros such as FINDC and FILEC. However, heap storage can be used as an I/O buffer for macros such as FILNC and tape write.