Центр обработки транзакций

с/TPF

Разработчик	ИБМ
Написано в	z/Архитектура Язык ассемблера , C , C++
Семейство ОС	Язык ассемблера z/Architecture (z/TPF), язык ассемблера ESA/390 (TPF4)
Рабочее состояние	Текущий
Исходная модель	Закрытый исходный код (Исходный код доступен лицензированным пользователям с ограничениями)
Первоначальный выпуск	1979 год ( 1979 )
Последний выпуск	1.1.0.2023
Платформы	IBM System z (z/TPF), ESA/390 (TPF4)
ядра Тип	В режиме реального времени
По умолчанию пользовательский интерфейс	3215 3270
Лицензия	Собственная ежемесячная плата за лицензию (MLC)
Официальный сайт	Страница продукта z/TPF

Средство обработки транзакций (TPF) — это IBM операционная система реального времени для мэйнфреймов , происходящая из семейства IBM System/360 , включая zSeries и System z9 .

TPF обеспечивает быструю, объемную и высокопроизводительную обработку транзакций, обрабатывая большие, непрерывные нагрузки по существу простых транзакций в больших, географически распределенных сетях.

Хотя существуют и другие промышленные системы обработки транзакций от IBM , в частности собственные CICS и IMS , особенностью TPF являются экстремальные объемы, большое количество одновременных пользователей и очень быстрое время отклика. Например, он обрабатывает по кредитным картам VISA во время пикового сезона праздничных покупок. транзакции

Приложение для бронирования пассажиров TPF PARS или его международная версия IPARS используется многими авиакомпаниями. PARS — прикладная программа ; TPF — это операционная система.

Одним из основных дополнительных компонентов TPF является высокопроизводительная специализированная база данных, называемая TPF Database Facility (TPFDF).

Близкий родственник TPF, монитор транзакций ALCS , был разработан IBM для интеграции сервисов TPF в более распространенную операционную систему для мэйнфреймов MVS , теперь z/OS .

История

TPF произошел от программы управления авиакомпаниями (ACP), бесплатного пакета, разработанного в середине 1960-х годов компанией IBM совместно с крупными авиакомпаниями Северной Америки и Европы. В 1979 году IBM представила TPF в качестве замены ACP и в качестве платного программного продукта. Новое название предполагает его больший масштаб и эволюцию в организации, не связанные с авиакомпаниями.

TPF традиционно представлял собой IBM System/370 среду ассемблера по соображениям производительности, и многие приложения ассемблера TPF сохраняются. поощряют использование C. Однако более поздние версии TPF Другой язык программирования под названием SabreTalk родился и умер на TPF.

IBM объявила о выпуске текущей версии TPF, получившей название z/TPF V1.1, в сентябре 2005 года. Самое главное, что 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 способен работать на мультипроцессоре , то есть на системах, в которых имеется более одного ЦП. В LPAR процессоры называются потоками инструкций или просто I-потоками . При работе в LPAR с более чем одним I-потоком TPF считается тесно связанным . TPF придерживается концепции SMP ; не существует концепции основанного на NUMA различия между адресами памяти.

Глубина списка готовности ЦП измеряется при получении любой входящей транзакции и помещается в очередь для I-потока с наименьшим спросом, таким образом поддерживая непрерывную балансировку нагрузки между доступными процессорами. В тех случаях, когда слабосвязанные конфигурации заполняются многопроцессорными CPC ( центральным вычислительным комплексом , т.е. физической машиной, упакованной в один системный шкаф ), SMP происходит внутри CPC, как описано здесь, тогда как совместное использование ресурсов между CPC происходит, как описано в разделе Слабо связанный , ниже.

В архитектуре TPF вся память (за исключением префиксной области размером 4 КБ ) распределяется между всеми I-потоками. В тех случаях, когда данные, находящиеся в памяти, должны или должны храниться разделенными I-потоком, программист обычно распределяет область хранения на несколько подразделов, равных количеству I-потоков, а затем получает доступ к желаемой области, связанной с I-потоком, взяв базовый адрес выделенной области и добавление к нему произведения относительного числа I-потока, умноженного на размер каждого подраздела.

Слабосвязанный

TPF способен поддерживать несколько мэйнфреймов (любого размера — будь то один I-поток или несколько I-потоков), подключающихся к общей базе данных и работающих с ней. В настоящее время 32 мэйнфрейма IBM могут совместно использовать базу данных TPF; если бы такая система действовала, ее бы называли 32-канальной слабосвязанной . Простейшая слабосвязанная система — это два мэйнфрейма IBM, совместно использующие один DASD ( устройство хранения данных с прямым доступом ). В этом случае управляющая программа будет одинаково загружена в память, и каждая программа или запись на DASD потенциально могут быть доступны любому мэйнфрейму.

Чтобы сериализовать доступ к записям данных в слабосвязанной системе, практику, известную как блокировка записей необходимо использовать . Это означает, что когда один процессор мэйнфрейма удерживает запись , механизм должен препятствовать получению такого же удержания всеми другими процессорами и сообщать запрашивающим процессорам, что они ожидают. В любой тесно связанной системе этим легко управлять между I-потоками с помощью таблицы удержания записей . Однако, когда блокировка получена вне процессора TPF в блоке управления DASD, необходимо использовать внешний процесс. Исторически блокировка записи осуществлялась в блоке управления DASD через RPQ, известный как LLF (Limited Locking Facility), а позже ELLF (расширенный). LLF и ELLF были заменены Multipathing Lock Facility (MPLF). Для запуска кластерного (слабосвязанного) z/TPF требуется либо MPLF во всех блоках управления дисками, либо альтернативное устройство блокировки, называемое Coupling Facility.

Общие записи процессора

Записи, которые обязательно должны управляться с помощью процесса блокировки записей, — это те, которые являются общими для процессора. В TPF большинство обращений к записям осуществляется с использованием типа записи и порядкового номера . Учитывая тип записи в системе TPF «FRED» со 100 записями или порядковыми номерами, в схеме совместного использования процессора тип записи «FRED» с порядковым номером «5» будет разрешаться в точно такой же адрес файла на DASD, что требует использования записи запорный механизм.

Доступ ко всем общим записям процессора в системе TPF будет осуществляться через один и тот же адрес файла, который будет разрешаться в одно и то же местоположение.

Уникальные записи процессора

Уникальная запись процессора — это запись, которая определена таким образом, что каждый процессор, который, как ожидается, будет входить в слабосвязанный комплекс, имеет тип записи «FRED» и, возможно, 100 порядковых номеров. Однако если пользователь на любых двух или более процессорах проверит адрес файла, которому соответствует тип записи «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, должны соответствовать формату ELF для s390x-ibm-linux.

Использование TPF требует знания руководства по его командам. поскольку нет поддержки онлайн-команд «каталог» или «man»/справки, к которым пользователи, возможно, привыкли. Команды, созданные и поставляемые IBM для системного администрирования TPF, называются «функциональными сообщениями» — обычно их называют « Z-сообщениями », поскольку все они имеют префикс буквы «Z». Остальные буквы зарезервированы, чтобы клиенты могли писать свои собственные команды.

TPF реализует отладку в распределенном режиме клиент-сервер, что необходимо из-за безголовой и многопроцессорной природы системы: приостановка всей системы для перехвата одной задачи была бы крайне контрпродуктивной. Пакеты отладчика были разработаны сторонними поставщиками, которые использовали совершенно разные подходы к операциям «прерывания/продолжения», требуемым на узле TPF, реализуя уникальные протоколы связи, используемые в трафике между разработчиком-человеком, запускающим клиент отладчика, и контроллером отладки на стороне сервера. , а также форму и функции операций программы-отладчика на стороне клиента. Два примера сторонних пакетов отладчика: Step by Step Trace от Bedford Associates. и CMSTPF , TPF/GI и zTPFGI — все от TPF Software, Inc. Ни один из пакетов не является полностью совместимым ни с другим, ни с собственным предложением IBM. Клиентское предложение IBM для отладки упаковано в IDE под названием IBM TPF Toolkit .

Что такое ТПФ

TPF высоко оптимизирован, чтобы разрешить переключение сообщений из поддерживаемой сети в другое место, маршрутизацию к приложению (определенному набору программ) или обеспечение чрезвычайно эффективного доступа к записям базы данных.

Записи данных

Исторически сложилось так, что все данные в системе TPF должны были помещаться в фиксированные записи (и блоки памяти) размером 381, 1055 и 4 КБ. Частично это было связано с физическими размерами записей блоков, расположенных на DASD. Значительная часть накладных расходов была сэкономлена за счет освобождения любой части операционной системы от разбиения больших объектов данных на более мелкие во время файловых операций и их повторной сборки во время операций чтения. Поскольку оборудование IBM выполняет ввод-вывод посредством использования каналов и канальных программ , TPF будет генерировать очень маленькие и эффективные канальные программы для выполнения ввода-вывода — и все это во имя скорости. Поскольку на первых порах большое внимание уделялось размеру носителя информации (будь то память или диск), приложения TPF превратились в способные выполнять очень мощные задачи, используя при этом очень мало ресурсов.

Сегодня большая часть этих ограничений снята. Фактически, только из-за устаревшей поддержки записи DASD размером менее 4 КБ все еще используются. Благодаря достижениям в технологии DASD чтение/запись записи 4K столь же эффективна, как запись размером 1055 байт. Те же достижения позволили увеличить емкость каждого устройства, так что больше не нужно придавать большого значения возможности упаковывать данные в самую маленькую модель, насколько это возможно.

Программы и резидентура

программы TPF также выделяла сегменты размером 381, 1055 и 4 КБ как записи В разные моменты своей истории . Каждый сегмент состоял из одной записи; с типично комплексным приложением, требующим, возможно, десятков или даже сотен сегментов. За первые сорок лет истории TPF эти сегменты ни разу не редактировались по ссылкам . Вместо этого перемещаемый объектный код (прямой вывод ассемблера) размещался в памяти, его внутренние (самореферентные) перемещаемые символы разрешались, затем все изображение записывалось в файл для последующей загрузки в систему. Это создало сложную среду программирования, в которой связанные друг с другом сегменты не могли напрямую обращаться друг к другу , а передача управления между ними была реализована как ENTER/BACK системная служба .

В первые дни существования ACP/TPF (около 1965 г.) объем памяти был сильно ограничен, что привело к различию между резидентными в файле и резидентными программами — только наиболее часто используемые прикладные программы записывались в память и никогда не удалялись ( core-резидентные программы) . резиденция ); остальные хранились в файле и считывались по требованию, а их резервные буферы памяти освобождались после выполнения.

Введение языка C в TPF в версии 3.0 было впервые реализовано в соответствии с соглашениями о сегментах, включая отсутствие редактирования связей. Эта схема быстро показала себя непрактичной ни для чего, кроме простейших программ на языке C. В TPF 4.1 по-настоящему и полностью связанные нагрузочные модули в TPF были введены . Они были скомпилированы с помощью компилятора z/OS C/C++ с использованием заголовочных файлов , специфичных для TPF , и связаны с IEWL , в результате чего появился загрузочный модуль, совместимый с z/OS, который никоим образом нельзя считать традиционным сегментом TPF. Загрузчик TPF был расширен для чтения уникального для z/OS формата файла загрузочного модуля , а затем размещения разделов резидентных загрузочных модулей в памяти; моделью TPF в то же время программы на ассемблере оставались ограниченными сегментной , создавая очевидное несоответствие между приложениями, написанными на ассемблере, и приложениями, написанными на языках более высокого уровня (HLL).

В z/TPF 1.1 все типы исходного языка были концептуально унифицированы и полностью отредактированы для соответствия спецификации ELF . Концепция сегмента устарела, а это означает, что любая программа, написанная на любом исходном языке, включая ассемблер, теперь может быть любого размера. Более того, стали возможны внешние ссылки, и отдельные программы с исходным кодом, которые когда-то были сегментами, теперь могли быть напрямую связаны друг с другом в общий объект . Ценность заключается в том, что критически важные устаревшие приложения могут выиграть от повышения эффективности за счет простой переупаковки — вызовы, выполняемые между членами одного общего объектного модуля, теперь имеют гораздо более короткую длину пути во время выполнения по сравнению с вызовом системной службы ENTER/BACK . Члены одного и того же общего объекта теперь могут совместно использовать доступные для записи области данных напрямую благодаря функции копирования при записи, также представленной в z/TPF 1.1; что по совпадению усиливает требования TPF к повторному входу .

Концепции местонахождения файлов и памяти также устарели из-за конструктивной точки зрения az/TPF, которая стремилась к тому, чтобы все программы всегда находились в памяти.

Поскольку z/TPF должен был поддерживать стек вызовов для программ на языке высокого уровня, что давало программам HLL возможность извлечь выгоду из распределения памяти на основе стека , было сочтено выгодным расширить стек вызовов для программ на языке ассемблера на необязательной основе. что может уменьшить нагрузку на память и упростить рекурсивное программирование.

Все исполняемые программы z/TPF теперь упаковываются как общие объекты ELF.

Использование памяти

Исторически сложилось так, что основные блоки памяти также имели размеры 381, 1055 и 4 КБ. Поскольку ВСЕ блоки памяти должны были быть такого размера, большая часть накладных расходов на получение памяти, найденной в других системах, была отброшена. Программисту просто нужно было решить, какой размер блока соответствует потребностям, и запросить его. TPF будет поддерживать список используемых блоков и просто выдавать первый блок из доступного списка.

Физическая память была разделена на разделы, зарезервированные для каждого размера, поэтому блок размером 1055 байт всегда исходил из раздела и возвращался туда. Единственными необходимыми накладными расходами было добавление его адреса в список соответствующей таблицы физических блоков. Никакого уплотнения или сбора данных не требовалось.

По мере того, как приложения становились все более продвинутыми, требования к памяти увеличивались, и как только C стал доступен, потребовались фрагменты памяти неопределенного или большого размера. Это привело к использованию динамического хранилища и некоторых процедур управления памятью. Чтобы уменьшить накладные расходы, память TPF была разбита на кадры размером 4 КБ (1 МБ с z/TPF). Если приложению требуется определенное количество байтов, предоставляется количество смежных кадров, необходимое для удовлетворения этой потребности.

Библиография

• Средство обработки транзакций: Руководство для прикладных программистов (серия Yourdon Press Computing), Р. Джейсон Мартин (в твердом переплете, апрель 1990 г.), ISBN   978-0139281105

Внешние ссылки

• z/TPF (IBM)
• Группа пользователей TPF (Группа пользователей TPF)