Войти
 | |
| Разработчик | IBM |
|---|---|
| Написано на | z / Architecture Assembly язык, C, C ++ |
| Семейство ОС | язык ассемблера z / Architecture (z / TPF), язык ассемблера ESA / 390 (TPF4) |
| Рабочее состояние | Текущее |
| Исходная модель | Закрытый исходный код (Исходный код доступен лицензированным пользователям с ограничениями) |
| Первоначальный выпуск | 1979; 41 год назад (1979) |
| Последний выпуск | 1.1.0.14 / ноябрь 2016 г.; 4 года назад (2016-11) |
| Платформы | IBM System z (z / TPF), ESA / 390 (TPF4) |
| Тип ядра | В реальном времени |
| По умолчанию пользовательский интерфейс | 3215 3270 |
| Лицензия | Собственная ежемесячная плата за лицензию (MLC) |
| Официальный веб-сайт | Страница продукта z / TPF |
Средство обработки транзакций (TPF) - это IBM операционная система реального времени для мэйнфреймов компьютеров, произошедших от IBM System / 360 семейство, включающее zSeries и System z9.
TPF обеспечивает быструю, крупномасштабную и высокопроизводительную обработку транзакций, обрабатывая большие, непрерывные нагрузки по существу простых транзакций в больших, географически разнесенных сетях.
Хотя существуют и другие промышленные системы обработки транзакций, в частности собственные CICS и IMS IBM, TPF специализируется на экстремальных объемах и больших количествах. одновременных пользователей и очень быстрое время отклика. Например, он обрабатывает транзакции кредитной карты VISA во время пикового сезона праздничных покупок.
Приложение TPF для бронирования пассажиров PARS или его международная версия IPARS используется многими авиакомпаниями.
Одним из основных дополнительных компонентов 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 сохраняются. Однако более поздние версии TPF поощряют использование C. Другой язык программирования, названный 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 (бронирование - ранее EDS, HPES ), Holiday Inn (центральное бронирование), Amtrak, Marriott International, Travelport (Galileo, Apollo, Worldspan, Axess Japan GDS), Citibank, Air Canada, Trenitalia (бронирование), Delta Air Lines (бронирование и выполнение операций) и Japan Airlines.
TPF может работы на мультипроцессоре, то есть в системах с более чем одним процессором. В LPAR процессоры называются потоками инструкций или просто I-потоками . Когда TPF работает в LPAR с более чем одним I-потоком, считается, что он выполняет тесно связанный . 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 были заменены механизмом блокировки многолучевого распространения (MPLF). Для работы кластеризованного (слабосвязанного) z / TPF требуется либо MPLF во всех блоках управления дисками, либо альтернативное блокирующее устройство, называемое Coupling Facility.
Записи, которыми необходимо управлять с помощью блокировки записи процессами являются те, которые используются совместно с процессором. В TPF большинство обращений к записям осуществляется с использованием типа записи и порядкового номера . Итак, если вы определили тип записи в системе TPF «FRED» и дали ему 100 записей или порядковых номеров, то в общей схеме процессора тип записи «FRED» с порядковым номером «5» разрешился бы в точно такой же адрес файла на DASD. - очевидно, что требует использования механизма блокировки записи.
Все общие записи процессора в системе TPF будут доступны через один и тот же адрес файла, который будет разрешен в одно и то же место.
Уникальная запись процессора - это запись, которая определена так, что каждый процессор, который, как ожидается, будет находиться в слабосвязанном комплексе, имеет тип записи «FRED» и, возможно, 100 порядковых номеров. Однако, если пользователь на любых 2 или более процессорах проверяет адрес файла, в который разрешается тип записи «FRED», порядковый номер «5», он заметит, что используется другой физический адрес.
TPF является не операционной системой общего назначения (GPOS ). Специализированная роль TPF состоит в том, чтобы обрабатывать входные сообщения транзакции, а затем возвращать выходные сообщения в соотношении 1: 1 при чрезвычайно большом объеме с короткими максимальными затраченными сроками.
TPF не имеет встроенных функций графического пользовательского интерфейса, а TPF никогда не предлагал средства прямого графического отображения: реализация его на хосте будет считаться ненужным и потенциально опасным отвлечением системных ресурсов реального времени. Пользовательский интерфейс TPF управляется командной строкой с простыми терминалами для отображения текста, которые прокручиваются вверх, и на TPF Prime CRAS (набор агентов компьютерной комнаты - что лучше всего) отсутствуют курсоры, окна или значки, управляемые мышью. как «пульт оператора»). Символьные сообщения предназначены для общения с пользователями-людьми; вся работа выполняется с использованием командной строки, аналогично UNIX без X. Доступно несколько продуктов, которые подключаются к Prime CRAS и предоставляют функции графического интерфейса для оператора TPF, например, TPF Operations Server. Графические интерфейсы для конечных пользователей при желании должны предоставляться внешними системами. Такие системы выполняют анализ содержания символов (см. Очистка экрана ) и преобразуют сообщение в / из желаемой графической формы в зависимости от его контекста.
Будучи операционной системой специального назначения, TPF не содержит компилятора / ассемблера, текстового редактора и не реализует концепцию рабочего стола, как можно было бы ожидать от GPOS. Исходный код приложения TPF обычно хранится во внешних системах и также создается в автономном режиме. Начиная с z / TPF 1.1, Linux является поддерживаемой платформой сборки; исполняемые программы, предназначенные для работы z / TPF, должны соответствовать формату ELF для s390x-ibm-linux.
Использование TPF требует знания его Руководства по командам, поскольку нет поддержки интерактивных команд «directory» или «man» / help, к которым пользователи могли бы привыкнуть. Команды, созданные и поставляемые 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. / НАЗАД сервис. Члены одного и того же общего объекта теперь могут совместно использовать записываемые области данных напрямую благодаря функции копирования при записи, также представленной в z / TPF 1.1; что по совпадению усиливает требования TPF к повторной входимости.
Концепции резидентности файла и ядра также устарели из-за проектной точки z / TPF, которая стремилась постоянно размещать все программы в памяти.
Поскольку z / TPF должен был поддерживать стек вызовов для программ на языке высокого уровня, что дало HLL-программам возможность использовать преимущества распределения памяти на основе стека, Было сочтено полезным расширить стек вызовов до программ на языке ассемблера на необязательной основе, что может уменьшить нагрузку на память и упростить рекурсивное программирование.
Все исполняемые программы z / TPF теперь упакованы как общие объекты ELF.
Исторически, как и предыдущие, блоки ядра - память - также имели размер 381, 1055 и 4 Кбайт. Поскольку ВСЕ блоки памяти должны были иметь этот размер, большая часть накладных расходов на получение памяти, обнаруженная в других системах, была отброшена. Программисту просто нужно было решить, какой размер блока подойдет, и запросить его. TPF будет поддерживать список используемых блоков и просто передавать первый блок в доступном списке.
Физическая память была разделена на разделы, зарезервированные для каждого размера, поэтому блок размером 1055 байт всегда приходил из раздела и возвращался туда, единственные накладные расходы, которые требовались, заключались в добавлении его адреса в соответствующий список таблицы физических блоков. Никакого уплотнения или сбора данных не требовалось.
По мере того, как приложения становились все более продвинутыми, требования к памяти увеличивались, и как только C стал доступен, потребовались блоки памяти неопределенного или большого размера. Это привело к использованию хранилища в куче и некоторых процедур управления памятью. Чтобы уменьшить накладные расходы, память TPF была разбита на фреймы размером 4 КБ (1 МБ с z / TPF). Если приложению требуется определенное количество байтов, предоставляется количество непрерывных кадров, необходимое для заполнения этой потребности.
