Editing Transaction Processing Facility (section)

====Programs and residency====
TPF also had its program '''segments''' allocated as 381, 1055 and 4K byte-sized '''records''' at different points in its history. Each segment consisted of a single record; with a typically comprehensive application requiring perhaps tens or even hundreds of segments. For the first forty years of TPF's history, these segments were never [[Linker (computing)|link-edited]]. Instead, the relocatable object code (direct output from the assembler) was laid out in memory, had its ''internally'' (self-referential) relocatable symbols resolved, then the entire image was written to file for later loading into the system. This created a challenging programming environment in which ''segments related to one another could not directly address each other'', with control transfer between them implemented as the '''ENTER/BACK''' ''system service''.

In ACP/TPF's earliest days (circa 1965), memory space was severely limited, which gave rise to a distinction between '''file-resident''' and '''core-resident''' programs—only the most frequently used application programs were written into memory and never removed ('''core-residency'''); the rest were stored on file and read in on demand, with their backing memory buffers released post-execution.

The introduction of [[C (programming language)|C language]] to TPF at version 3.0 was first implemented conformant to segment conventions, including the absence of linkage editing. This scheme quickly demonstrated itself to be impractical for anything other than the simplest of C programs. At TPF 4.1, truly and fully linked '''load modules''' were introduced to TPF. These were compiled with the [[z/OS]] C/C++ compiler using TPF-specific [[header files]] and linked with '''IEWL''', resulting in a z/OS-conformant load module, which in no manner could be considered a traditional TPF segment. The '''TPF loader''' was extended to read the z/OS-unique ''load module'' file format, then lay out file-resident load modules' sections into memory; meanwhile, assembly language programs remained confined to TPF's ''segment'' model, creating an obvious disparity between applications written in assembler and those written in higher level languages (HLL).

At z/TPF 1.1, all source language types were conceptually unified '''and''' fully link-edited to conform to the [[Executable and Linking Format|ELF]] specification. The ''segment'' concept became obsolete, meaning that ''any'' program written in ''any'' source language—including Assembler—may now be of '''any''' size. Furthermore, external references became possible, and separate source code programs that had once been ''segments'' could now be directly linked together into a [[shared object]]. A value point is that critical legacy applications can benefit from improved efficiency through simple ''repackaging''—calls made between members of a single shared object module now have a much shorter '''pathlength''' at run time as compared to calling the system's ''ENTER/BACK'' service. Members of the same shared object may now share writeable data regions directly thanks to [[copy-on-write]] functionality also introduced at z/TPF 1.1; which coincidentally reinforces TPF's [[Reentrancy (computing)|reentrancy]] requirements.

The concepts of file- and memory- residency were also made obsolete, due to a z/TPF design point which sought to have all programs resident in memory at all times.

Since z/TPF had to maintain a [[call stack]] for high-level language programs, which gave HLL programs the ability to benefit from [[stack-based memory allocation]], it was deemed beneficial to extend the call stack to assembly language programs on an optional basis, which can ease memory pressure and ease [[Recursion (computer science)|recursive]] programming.

All z/TPF executable programs are now packaged as ELF shared objects.