IBM жүйесіндегі нақты уақыттық операциялық жүйе (TPF)

Кіріспе

IBM нақты уақыт операциялық жүйесі

Transaction Processing Facility (TPF) – IBM System/360 отбасынан тараған, zSeries және System z9 жүйелерін қоса алғанда, эВМ-дер үшін IBM нақты уақыт операциялық жүйесі. TPF жоғары жылдамдықпен, үлкен көлемде және жоғары өнімділікпен транзакцияларды өңдейді, географиялық тұрғыдан шашыраңқы үлкен желілер арқылы негізінен қарапайым транзакциялардың үлкен, үздіксіз ағынын қамтамасыз етеді. CICS және IMS сияқты басқа да өнеркәсіптік деңгейдегі транзакциялық өңдеу жүйелері болғанымен, TPF-тің ерекшелігі – өте үлкен көлем, көптеген бір мезгілде пайдаланушылар және өте жылдам жауап беру уақыты. Мысалы, ол мерекелік сауда маусымында VISA кредиттік карталары арқылы жасалатын транзакцияларды өңдейді. TPF-тің тығыз байланысты туысы – транзакциялық монитор ALCS, TPF қызметтерін MVS операциялық жүйесіне, қазір z/OS-ке интеграциялау үшін IBM-мен әзірленді.

Тарих

TPF 1960 жылдардың ортасында IBM компаниясы Солтүстік Америка және Еуропаның ірі әуе компанияларымен бірлесіп жасаған тегін бағдарламалық пакет – Airline Control Program (ACP) бағдарламасынан дамыды. 1979 жылы IBM, ACP-ні алмастыру мақсатында және ақылы бағдарламалық өнім ретінде TPF-ті ұсынды. Жаңа атау оның кеңейтілген мүмкіндіктерін және әуе көлігімен байланысы жоқ ұйымдарға да қатысты екенін көрсетеді. TPF дәстүрлі түрде өнімділіктің жоғары деңгейін қамтамасыз ету үшін IBM System/370 жиналым тілінде жұмыс істеді, сондықтан көптеген TPF жиналым тілінде жазылған қолданбалар әлі де қолданыста. Дегенмен, TPF-тің соңғы нұсқалары C тілін пайдалануға басымдық береді. SabreTalk деп аталатын тағы бір бағдарламалау тілі TPF-те пайда болды, бірақ көп ұзаққа соқпады. IBM 2005 жылдың қыркүйегінде TPF-тің қазіргі нұсқасы – z/TPF V1.1 шығарылғанын хабарлады. Ең маңыздысы, z/TPF 64 биттік адрестеуді енгізеді және 64 биттік GNU әзірлеу құралдарын міндетті түрде пайдалануды талап етеді. GCC компиляторы және DIGNUS Systems/C++ және Systems/C z/TPF үшін қолдау көрсетілетін жалғыз компиляторлар болып табылады. Dignus компиляторлары TPF 4.1 нұсқасынан z/TPF нұсқасына көшу кезінде бастапқы кодты аз өзгертуге мүмкіндік береді.

Пайдаланушылар

Қазіргі қолданушыларға Sabre (брондау), VISA Inc. (авторизация), American Airlines, American Express (авторизация), DXC Technology SHARES (брондау), Amtrak, Marriott International, Travelport (Galileo, Apollo, Worldspan), Citibank, Trenitalia (брондау), Delta Air Lines (брондау және операциялар) және Japan Airlines кіреді.

Қатты біріктірілген

IBM-нің 3083-і TPF-ті «жоғары жылдамдықты бір процессорда» іске қосуға бағытталған болса да, TPF мультипроцессорда, яғни бірден көп CPU бар жүйелерде іске қосылуы мүмкін. LPAR ішінде CPU-лар нұсқау ағындары немесе жай ғана I ағындары деп аталады. Егер LPAR бірнеше I ағынымен жұмыс істесе, TPF тығыз байланысты деп есептеледі. TPF SMP тұжырымдамаларын қолдайды; жад адрестері арасында NUMA негізіндегі ешқандай айырмашылық жоқ. CPU дайын тізімінің тереңдігі әрбір келіп түскен транзакция қабылданғанда өлшенеді және ең төменгі талапқа ие I ағынына кезекке қойылады, осылайша қол жетімді процессорлар арасында үздіксіз жүктеме теңгерімі сақталады. Егер бос байланысты конфигурациялар көп процессорлы CPC-лермен (Орталық өңдеу кешені, яғни бір жүйелік шкафқа орналасқан физикалық машина) толтырылса, SMP CPC ішінде осы жерде сипатталғандай жүзеге асырылады, ал CPC ресурстарын бөлісу төменде сипатталғандай бос байланысты жағдайда жүзеге асырылады. TPF архитектурасында барлық жад (I ағындары арасында 4КБ көлеміндегі префикс аймағынан басқа) ортақ пайдаланылады. Егер жадта сақталған деректер I ағындары бойынша бөлінуі керек немесе ұсынылса, бағдарламашы әдетте сақтау аймағын I ағындарының санына тең кіші бөлімдерге бөледі, содан кейін бөлінген аймақтың бастапқы мекенжайын алып, оған I ағынының реттік нөмірін кіші бөлімнің мөлшеріне көбейту арқылы қажетті I ағынымен байланысты аймаққа кіреді.

Қалқымалы

TPF ортақ деректер базасына қосылатын және жұмыс істейтін бірнеше мейнфреймдерді (өздері қандай да бір өлшемді болсын – бір I ағынынан бірнеше I ағынына дейін) қолдауға қабілетті. Қазіргі уақытта 32 IBM мейнфреймдері TPF деректер базасын бөлісе алады; егер мұндай жүйе жұмыс істесе, ол 32 жолмен еркін байланыстырылған деп аталатын болады. Ең қарапайым еркін байланыстырылған жүйе – бір DASD (тікелей қолжетімді сақтау құрылғысы) бөлісетін екі IBM мейнфрейм. Бұл жағдайда басқару бағдарламасы бірдей түрде жадқа жүктеледі және DASD-дегі әрбір бағдарлама немесе жазбаға екі мейнфреймнің бірі қол жеткізе алады. Еркін байланыстырылған жүйедегі дерек жазбаларына қол жеткізуді реттеу үшін жазбаны құлыптау әдісі қолданылуы керек. Бұл дегеніміз, бір мейнфрейм процессоры жазбаны құлыптағанда, механизм басқа барлық процессорлардың сол жазбаны құлыптауына жол бермеуі керек және сұраныс жіберген процессорларға күтіп тұрғанын хабарлауы керек. Кез келген тығыз байланыстырылған жүйеде бұл I ағындары арқылы Record Hold Table пайдаланып басқару оңай. Алайда, құлыптау TPF процессорынан тыс, DASD басқару блогында алынса, сыртқы процестерді пайдалану қажет. Тарихи тұрғыдан алғанда, жазбаны құлыптау DASD басқару блогында LLF (Шектелген құлыптау құрылғысы) және кейіннен ELLF (кеңейтілген) деп аталатын RPQ арқылы жүзеге асырылды. LLF және ELLF екеуі де Multipathing Lock Facility (MPLF) – көп жолды құлыптау жүйесімен ауыстырылды. Кластерлік (еркін байланыстырылған) z/TPF-ті іске қосу үшін барлық дискілік басқару блогында MPLF немесе жұптастыру құрылғысы деп аталатын баламалы құлыптау құрылғысы болуы керек.

Процессормен ортақ жазбалар

Процессормен ортақ пайдаланылатын жазбалар – міндетті түрде жазбаны құлыптау арқылы басқарылуы тиіс жазбалар. TPF жүйесінде жазбаларға қол жеткізу көбінесе жазба түрі және реттік нөмірі арқылы жасалады. Мысалы, TPF жүйесінде "FRED" жазба түрінде 100 жазба немесе реттік нөмір болған жағдайда, процессормен ортақ пайдалану схемасында "FRED" жазба түрінің "5" реттік нөмірі DASD-дегі дәл сол файл адресіне сәйкес келеді – бұл жазбаны құлыптау механизмін қолдану қажеттігін білдіреді. TPF жүйесіндегі процессормен ортақ барлық жазбалар бірдей файл адресі арқылы қол жетімді болады, ол бірдей орынға сәйкес келеді.

Процессордың бірегей жазбалары

Процессордың бірегей жазбасы – бұл, бос байланысты кешенде болуы күтілетін әр процессор үшін 'FRED' жазба түрі және, мүмкін, 100 реттік нөмірлер жиынтығымен сипатталатын жазба. Дегенмен, егер кез келген 2 немесе одан көп процессордағы қолданушы 'FRED' түріндегі жазбаның файлдық адресін, '5' реттік нөміріне сәйкес келетін адресті тексерсе, олар әртүрлі физикалық адрес қолданылғанын көреді.

TPF дегеніміз не

TPF жалпы мақсаттағы операциялық жүйе емес. TPF-тің арнайы рөлі – транзакциялық кіріс хабарламаларын өңдеу, содан кейін өте жоғары көлемде, 1:1 пропорциясында, қысқа ең көп уақыт шегінде шығыс хабарламаларын қайтару. TPF графикалық пайдаланушы интерфейсінің функционалдығына ие емес және TPF ешқашан тікелей графикалық дисплей мүмкіндіктерін ұсынбаған: оны хостқа енгізу қажетсіз және жүйе ресурстарын зиянды түрде бұру болар еді. TPF пайдаланушы интерфейсі – жоғары қарай прокруллданатын қарапайым мәтіндік дисплей терминалдары бар командалық жол, және TPF Prime CRAS-та (Компьютерлік бөлме агенті жиынтығы – оны «оператор консолі» деп санаған дұрыс) тышқанмен басқарылатын курсорлар, терезелер немесе белгішелер жоқ. Мәтіндік хабарламалар адам-пайдаланушылармен байланыс құралы ретінде көзделеді. Барлық жұмыс UNIX сияқты, бірақ X интерфейсіз, командалық жол арқылы орындалады. Prime CRAS-қа қосылатын және TPF операторына графикалық интерфейс функцияларын ұсынатын бірнеше өнім бар, мысалы TPF Operations Server. Егер қажет болса, соңғы пайдаланушыларға арналған графикалық интерфейстерді сыртқы жүйелер қамтамасыз етуі керек. Мұндай жүйелер мәтіндік мазмұнды талдайды (қараңыз: Экранды түсіру) және хабарламаны контекстіне байланысты қажетті графикалық формаға түрлендіреді. Арнайы мақсаттағы операциялық жүйе болғандықтан, TPF компиляторды/ассемблерді, мәтін редакторын қамтымайды және жалпы мақсаттағы операциялық жүйеде күтілетін жұмыс үстелі тұжырымын іске асырмайды. TPF қолданбасының бастапқы коды әдетте сыртқы жүйелерде сақталады және сол сияқты «оффлайн» режимде құрастырылады. z/TPF 1.1 нұсқасынан бастап Linux құрастыру үшін қолдау көрсетілетін платформа болып табылады; z/TPF операциясы үшін арналған орындалатын бағдарламалар s390x ibm linux үшін ELF форматын сақтауы тиіс. TPF-ті пайдалану үшін оның Командалық нұсқаулығын білу қажет, себебі пайдаланушыларға таныс онлайн командалық «директория» немесе «көмек»/ақпарат құралы қолдау көрсетілмейді. IBM жүйелік әкімшілік үшін жасаған және жеткізген командалар «функционалдық хабарламалар» деп аталады, себебі олардың барлығы «Z» әрпімен басталады. Басқа әріптер клиенттер өздерінің командаларын жазуы үшін резервте сақталады. TPF-те қателерді жою (debugging) жүйелік клиент-сервер режимінде жүзеге асырылады, бұл жүйенің бассыз, көппроцессорлық табиғатына байланысты қажет: жалғыз тапсырманы ұстау үшін бүкіл жүйені тоқтату өте тиімсіз болар еді. Үшінші тарап өнімдері қателерді жою пакеттерін әзірледі, олар TPF хостында қажетті «үзіліс/жалғастыру» операцияларына әртүрлі тәсілдер қолданды, дебьюгерлік клиентті іске асыратын адам-әзірлеуші мен серверлік жағынан дебьюгерлік контроллер арасындағы байланыста қолданылатын бірегей байланыс протоколдарын іске асырды, сондай-ақ клиенттік жағынан дебьюгерлік бағдарлама операцияларының нысаны мен функциясын анықтады. Үшінші тараптан шыққан қателерді жою пакеттерінің екі мысалы – Bedford Associates компаниясының Step by Step Trace және TPF Software, Inc компаниясының CMSTPF, TPF/GI және zTPFGI. Бұл пакеттердің ешқайсысы бір-бірімен де, IBM-нің өзі ұсынған нұсқасымен де толық үйлесімді емес. IBM-нің қателерді жою клиенттік ұсынысы IBM TPF Toolkit деп аталатын IDE-де жинақталған.

TPF is not a general purpose operating system. TPF's specialized role is to process transaction input messages, then return output messages on a 1:1 basis at extremely high volume with short maximum elapsed time limits. TPF has no built in graphical user interface functionality, and TPF has never offered direct graphical display facilities: to implement it on the host would be considered an unnecessary and potentially harmful diversion of real time system resources. TPF's user interface is command line driven with simple text display terminals that scroll upward, and there are no mouse driven cursors, windows, or icons on a TPF Prime CRAS (Computer room agent set — which is best thought of as the "operator's console"). Character messages are intended to be the mode of communications with human users. All work is accomplished via the use of the command line, similar to UNIX without X. There are several products available which connect to Prime CRAS and provide graphical interface functions to the TPF operator, such as TPF Operations Server. Graphical interfaces for end users, if desired, must be provided by external systems. Such systems perform analysis on character content (see Screen scrape) and convert the message to/from the desired graphical form, depending on its context. Being a specialized purpose operating system, TPF does not host a compiler/assembler, text editor, nor implement the concept of a desktop as one might expect to find in a general purpose operating system. TPF application source code is commonly stored in external systems, and likewise built "offline". Starting with z/TPF 1.1, Linux is the supported build platform; executable programs intended for z/TPF operation must observe the ELF format for s390x ibm linux. Using TPF requires a knowledge of its Command Guide since there is no support for an online command "directory" or "man"/help facility to which users might be accustomed. Commands created and shipped by IBM for the system administration of TPF are called "functional messages"—commonly referred to as "Z messages", as they are all prefixed with the letter "Z". Other letters are reserved so that customers may write their own commands. TPF implements debugging in a distributed client server mode, which is necessary because of the system's headless, multi processing nature: pausing the entire system in order to trap a single task would be highly counterproductive. Debugger packages have been developed by third party vendors who took very different approaches to the "break/continue" operations required at the TPF host, implementing unique communications protocols used in traffic between the human developer running the debugger client and the server side debug controller, as well as the form and function of debugger program operations at the client side. Two examples of third party debugger packages are Step by Step Trace from Bedford Associates and CMSTPF, TPF/GI, and zTPFGI, all from TPF Software, Inc. Neither package is wholly compatible with the other, nor with IBM's own offering. IBM's debugging client offering is packaged in an IDE called IBM TPF Toolkit.

ТПФ деген не ?

TPF қолдау көрсетілетін желіден келетін хабарларды басқа орынға ауыстыруға, белгілі бір бағдарламалар жиынтығына бағыттауға немесе дерекқор жазбаларына өте тиімді қол жеткізуді қамтамасыз ету үшін жоғары деңгейде оңтайландырылған.

Деректер жазбалары

Тарихи тұрғыдан алғанда, TPF жүйесіндегі барлық деректер 381, 1055 және 4К байт өлшемдеріне сәйкес келетін белгілі жазбаларға (және жад блоктарына) сыйып келуі керек еді. Бұл, ішінара, DASD құрылғыларындағы блоктардың физикалық жазба өлшемдерімен байланысты болды. Файл операциялары кезінде үлкен деректерді кішірек бөліктерге бөлуден және оларды оқу операциялары кезінде қайта құрастырудан опералық жүйенің кез келген бөлігін босату арқылы көптеген ресурстар үнемделді. IBM жабдықтары арналар мен арна бағдарламаларын пайдаланып I/O операцияларын жасайтындықтан, TPF жылдамдық үшін өте кішкентай және тиімді арна бағдарламаларын жасап, I/O операцияларын орындады. Бастапқы кезеңдерде жад немесе дискі болсын, сақтау құралдарының көлеміне ерекше мән берілді, сондықтан TPF қолданбалары өте аз ресурстарды пайдалана отырып, өте күшті мүмкіндіктерге ие болды. Бүгінде бұл шектеулердің көп бөлігі жойылды. Шындығында, ескі жүйелермен үйлесімділікті сақтау үшін ғана 4К DASD жазбаларынан кішкентай өлшемдердегі жазбалар қолданылады. DASD технологиясындағы жетістіктердің арқасында 4К жазбаны оқу/жазу 1055 байттық жазбаны оқу/жазумен бірдей тиімді. Осы жетістіктер әр құрылғының сыйымдылығын арттырды, сондықтан деректерді ең кішкентай өлшемге сығымдау қажеттігі жойылды.

Бағдарламалар мен резиденттік

TPF-де бағдарламалық сегменттер әртүрлі кезеңдерде 381, 1055 және 4К байт көлеміндегі жазбалар ретінде бөлінген. Әрбір сегмент бір жазбадан тұрады; әдеттегі күрделі қосымшада ондаған, тіпті жүздеген сегменттер қажет болуы мүмкін. TPF тарихының алғашқы қырық жылында бұл сегменттер сілтемеленбеген. Оның орнына, жылжымалы объектілік код (ассемблерден тікелей шығыс) жадыға орналастырылды, ішкі (өздік сілтемелі) жылжымалы символдары шешілді, содан кейін бүкіл бейне жүйеге кейінірек жүктеу үшін файлға жазылды. Бұл бір-бірімен байланысты сегменттердің тікелей бір-біріне сілтеме жасау мүмкін болмайтын, ал олардың арасындағы басқару ENTER/BACK жүйелік қызметі арқылы жүзеге асырылатын қиын бағдарламалау ортасын жасады. ACP/TPF-тің алғашқы күндерінде (шамамен 1965 жыл) жад кеңістігі өте шектеулі болды, бұл файлда тұратын және негізгі жадта тұратын бағдарламалардың арасындағы айырмашылыққа әкелді. Тек ең көп қолданылатын қосымша бағдарламалары ғана жадқа жазылып, ешқашан алынып тасталмайтын (негізгі жадта тұру); қалғандары файлда сақталады және қажет болғанда оқылады, олардың қосалқы жад буферлері орындалғаннан кейін босатылады. TPF-ке 3.0 нұсқасында C тілін енгізу сегменттік конвенцияларға сәйкес жүзеге асырылды, оның ішінде сілтемеленудің болмауы. Бұл схема C бағдарламаларының ең қарапайымдарынан басқа кез келген нәрсеге жарамсыз екенін тез көрсетті. TPF 4.1-де TPF-ке толыққанды сілтемеленген жүктеу модульдері енгізілді. Бұлар z/OS C/C++ компиляторымен TPF-ке тән бас файлдарын пайдалана отырып құрастырылды және IEWL арқылы сілтемеленді, нәтижесінде z/OS-қа сәйкес жүктеу модулі пайда болды, оны дәстүрлі TPF сегменті деп санауға болмайды. TPF жүктеуіші z/OS жүктеу модулінің бірегей файл форматын оқып, содан кейін файлда тұратын жүктеу модульдерінің бөлімдерін жадыға орналастырды; ал ассемблерлік бағдарламалар TPF сегменттік моделімен шектелді, бұл ассемблерлік және жоғары деңгейдегі тілдерде (HLL) жазылған бағдарламалардың арасында айқын айырмашылықты тудырды. z/TPF 1.1 нұсқасында барлық бастапқы тіл түрлері тұжырымдық жағынан біріктірілді және ELF спецификациясына сәйкес толыққанды сілтемеленді. Сегмент түсінігі ескірді, яғни кез келген бағдарлама кез келген бастапқы тілде жазылған, соның ішінде Assembler, кез келген көлемде болуы мүмкін. Сонымен қатар, сыртқы сілтемелерге қол жеткізілді, ал бір кезде сегмент болған жеке бастапқы код бағдарламалары енді ортақ нысанға тікелей сілтемелене алады. Маңыздысы, маңызды мұрагерлік қосымшалар қарапайым қайта жинақтау арқылы тиімділікті арттырудан пайда көре алады – бір ортақ нысан модулінің мүшелері арасындағы шақырулар жүйенің ENTER/BACK қызметін шақырумен салыстырғанда орындалу кезінде әлдеқайда қысқа жолға ие. Бір ортақ нысанның мүшелері енді z/TPF 1.1-де енгізілген көшіру арқылы жазу функционалдығының арқасында жазуға болатын деректер аймақтарын тікелей бөлісе алады, бұл TPF-тің қайта кіру талаптарын күшейтеді. Файл және жадта тұру түсініктері де ескірді, себебі z/TPF дизайны барлық бағдарламаларды әрқашан жадта сақтауға бағытталды. z/TPF жоғары деңгейдегі тіл бағдарламалары үшін шақыру стегін сақтауға тиіс болғандықтан, бұл HLL бағдарламаларына стекке негізделген жадты бөлуден пайда алуға мүмкіндік берді, сондықтан шақыру стегін ассемблерлік бағдарламаларға опциялық түрде кеңейту пайдалы деп танылды, бұл жад қысымын азайтуға және рекурсивті бағдарламалауды жеңілдетуге көмектеседі. Барлық z/TPF орындалатын бағдарламалары енді ELF ортақ нысандары ретінде жинақталған.

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 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 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 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 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 recursive programming. All z/TPF executable programs are now packaged as ELF shared objects.

Жад пайдалануы

Тарихи тұрғыдан алсақ, бұрынғы негізгі блоктар сияқты, жад блоктарының көлемі де 381, 1055 және 4 К байтты құрады. Барлық жад блоктары осы өлшемде болғандықтан, басқа жүйелердегі жадты алуға байланысты көптеген қиындықтар жойылды. Бағдарламашыға қажетті өлшемдегі блокты анықтап, оны сұрау жеткілікті болды. TPF қолданыстағы блоктардың тізімін ұстап, қолжетімді тізімдегі алғашқы блокты беретін болды. Физикалық жад әр көлемге бөлінген бөлімдерге бөлінді, сондықтан 1055 байттық блок әрқашан сол бөлімнен алынып, қайтарылатын. Қосымша шығын тек оның мекенжайын тиісті физикалық блок кестесінің тізіміне қосудан тұрды. Жадыны жинақтау немесе деректерді шоғырландыру қажет болмады. Қолданбалардың күрделенуімен жадқа деген талаптар артты және C тілі қолжетімді болғаннан кейін, белгісіз немесе үлкен көлемдегі жад блоктары қажет болды. Бұл үйінділік сақтау және жадты басқару процедураларын пайдалануға себеп болды. Қиындықтарды жеңілдету үшін TPF жады фреймдерге бөлінді – 4 КБ (z/TPF үшін 1 МБ). Егер қосымшаға белгілі бір байт саны қажет болса, сол қажеттілікті қанағаттандыру үшін қажетті үздіксіз фреймдер саны беріледі.