gtps4m0q | System Generation |
Application programs, including system supplied programs that are ECB controlled, may reside in one of the following program areas:
The TPF release includes a number of ECB controlled system programs. These programs plus the core-resident control program CSECTs comprise the TPF online system programs. SIP employs a program dependency table to eliminate those programs and CSECTs which are not required for the functions selected via SIP Stage I macros.
Disk space for programs is defined by a SIP RAMFIL statement allocating #PROGx records using the RECNO parameter. All program records are 4K. Space for programs in main memory is specified by the APSIZ24 and APSIZ31 parameters of the CORREQ macro.
During Stage I execution, SIP processes the SPPGML macro to determine which programs and versions must be assembled, link-edited, and loaded during Stage II.
The program tables (SPPGML) are divided into 12 separate groups:
In addition to the program name, each entry contains a version number, if applicable. The size of these tables is preset at a maximum limit based on the needs of the current release and an estimated number of user real-time programs. You may need to modify or add to these tables before Stage I.
IBMPAL is a file containing a list of released programs and other structures that must be allocated as part of the TPF system. Each entry is in a format that can be run directly into the allocator SALO. IBMPAL statements are also used to allocate transfer vectors, spare slots, and GFS IDs. For ISO-C, only ICL entries (libraries or dynamic load modules (DLMs)) require corresponding PAL entries. ISA and ISC entries do not require PAL entries.
Most IBMPAL statements are program allocations. Programs can be allocated as either core resident, indicated by CR, or file resident, indicated by FR. The older TPF notions of corefast and coreslow are no longer meaningful. Certain ECB-controlled programs (for example, those that are really data records and those with non-reentrant code) are allocated as file resident.
All assembler programs reside on DASD as 4KB #PROG records. ISO-C programs reside in 1 #PROGn record and 2 or more #XPRGn records, which are allocated as 4KB. Therefore, the programs may be larger than 4KB when loaded into main storage.
SALO generates the program allocation table (PAT), which is read during IPL. The PAT (IDSPAT) serves as the online system allocator. It also contains the file and main storage addresses of all E-type programs. PAT information is used by CTIN in carving out the core resident areas.
Assembler and TARGET(TPF) C programs are loaded to #PROG records. Each ISO-C program requires a #PROGn record and at least 2 #XPRGn records. For ISO-C, the #PROGn record contains the ordinals of the #XPRGn records and the #XPRGn records contain the compiled program text and ADCON relocation information. Both #PROGn and #XPRGn records are program version record (PVR) unique. #XPRGn records need to use the RESTORE=NO parameter on their RIAT definitions. This ensures that they are not restored.
The class of a program can be any one of the following: shared, private, IS-unique, common, or unprotected. When restart is processing the PVRs and it encounters a C load module, it changes the core copy of the PAT to always show the class attribute as shared, although the file copy of the PAT still contains the original allocation. This is not a problem; DLMs and libraries that are allocated with different characteristics do not need to be changed.
The amount of memory allocated to program areas is affected by input to the SIP CORREQ macro. The APSIZ24 and APSIZ31 parameters in the CORREQ macro estimate the amount of main storage to be used for core resident programs, often application programs. A program base requires #PROGn, #XPRGn, and #PVRn records.
RAMFIL statements control the amount of space available on each DASD device. The RECID parameter is set to the various record types (#PROG1-8) for both TPF-supplied and user-supplied programs. The RECNO parameter specifies the total number of slots to reserve on disk for image x.
Programs allocated to the application program area are ECB-controlled programs assigned to main storage in the online environment. These programs are classified as core resident programs.
They are loaded into one of the core resident program areas (CRPAs) in main storage either above or below the 16M line depending on whether their MODE is 31-bit or 24-bit. Both user application and system file resident ECB controlled programs may reside in the program areas. C load modules, dynamic load modules (DLMs), and libraries all run in 31-bit mode.
Programs in the core resident program area are accessed via ENTER-type macros.
A core resident program adheres to all the reentrant (recursive) conventions implied by the enter-back mechanism. Programs with anticipated high activity are classified core resident and assigned to main storage. Several entry control blocks (ECBs) may be associated with the same reentrant core resident programs.
The size of the core resident program areas has a direct bearing on system performance. This is quite understandable because the larger the main storage area the greater the number of programs which can reside in main storage. Consequently, the number of accesses to files for programs will diminish in an inverse proportion to the number of core resident programs allocated.
For systems with a large amount of available main storage and a large application, it is desirable to have at least the number of core resident applications times 4 KB of the main storage allocated to the core resident program areas. Data collection/reduction should be used to modify program allocations for optimum performance.
The APSIZ parameters of the CORREQ macro are used to estimate the size of the core resident program areas in 1 KB blocks. A minimum of 1000 or more blocks must be specified for the required CORREQ core resident system programs, and the two areas (24-bit and 31-bit) together must be at least 1000 blocks.
A list of the released programs that should reside in the core resident program area can be found at the beginning of the IBMPAL deck.
The standard C library and TPF API libraries used for ISO-C reside in the core resident program area (CRPA).
Reserve a portion of CRPA space for user C programs. Once you enter a ZOLDR ACCEPT or ZOLDR DEACTIVATE command and a C load module is no longer needed (because no ECBs will execute it), the storage used by the C load module is released.
You need a #PROGn record for each C language program along with at least 2 #XPRGn records. A formula can be used to estimate the approximate number of #XPRGn records needed. Each directory record can hold approximately 500 entries and each program record is 4KB.
HPO feature users of MDBF should be aware of the fact that program allocation is done separately for each subsystem, with the BSS done first. In effect, this results in a core resident program area for each subsystem. The core resident program areas are laid out sequentially, by subsystem. For example, the size of each subsystem's area is estimated via the APSIZ parameter of the CORREQ macro for each subsystem. The size required by the system is the sum of the sizes of the subsystems, both above and below the line.
One method for estimating a value for APSIZ is:
"Total Area" divided by 1024 = APSIZ
This should be done for each core resident area, one above the 16M line and one below the line.
Immediately following the core resident programs above the 16M line reside
the following programs.
Table 1. Application Program Areas above the 16M Line
Program Name | Notes |
---|---|
General File Loader Online Segment (ACPL) | After running SIP, verify the size of ACPL by looking at SKGTSZ from your SIP Stage II deck. (Size is approximately 20 KB.) |
FACE Table (FCTB) | After running SIP, verify the size of the FCTB by looking at SKGTSZ from your SIP Stage II deck. |
In-Core Dump Formatter (ICDF) | After running SIP, verify the size of the ICDF by looking at SKGTSZ from your SIP Stage II deck. (Size is approximately 85 KB.) |
Record ID Attribute Table (RIAT) | The size of the RIAT depends on the number of RIATA macros coded. Each RIAT entry requires approximately 20 bytes of storage. |
Program Allocator Table (PAT) | The size of the PAT depends on the number of program, transfer vectors, and spares allocated. Each PAT entry requires approximately 88 bytes of storage. |
The SIGT is built by SIP as a result of input from the user-coded GLSYNC macro and there is a separate table built for each MDBF subsystem if both facilities are required plus a common table for all subsystems. For non-MDBF users there is only one SIGT for the entire system.
The general file loader online segment (ACPL) resides in main storage only during the online load operation (for example, when the loader general file is IPLed). This program is not in main storage during online operation.
The FACE table (FCTB) contains a list of base file addresses which the FACE program uses to compute a file address. There is a separate FACE table for each subsystem in a MDBF system. See Offline FACE Table Generator for more information.
The record ID attribute table (RIAT) contains information on every file type within the data base. This information includes pool record attributes (such as size, duration, and duplication), VFA candidacy for fixed- and pool-file records, logging, exception recording, user exit, and record caching attributes. There is a separate RIAT table for each subsystem in an MDBF system.
The in-core dump formatter (ICDF) is optionally used to print system error dumps directly to the online printer but only when the system is in test mode.
The size of the SIGT varies based upon the SIP input. Each subsystem's table is comprised of 2 subsections, section 0 and 1.
Section 0 contains an 8-byte header and an 8-byte item for each subsystem user (SSU) in an SS. Therefore, the size per subsystem is 8 times the number of SSUs plus 8.
Section 1 has an 80-byte item per synchronizable global for each SSU. For each SS a maximum of 256 global fields and 256 global records may be defined as synchronizable (see Application Global Area). For example, if there are 2 subsystems, the first with 2 SSUs with 8 synchronizable fields and 2 synchronizable records, the second SS with 6 SSUs with 30 synchronizable fields and 6 synchronizable records, you must allocate space for 2 SIGT section 1 tables as follows:
The total size of the application program area can be estimated by adding the number of core resident programs times 4096 to the sizes of ICDF, if selected, ACPL, FCTB, and SIGT if required.