Эбберс М. Введение в современные мейнфреймы: основы z/OS

Подождите немного. Документ загружается.

252 Глава8

842 Unicode на мэйнфрейме

Unicode является промышленным стандартом и представляет собой 16-разрядный

набор символов, предназначенный для отображения текста и символов во всех со-

временных языках и ИТ-протоколах. Мэйнфреймы (использующие EBCDIC для одно-

байтовых символов), PC и различные RISC-системы используют одинаковую коди-

ровку Unicode.

Поддержкой Unicode занимается Unicode Consortium (http://www.unicode.org/).

В настоящее время Unicode все чаще используется в мэйнфрейм-приложениях.

Последние мэйнфреймы zSeries содержат множество уникальных аппаратных ин-

струкций для поддержки Unicode. На момент написания этой книги, Unicode на мэй-

нфреймах использовался главным образом в Java. Однако программные продукты

промежуточного уровня для z/OS также начинают использовать Unicode, и в этой

области, очевидно, следует ожидать изменений в ближайшем будущем.

843 Интерфейсы для программистов приложений для z/OS

При разработке операционных систем для удовлетворения потребностей компью-

терного рынка создаются также и приложения для выполнения на этих операцион-

ных системах. За прошедшие годы было разработано множество приложений, вы-

полняющихся в z/OS, а позднее и в UNIX. Для того чтобы обеспечить клиентов UNIX-

приложениями, z/OS содержит полную операционную систему UNIX в дополнение

к своим традиционным интерфейсам z/OS. Реализация UNIX-интерфейсов в z/OS

называется z/OS UNIX System Services (или кратко z/OS UNIX).

Самым распространенным интерфейсом для разработчиков z/OS является TSO/E

с его панельным интерфейсом, ISPF и использованием терминала 3270. Как правило,

разработчики используют эмуляторы терминала 3270, запускаемые на персональных

компьютерах, а не настоящие терминалы 3270. Эмуляторы предоставляют разработчи-

кам дополнительные функции, в частности, возможность создания нескольких сеансов

и загрузка/выгрузка кода и данных с PC. TSO/E и прочие пользовательские интерфейсы

для z/OS описываются в главе 4, «TSO/E, ISPF и UNIX: интерактивные средства z/OS».

Разработка программ в z/OS обычно предполагает использование построчного

редактора для работы с файлами исходного кода, использование пакетных задания

для компиляции и множество механизмов для тестирования кода. Для распростра-

ненных языков доступны интерактивные отладчики, основанные на функциях тер-

миналов 3270. В этой главе рассматриваются инструменты и утилиты для разработки

простой программы, выполняемой в z/OS.

Разработка с использованием только подсистемы z/OS UNIX может выполняться

через сеансы Telnet (из которых доступен редактор vi), через 3270 и TSO/E при исполь-

зовании других редакторов или через сеансы X Window System с персональных ком-

пьютеров с запущенными X-серверами. Интерфейсы X-сервера используются реже.

Существуют альтернативные методы, которые можно использовать в сочетании

с различными программными продуктами промежуточного уровня. Например, про

дукты WebSphere содержат средства разработки с графическим интерфейсом для

персональных компьютеров. Эти средства используют TCP/IP-связь с z/OS для авто-

 Проектированиеиразработкаприложенийдляz/OS 253

матического вызова элементов мэйнфрейма, необходимых на этапах разработки

и тестирования нового приложения.

В этой книге использование оперативных приложений и программных продуктов

промежуточного уровня рассматривается в части 3 «Оперативная рабочая нагрузка

в z/OS», включающей такие вопросы, как сетевые коммуникации, управление базами

данных и задачи веб-сервера.

844 Использование инструментов разработки приложений

Составление тщательно протестированного кода требует использования определен-

ных инструментов на мэйнфрейме. Основным инструментом для программиста яв-

ляется редактор ISPF.

При разработке традиционных процедурных программ на таких языках, как CO-

BOL и PL/I, программист часто подключается к мэйнфрейму и использует IDE или

редактор ISPF для изменения кода, его компиляции и запуска. Программист исполь-

зует общее хранилище (например, IBM Software Configuration Library Manager – SCLM)

для хранения кода, находящегося в процессе разработки. Хранилище позволяет про-

граммисту осуществлять извлечение или возврат кода и гарантирует, что програм-

мисты не будут нарушать работу друг друга. SCLM входит в ISPF в качестве опции

главного меню.

Для простоты исходный код можно хранить и

обрабатывать в секционированном наборе дан-

ных (partitioned data set, PDS). Однако использова-

ние PDS не позволит ни осуществлять управление

изменениями, ни предотвратить множество изменений в одной версии кода таким

же образом, как это делает SCLM. Таким образом, понятия «извлечение» или «сохране-

ние» при работе с SCLM можно заменять на «редактирование раздела PDS» или «со-

хранение раздела PDS».

После внесения изменений в исходный код программист передает на выполнение

JCL-файл для компиляции исходного кода, связывания модулей приложения и созда-

ния исполняемого кода для тестирования. Программист проводит «модульные тесты»

функциональности программы, используя инструменты мониторинга и просмотра

заданий для отслеживания запущенных программ, просмотра выходных данных

и внесения соответствующих исправлений в исходный код или другие объекты.

Иногда при возникновении отказа программа создает «дамп» памяти. Программист

может также использовать инструменты для запроса вывода дампа и для трассировки

выполняющегося кода с целью определения точек отказов.

Некоторые программисты приложений для мэйнфреймов перешли на использо-

вание инструментов интерактивной среды разработки (IDE), чтобы ускорить процесс

редактирования, компиляции и тестирования. IDE позволяют программистам прило-

жений осуществлять редактирование, тестирование и отладку исходного кода на ра-

бочей станции, а не непосредственно на мэйнфрейм-системе. Использование IDE

особенно полезно для разработки «гибридных» приложений, использующих центра-

лизованные программы или транзакционные системы, но при этом содержащих

пользовательский интерфейс, подобный веб-браузеру.

Исполняемыйкод–

файлпрограммы,готовый

квыполнениювопределенной

среде

254 Глава8

По окончании разработки и тестирования компонентов программист приложе-

ний выполняет их упаковку в соответствующем формате развертывания и передает

их группе, координирующей развертывание рабочего кода.

К средствам разработки приложений, доступным в z/OS, относятся:

• Language Environment

;

• C/C++ IBM Open Class

Library;

• DCE Application Support1;

• Encina

Toolkit Executive2;

• C/C++ с отладчиком Debug Tool;

• DFSORT;

• GDDM

-PGF;

• GDDM-REXX;

• HLASM Toolkit;

• традиционные языки, такие как COBOL, PL/I и Fortran.

845 Сеанс отладки

Программист приложений проводит «модульный тест» для тестирования функцио-

нальности определенного разрабатываемого модуля, используя средства мониторин-

га и просмотра заданий, такие как SDSF (описывается в разделе 6.8 «Общее представ-

ление о SDSF»), для трассировки выполнения заданий компиляции, просмотра вы-

ходных данных компилятора и проверки результатов модульных тестов. Если необ-

ходимо, программист вносит соответствующие исправления в исходный код и другие

объекты.

Иногда при возникновении отказа программа создает «дамп» памяти. Когда это про-

исходит, программист приложений для z/OS может использовать такие инструменты,

как IBM Debug Tool и IBM Fault Analyzer для запроса вывода дампа и для трассировки вы-

полняющегося кода с целью поиска ошибки или неправильно выполняющегося кода.

Стандартный сеанс разработки включает следующие действия:

1. Подключение к z/OS.

2. Вход в ISPF и открытие/извлечение исходного кода из хранилища SCLM (или PDS).

3. Редактирование исходного кода с внесением требуемых изменений.

4. Передача на выполнение JCL-кода для компоновки приложения и тестового

прогона.

5. Переключение в SDSF для просмотра состояния выполняющегося задания.

6. Просмотр выходных данных задания в SDSF с целью проверки на ошибки.

7. Просмотр выходного дампа для поиска ошибок («багов»

Происхождение термина «программный баг» (англ. bug –насекомое) часто связывается с лейтенантом

военно-морских сил США Грейс Муррей Хоппером (Grace Murray Hopper) и относится к 1945 г. Как

рассказывают, лейтенант Хоппер тестировал Mark II Aiken Relay Calculator в Гарвардском университете.

В один из дней программа, которая прежде работала, неожиданно загадочным образом отказала. В ре-

зультате осмотра оператор обнаружил моль, попавшую между точками переключения цепи и ставшую

причиной короткого замыкания (первые калькуляторы занимали большую площадь и содержали де-

сятки тысяч вакуумных ламп). Запись в журнале от 9 сентября 1945 года содержала саму моль и под-

пись: «Первый случай обнаружения насекомого (bug)», а также сообщала, что они «избавили от насеко-

мых (debugged) машину».

 Проектированиеиразработкаприложенийдляz/OS 255

8. Повторное выполнение компиляции/связывания/запуска и просмота состояния.

9. Проверка правильности выходных данных задания.

10. Сохранение исходного кода в SCLM (или PDS).

Некоторые программисты приложений для мэйнфреймов перешли на использо-

вание инструментов интерактивной среды разработки (IDE), чтобы ускорить процесс

редактирования, компиляции и тестирования. Инструменты IDE, такие как WebSphere

Studio Enterprise Developer, позволяют выполнять редактирование исходного кода на

рабочей станции, а не непосредственно на центральной системе, выполнять компи-

ляцию «вне платформы» и удаленную отладку.

Использование IDE в особенности полезно при построении гибридных приложе-

ний, использующих централизованные программы на языке COBOL или системы

транзакций, такие как CICS и IMS, но при этом содержащие пользовательский интер-

фейс, подобный веб-браузеру. IDE обеспечивает унифицированную среду для разра-

ботки как компонентов обработки оперативных транзакций (online transaction pro-

cessing, OLTP) на высокоуровневом языке, так и компонентов пользовательского HT-

ML-интерфейса переднего плана. После разработки и тестирования компонентов

выполняется их упаковка в соответствующем формате развертывания, затем они пе-

редаются группе, координирующей развертывание рабочего кода.

Помимо создания кода новых приложений программист приложений отвечает за

обслуживание и доработку существующих мэйнфрейм-приложений компании.

В действительности это часто является основной задачей для многих современных

программистов мэйнфрейм-приложений, использующих высокоуровневые языки.

Несмотря на то, что для создания новых программ для мэйнфреймов часто все еще

используется COBOL и PL/I, такие языки как Java набирают популярность точно так

же, как и на распределенных платформах.

Тем не менее, для тех, кто интересуется тради-

ционными языками, скажем, что все еще продол-

жается интенсивная разработка программ для

мэйнфреймов на высокоуровневых языках, таких

как COBOL и PL/I. Существует много тысяч про-

грамм в рабочих средах на мэйнфрейм-системах по всему миру, и эти программы

критически важны для повседневной работы корпораций, которые их используют.

Программисты на языке COBOL и других высокоуровневых языках нужны для под-

держки существующего кода и внесения обновлений и изменений в эти программы.

Кроме того, многие корпорации продолжают разрабатывать новые приложения

на языке COBOL и других традиционных языках, и IBM продолжает совершенство-

вать компиляторы высокоуровневых языков, включая в них новые функции и воз-

можности, позволяющие этим языкам продолжать использовать новые технологии

и форматы данных.

846 Выполнение системного тестирования

Разница между тестированием на этом этапе и тестированием на этапе разработки

состоит в том, что теперь выполняется тестирование приложения в целом, а также

совместно с другими приложениями. Кроме того, выполняются тесты, которые мож-

Транзакция–

действиеилизапрос

Выполняетобновлениеглав-

ныхфайловпризаказах,из-

менениях,добавленияхитд

256 Глава8

но осуществлять только после окончания разработки приложения, так как нам необ-

ходимо знать, как работает приложение в целом, а не только его часть.

На данном этапе выполняются следующие тесты:

• пользовательское тестирование – тестирование приложения на предмет функ-

циональности и практичности.

• интеграционное тестирование – новое приложение тестируется совместно

с другими приложениями, чтобы убедиться в том, что они взаимодействуют

должным образом.

• тестирование производительности (нагрузочный тест) – приложение тести-

руется с использованием реальных рабочих данных или, по меньшей мере,

данных реальных рабочих объемов, чтобы увидеть, как работает приложение

в условиях большой нагрузки.

Результаты пользовательских и интеграционных тестов нужно проверять, чтобы

убедиться в их допустимости. Кроме того, производительность приложения должна

соответствовать требованиям. Любые проблемы, возникающие во время этих тестов,

нужно решать до переноса в рабочую среду. Многие проблемы, возникающие на эта-

пе тестирования, являются индикатором того, насколько хорошо было выполнено

проектирование.

85 Перенос в рабочую среду на мэйнфрейме

Перенос в рабочую среду – это не просто нажатие кнопки, которая сообщает, что

теперь приложение готово к выполнению в рабочей среде. Это нечто гораздо бо-

лее сложное. И в разных проектах способ переноса программы в рабочую среду

может изменяться. В некоторых случаях, когда имеется существующая система, ко-

торую требуется заменить, может быть принято решение о параллельном выполне-

нии в течение определенного периода времени до переключения на новое прило-

жение. В этом случае старая и новая системы в течение этого периода работают

с одинаковыми данными, после чего результаты сравниваются. Если после некото

рого периода времени результаты удовлетворительны, выполняется переход на

новое приложение. Если обнаруживаются проблемы, их можно исправить и про-

должить параллельное выполнение до тех пор, пока не прекратиться возникнове-

ние новых проблем.

В других случаях мы работаем с новой системой, и у нас может быть только один

день для того, чтобы начать ее использовать. В случае новой системы обычно выпол-

няется замена некоторой системы, даже если это ручная система, поэтому при жела-

нии все равно можно выполнить параллельное тестирование.

Какой бы метод ни использовался для переноса в рабочую среду, все равно оста-

ются какие-то мелочи, которые следует решить до передачи системы операционному

персоналу. Одной из задач является разработка документации системы, а также про-

цедур ее запуска и использования. Требуется обучить всех, кто будет взаимодейство-

вать с системой.

После завершения создания документации и обучения можно передать ответс-

твенность за работу приложения операционному персоналу, а ответственность за

 Проектированиеиразработкаприложенийдляz/OS 257

сопровождение приложения группе сопровождения. В некоторых случаях сопровож-

дением приложений также занимается группа разработки.

На данном этапе жизненный цикл разработки приложений достигает стабильно-

го состояния, и происходит переход к этапу сопровождения приложения. С этого

момента только лишь применяются усовершенствования и выполняются повседнев-

ные изменения в приложении. Так как приложение теперь находится под контролем

за изменениями, все изменения требуют тестирования в соответствии с процессом

контроля за изменениями до их принятия в рабочей среде. Таким образом, обеспечи-

вается стабильная работа приложения с точки зрения конечных пользователей.

86 Заключение

В этой главе описываются роли проектировщика приложений и программиста при-

ложений. Обсуждение направлено на то, чтобы выявить типы решений, задейство-

ванных в проектировании и разработке приложения, выполняющегося в среде мэйн-

фреймов. Это не означает, что процесс намного отличается от других платформ, од-

нако некоторые вопросы и выводы могут отличаться.

Затем в этой главе описывается жизненный цикл проектирования и разработки

приложения, выполняющегося в z/OS. Процесс начинается с этапа сбора требований,

на котором проектировщик приложения анализирует пользовательские требования,

чтобы увидеть, как их удовлетворить. Может существовать множество вариантов ре-

шения; цель этапов анализа и проектирования состоит в том, чтобы обеспечить вы-

бор оптимального решения. В данном случае под «оптимальным» не понимается «са-

мое быстрое», хотя время является важным аспектом любого проекта. Вместо этого,

оптимальным называется наилучшее в целом решение, с точки зрения пользователь-

ских требований и анализа задачи.

Набор символов EBCDIC отличается от набора символов ASCII. Посимвольное

преобразование между этими двумя наборами символов выполняется просто. С уче-

том последовательностей сортировки различия становятся более значимыми, и про

граммы преобразования из одного набора символов в другой могут быть простыми

или довольно сложными. Набор символов EBCDIC стал общепринятым стандартом

до того, как современный 8-разрядный набор символов ASCII получил широкое при-

менение.

По окончании этапа проектирования наступает очередь программиста. Теперь

программист должен преобразовать проект приложения в безошибочный програм-

мный код. На протяжении этапа разработки программист тестирует код по мере до-

бавления каждого модуля в общую программу. Он должен исправить все обнаружен-

ные проблемы в логике и добавить обновленные модули к завершенному набору

протестированных программ.

Приложение редко существует в изоляции. Обычно приложение является частью

крупного набора приложений, где выходные данные одного приложения являются

входными данными следующего. Чтобы убедиться в том, что новое приложение не

вызывает проблем при внедрении в более крупный набор приложений, программист

приложения проводит системный тест или интеграционный тест. Эти тесты сами

258 Глава8

проектируются, и результаты многих тестов проверяются непосредственными поль-

зователями приложений. Если во время системного теста обнаруживаются какие-ли-

бо проблемы, их необходимо решить и повторить тест, прежде чем можно будет пе-

рейти к следующему этапу процесса.

После успешного выполнения системного теста приложение готово к переносу

в рабочую среду. Этот этап иногда называется внедрением приложения. После внед

рения код приложения подлежит более тщательному контролю. Предприятию не

следует вносить изменения в рабочую систему, не будучи уверенным в их надежнос-

ти. На большинстве z/OS-узлов существуют строгие правила внедрения приложений

(или модулей внутри приложений), позволяющие не допустить попадания непротес-

тированного кода в «чистую» систему.

На данном этапе жизненного цикла приложение достигло стабильного состояния.

Изменения, вносимые в рабочее приложение, представляют собой усовершенствова-

ния, функциональные изменения (например, изменения программ ведения ведомос-

тей в связи с изменениями в налоговом законодательстве) или исправления.

Основные термины в этой главе

Приложение ASCII Базаданных

Проектирование Разработка EBCDIC

Исполняемыйкод

Платформа Транзакция

87 Контрольные вопросы

Чтобы проверить понимание материала этой главы, ответьте на следующие вопросы:

1. В чем различия между проектировщиком приложений и программистом при

ложений? Какая из этих ролей должна иметь общее представление о проекте

в целом?

2. На каком этапе жизненного цикла разработки приложения проектировщик про

водит собеседования?

3. Какая цель использования хранилища для управления исходным кодом?

4. Какие существуют этапы жизненного цикла разработки приложения? Вкратце

расскажите, что происходит на каждом этапе.

5. Если бы вы были проектировщиком в конкретном проекте и нужно очень быстро

внедрить новое приложение в рабочую среду, какие решения вы бы приняли, что-

бы сократить общее время проекта?

6. На этапе системного тестирования выполняется тест производительности при

ложения. Почему следует использовать рабочие данные при проведении этого

теста?

7. Назовите возможные причины для решения использовать в приложении пакет

ную, а не оперативную обработку.

8. Почему не получается сохранять все документы в формате ASCII, чтобы их не

приходилось преобразовывать из формата EBCDIC?

 Проектированиеиразработкаприложенийдляz/OS 259

Использование языков

программирования в z/OS

ЦельКакновомупрограммиступриложенийдляz/OS,вамнеобходимознать

отом,какиеязыкипрограммированияподдерживаютсявz/OS,икакопределить,

какойизнихявляетсянаилучшимдляпоставленныхтребований

Послезавершенияработынадэтойглавойвысможете:

• перечислитьнекоторыеязыкипрограммированиядлямэйнфрейма;

• объяснитьразличиямеждукомпилируемымязыкомиинтерпретируемым

языком;

• создатьпростуюCLIST-илиREXX-программу;

• выбратьправильнуюорганизациюфайловданныхдляоперативного

приложения;

• сравниватьпреимуществавысокоуровневыхязыковиассемблера;

• объяснитьсвязьмеждуименемнабораданных,DD-именемиименемфайла

впрограмме;

• объяснить,какиспользованиеz/OSLanguageEnvironmentвлияетнарешения,

принимаемыепроектировщикомприложений

260 Глава9

91 Обзор языков программирования

Язык программирования является средством об-

щения между человеком и компьютером. Он нужен

потому, что компьютер работает только со своим

машинным языком (состоящим из битов и байтов). Для человека машинный язык яв-

ляется сложным и медленным в использовании. Поэтому написание программ вы-

полняется на компьютерном языке, после чего они преобразуются в машинный язык,

с которым работает компьютер.

Существует множество компьютерных языков,

являющихся результатом эволюции от машинного

языка к более естественному способу письма. Не-

которые языки были адаптированы к типам приложений, для которых они предна-

значены, и к подходу, используемому в проектировании. Для обозначения этапов

этой эволюции используется слово поколение.

Ниже приведена классификация компьютерных языков.

1. Машинный язык, 1-е поколение, непосредственный машинный код.

2. Ассемблер, 2-е поколение, использование мнемоники для представления инструк

ций, преобразуемых в машинный код программой ассемблирования, в частности

языком ассемблер.

3. Процедурные языки, 3-е поколение, также называются высокоуровневыми языка

ми (high-level languages, HLL); сюда относятся Pascal, FORTRAN, Algol, COBOL, PL/I,

Basic и C. Написанную программу, называемую исходной программой, необходи-

мо транслировать посредством этапа компиляции.

4. Непроцедурные языки, 4-е поколение, также имеют общее название 4GL; использу

ются для предопределенных функций в приложениях, предназначенных для работы

с базами данных, генераторах отчетов, запросах; сюда относятся RPG, CSP, QMF™.

5. Визуальные языки программирования, использующие мышь и значки, такие как

VisualBasic и VisualC++.

6. HyperText Markup Language, используемый для написания веб-документов.

7. Объектно-ориентированные языки, OO-технология; сюда относятся Smalltalk, Java

и C++.

8. Прочие языки, например для написания 3D-приложений.

Каждый компьютерный язык развивается самостоятельно в условиях создания

и адаптации к новым стандартам. В следующих разделах мы рассмотрим некоторые

из наиболее используемых компьютерных языков, поддерживаемых в z/OS.

• Ассемблер – «Использование ассемблера в z/OS».

• COBOL – «Использование COBOL в z/OS».

• PL/I – «Использование PL/I в z/OS».

• C/C++ – «Использование C/C++ в z/OS».

• Java – «Использование Java в z/OS».

• CLIST – «Использование CLIST в z/OS».

• REXX – «Использование REXX в z/OS».

Языкпрограммирования–

средствообщениямежду

человекомикомпьютером

Поколение–

этапыэволюции

компьютерныхязыков

 Проектированиеиразработкаприложенийдляz/OS 261

К этому списку можно добавить использование скриптов оболочки и языка PERL

в среде z/OS UNIX System Services.

Что касается рассматриваемых компьютерных языков, в этой главе описывается

их эволюция и классификация. Среди них есть процедурные и непроцедурные, ком-

пилируемые и интерпретируемые, машинно-зависимые и машинно-независимые

языки.

Программы на ассемблере являются машинно-зависимыми (machine-dependent),

так как язык представляет собой символьную версию машинного языка того компью-

тера, на котором выполняется программа. Инструкции ассемблера на разных ком-

пьютерах могут отличаться, поэтому программа на ассемблере, написанная для од-

ного компьютера, может не работать на другом компьютере. Скорее всего, ее придет-

ся переписать, используя набор инструкций другого компьютера. Программа, напи-

санная на высокоуровневом языке, будет работать на других платформах, но ее пот-

ребуется перекомпилировать в машинный язык целевой платформы.

Большинство высокоуровневых языков, рассматриваемых в этой главе, являются

процедурными языками (procedural languages). Этот тип языков хорошо подходит для

написания структурированных программ. Непроцедурные языки (non-procedural lan-

guages), такие как SQL и RPG, больше подходят для специальных целей, таких как ге-

нерирование отчетов.

Большинство высокоуровневых языков компилируются в машинный код, однако

некоторые из них являются интерпретируемыми. Результатом компиляции является

машинный код, очень эффективный для многократного выполнения. Программы на

интерпретируемых языках анализируются, интерпретируются и выполняются при

каждом запуске программы. При использовании интерпретируемых языков умень-

шается время составления программы, однако увеличивается использование машин-

ных ресурсов.

Преимущества компилируемых и интерпретируемых языков более подробно

рассматриваются в разделе 9.11 «Компилируемые и интерпретируемые языки».

92 Выбор языка программирования в z/OS

При разработке программы, предназначенной для выполнения в z/OS, выбор языка

программирования может определяться следующими аспектами:

• Какой тип имеет приложение?

• Каковы требования к времени реагирования?

• Каковы бюджетные ограничения для разработки и последующей поддержки?

• Каковы временные ограничения проекта?

• Нужно ли составлять некоторые подпрограммы на других языках из-за пре-

имуществ определенного языка по сравнению с основным выбранным

языком?

• Использовать ли компилируемый или интерпретируемый язык?

В следующих разделах рассматриваются особенности некоторых языков, подде-

рживаемых на мэйнфреймах.