gtpm1m17TPF V4R1 Migration Guide: 3.1 to 4.1

Working Storage and 16-MB Constraint Relief

Before this release, working storage had to be under 16 MB, restricting the number of tasks that could be run at a time. Also, some system tables, including large system tables such as the Systems Network Architecture (SNA) tables, the file address compute program (FACE) table, and the system interprocessor global table (SIGT), resided under 16 MB, along with the application program global areas for all I-streams. The location of these tables under 16 MB further limited the space available to you.

When ECB-controlled (E-type) programs wanted to get working storage, they had to do so in one of four fixed block sizes. C language programs did the same thing, using C functions that corresponded to pre-existing assembler macros. Contiguous memory was limited to 4095 bytes.

Beginning with this release, up to 2GB of total main storage are supported. With the use of the dynamic address translation (DAT) facility, TPF programs can view and manipulate the working storage located above 16 MB as if it was under 16 MB, therefore preserving the existing 24-bit addressing application program interface (API).

In the TPF 4.1 system, the concept of real (main) storage was expanded with the concept of virtual storage. The layout of virtual storage in the TPF 4.1 system is shown in Figure 6.

Transaction Protection and Data Integrity

The TPF 4.1 system separates and isolates information into types of address spaces. The two major address spaces are for the following:

In the TPF 4.1 system, each message has its own address space.

Through the use of the dynamic address translation (DAT) facility and low address protection, the TPF 4.1 system changes how storage is physically and logically used for system programs, application programs, and messages.

The DAT facility provides a virtual storage environment for the running program and detects whether the program is storing into address space other than its own. Each message has private storage both above and below 16 MB that is not accessible by other transactions. However, message information that needs to be shared can be shared by other messages through common storage below 16 MB. The TPF 4.1 system uses the DAT facility to provide each message with private areas that cannot be damaged by other messages or by the TPF 4.1 system when it operates on behalf of other messages.

This program isolation prevents some of the storage-sharing techniques used in previous releases. However, messages can still share common information in storage through a pool of working storage below 16 MB called the common area.

The low address protection facility protects the first 512 bytes of storage against any alteration by an application program or the TPF 4.1 system regardless of the storage key used.

Increased Main Storage for Application Use

By using the TPF 4.1 system, your application programs benefit from increased access to storage above and below 16 MB while maintaining the 24-bit application program interface (API) for existing TPF system programs. The concept of virtual storage replaces the concept of real (main) storage.

The TPF 4.1 system supports up to 2 GB of main storage. With the use of the dynamic address translation (DAT) facility, TPF system programs can view and manipulate storage located above 16 MB as if the storage was below 16 MB, removing the 16-MB constraint and allowing program access of up to 2 GB of main storage. Each message can use up to 2 MB of memory for its private use and then reference any other data that is available in main storage.

In the TPF 4.1 system, the use of storage is streamlined and more storage is available below 16 MB for application programs. Application programs that are written using 31-bit addressing can use a separate, exclusive 31-bit program area above 16 MB. All large TPF system tables are supported above 16 MB.

Allocating Working Storage

With the availability of storage above 16 MB, more working storage can be allocated than in previous releases. In addition, the TPF 4.1 system requires more storage.

Working storage allocation is now composed of:

In general, you should allocate the same number of ECBs as for the TPF 3.1 system. A rule of thumb for allocating frames is to allocate 10 frames for an ECB (but this will not work for all systems). You can use TPF data collection reports to calculate the number of frames you should allocate.

The number of IOBs required in the TPF 4.1 system is slightly less than was required in the TPF 3.1 system. This is because only DASD support code uses IOBs. All other functions that previously used IOBs (including tape support) now use SWBs. The relative numbers of IOB and SWBs should be changed accordingly.

You can use the ZCTKA command to change all working storage allocation values online if TPF data collection reports show that a problem exists with the original storage allocation values. See Modifying Storage Allocation Values Online for more information about the ZCTKA command.

Virtual file access (VFA) is of more importance in the TPF 4.1 system than it was in the TPF 3.1 system. VFA size is determined by the number of bytes of storage left after all blocks are allocated. When allocating storage be careful that you allow sufficient storage for VFA. The TPF 4.1 system enforces a minimum VFA size of 512 KB at run time by applying percentage reductions to the working storage block allocations.

See the TPF Database Reference for more information about VFA.

Figure 6. Virtual Storage Layout


Note:
TPF's virtual address spaces makes it impossible to use a full 2 gigabytes of real memory.