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

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

282 Глава9

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

претируемые программы обычно менее эффективны, чем компилируемые.

Некоторые языки программирования, такие как REXX и Java, допускают как ин-

терпретацию, так и компиляцию.

9112 Преимущества интерпретируемых языков

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

использования компилируемых языков. В разделах «Использование языка CLIST в z/

OS» и «Использование языка REXX в z/OS» обсуждались сильные стороны интерпре-

тируемых языков. Не существует ответа на вопрос, какой язык «лучше» – все зависит

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

ных языков. Например, одно из преимуществ такого языка как CLIST состоит в про-

стоте кодирования, тестирования и внесения изменений. Однако он не очень эффек-

тивен. В данном случае компромисс состоит в увеличении требуемых машинных ре-

сурсов взамен уменьшения времени разработки.

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

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

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

интенсивные части можно написать на интерпретируемом языке. Интерпретируе-

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

разработки прототипа приложения.

Одна из задач проектировщика состоит в том, чтобы сопоставить преимущества

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

иной части приложения.

912 Что такое z/OS Language Enironment?

Как говорилось в главе 8 «Проектирование и разработка приложений для z/OS», при-

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

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

запасами или ведение ведомостей. Цели разработки приложений включают модуль-

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

станции.

В z/OS Language Environment обеспечивает общую среду для всех соответствую-

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

граммирования более высокого уровня, чем ассемблер, но более низкого уровня, чем

в генераторах программ и языки запросов. z/OS Language Environment обеспечивает

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

в z/OS. Если функции были предварительно реализованы в отдельных языковых про

дуктах, Language Environment устраняет необходимость поддерживать отдельные

языковые библиотеки.

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

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

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

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

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

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

течными подпрограммами.

В Language Environment благодаря возможности обращения из одного языка

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

можности в каждом языке.

9121 Как используется Language Enironment

Language Environment создает общую среду выполнения для всех используемых вы-

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

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

аций и управления памятью. Доступ к этим службам осуществляется через набор ин-

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

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

языка, вызывающие интерфейсы.

Language Environment позволяет использовать одну среду выполнения для прило-

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

темным ресурсам.

На рис. 9.5 представлены компоненты Language Environment, в том числе:

• Основные подпрограммы, поддерживающие запуск и остановку программ,

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

а также индикацию и обработку ситуаций.

• Общие библиотечные службы, в частности математические службы и службы

времени, часто требуемые программам, запускаемым в системе. Эти функции

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

• Фрагменты библиотеки времени выполнения, ориентированные на опреде-

ленный язык.

Библиотека,

ориентированная

на C/C++

Библиотека,

ориентированная

на COBOL

Библиотека,

ориентированная

на FORTRAN

Библиотека,

ориентированная

на PL/I

Вызываемый сервисный интерфейс, общие службы и поддерживающие

подпрограммы среды Language Environment

Рис 95 Компонентыz/OSLanguageEnvironment

Language Environment представляет собой обязательную среду выполнения для

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

• z/OS C/C++;

• C/C++ Compiler for z/OS;

• AD/Cycle

C/370™ Compiler;

284 Глава9

• VisualAge

for Java, Enterprise Edition for OS/390;

• Enterprise COBOL for z/OS and OS/390;

• COBOL for z/OS;

• Enterprise PL/I for z/OS and OS/390;

• PL/I for MVS and VM (прежде назывался AD/Cycle PL/I for MVS and VM);

• VS FORTRAN и FORTRAN IV (в режиме совместимости).

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

предыдущими версиями вышеперечисленных компиляторов. Также существует набор

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

в Language Environment.

9122 Подробнее о Language Enironment

Компоненты Language Environment, ориентированные на определенный язык, обес-

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

дого отдельного языка, которые могут вызываться через общий интерфейс вызовов.

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

На рис. 9.6 представлена общая среда выполнения, создаваемая Language Environment.

FORTRAN

COBOL

PL/I

C/C++

Assembler

CEL

PL/I C/C++

COBOL FORTRAN

TSO

Операционная система

Пакетная

обработка

Системные

службы

UNIX

IMS

(FORTRAN

не включен)

DB2

(FORTRAN

не включен)

CICS

(FORTRAN

не включен)

Исходный

код

Компиляторы

Ассемблер

не требует

библиотеки

времени

выполнения

Рис 96 ОбщаясредавыполненияLanguageEnvironment

Архитектура среды Language Environment построена на следующих моделях:

• модель управления программой;

• модель обработки ситуаций;

• модель служб сообщений;

• модель управления памятью.

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

Модель управления программой

Модель управления программой Language Environment обеспечивает инфраструктуру,

в которой выполняется приложение. Она является основой для всех моделей компо

нентов (модели обработки ситуаций, модели обработки сообщений времени выполне-

ния и модели управления памятью), составляющих архитектуру Language Environment.

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

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

и многопоточную обработку.

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

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

имеют другое значение. Важно понимать значения терминов в контексте Language

Environment в сравнении с другими контекстами.

Управление программой

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

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

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

В основе модели управления программой в Language Environment лежат три сущ-

ности: процесс (process), анклав (enclave) и поток (thread).

Процессы

Компонентом наивысшего уровня в модели программы Language Environment явля-

ется процесс (process). Процесс состоит по меньшей мере из одного анклава и логи-

чески отделен от других процессов. Language Environment обычно не допускает сов-

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

доступа к наборам внешних данных.

Анклавы

Основной сущностью в модели управления программой является анклав (enclave),

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

ляется аналогом следующих понятий:

• выполняемого модуля в COBOL;

• программы, содержащей функцию main и ее подфункции в C и C++;

• процедуры main и всех ее подпрограмм в PL/I;

• программы и ее подпрограммы в Fortran.

В Language Environment под «средой» обычно понимается среда выполнения вы-

сокоуровневого языка на уровне анклава. Анклав содержит одну процедуру main и ни

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

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

Потоки

Каждый анклав содержит по меньшей мере один поток (thread), представляющий

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

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

286 Глава9

при выполнении потока, а также собственный счетчик инструкций, регистры и меха-

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

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

Main

Sub

Main

Sub Sub

Внешние

данные X

Внешние

данные Y

...

Внешние

данные Y

Внешние

данные Z

...

Поток

Анклав

Main

Внешние

данные X

Внешние

данные Y

...

Поток

Анклав

Процесс

Поток

Рис 97 ПолнаямодельпрограммLanguageEnvironment

На рис. 9.7 представлена полная модель программ Language Environment со мно-

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

находится в собственном адресном пространстве. Анклав содержит одну процедуру

main и некоторое количество подпрограмм.

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

Модель обработки ситуаций

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

Language Environment предоставляет согласованное и предсказуемое средство обра-

ботки ситуаций. Оно не призвано заменить текущую обработку ситуаций в высокоу-

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

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

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

Управление ситуациями в Language Environment обеспечивает гибкость непос-

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

рующих о ситуациях и запрашивающих информацию об этих ситуациях. Также оно

содержит функции диагностики ошибок, генерирования отчетов об ошибках и вос-

становления после ошибок.

Модель обработки сообщений и поддержка национальных языков

Language Environment содержит набор общих служб обработки сообщений, создаю-

щих и передающих информационные и диагностические сообщения времени вы-

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

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

ции, преобразовывать его в сообщение и передавать в заданное устройство вывода

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

национальный язык для вывода сообщений об ошибках, а также названия дней и ме-

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

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

ми и разделитель тысяч.

Модель управления памятью

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

соответствующих Language Environment; среда Language Environment контролирует

стек и кучу (heap), используемые во время выполнения. Она позволяет одноязычным

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

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

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

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

ти между различными механизмами хранения.

9123 Выполнение программы в Language Enironment

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

• скомпоновать и запустить существующий объектный модуль и принять задан-

ные по умолчанию опции времени выполнения Language Environment;

• скомпоновать и запустить существующий объектный модуль и задать новые

опции времени выполнения Language Environment;

• вызвать службу Language Environment.

Применение заданных по умолчанию опций времени выполнения

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

заданных по умолчанию опций времени выполнения Language Environment можно ис-

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

в Language Environment (каталогизированные процедуры обсуждаются в разделе 6.7 «JCL-

процедуры (PROC)». Процедура CEEWLG идентифицирует библиотеки Language Environ-

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

288 Глава9

Службы библиотеки времени выполнения

Библиотеки Language Environment находятся в наборах данных, идентифицируемых

старшим квалификатором, характерным для инсталляции. Например, SCEERUN со-

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

нении приложений, написанных на языках C/C++, PL/I, COBOL и FORTRAN. SCEERUN2

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

полнении приложений, написанных на языках C/C++ и COBOL.

Приложения, которым требуется библиотека времени выполнения, обеспечиваемая

средой Language Environment, могут осуществлять доступ к наборам данных SCEERUN

и SCEERUN2 с использованием одного или обоих нижеперечисленных методов:

• LNKLST;

• STEPLIB.

Важно! Подпрограммы библиотекиLanguageEnvironmentразделенынадвекатегории:

резидентныеподпрограммыидинамическиеподпрограммыРезидентныеподпрограммы

связанысприложениемисодержатподпрограммыинициализацииизавершенияпроцесса,

атакжеуказателинавызываемыеслужбыДинамическиеподпрограммынеявляютсячастью

приложенияидинамическизагружаютсявовремявыполнения

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

компоновку и запуск приложений в Language Environment.

Вызываемые службы Language Enironment

Согласованные службы обработки ситуаций, реализованные в Language Environment,

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

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

ты-времени.

Вызываемые службы Language Environment разделены на следующие группы:

• Службы ситуаций связи.

• Службы обработки ситуаций.

• Службы даты-времени.

• Службы динамической памяти.

• Общие вызываемые службы.

• Службы инициализации и завершения процессов.

• Вызываемые службы региональных параметров.

• Математические службы.

• Службы обработки сообщений.

• Службы поддержки национальных языков.

Дополнительные сведения. Вызываемые службы более подробно описываются

в публикации z/OS Language Environment Programming Reference, SA22-7562.

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

Соглашения вызовов в Language Enironment

Службы Language Environment могут вызываться подпрограммами библиотек высо-

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

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

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

ской функции. Ниже представлены примеры вызовов вызываемой математической

службы из трех языков, рассматривавшихся в этой главе. Также см. примеры в разделе

9.9.3 «Другие варианты использования языка CLIST».

В Примере 9.8 представлен вызов вызываемых математических служб CEESDLG1 для

логарифма по основанию10

из COBOL-программы.

Пример 9.8. Образец вызова математической вызываемой службы из COBOL-программы

77 ARG1RL COMP-2.

77 FBCODE PIC X(12).

77 RESLTRL COMP-2.

CALL «CEESDLG1» USING ARG1RL , FBCODE ,

RESLTRL.

913 Заключение

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

при проектировании и разработке приложения для z/OS. Выбор языка программиро-

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

щик приложения должен иметь представление о преимуществах и недостатках каж-

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

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

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

приложений инсталляции используется COBOL, скорее всего этот язык будет выбран

и для новых приложений этой инсталляции.

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

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

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

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

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

максимально увеличить эффективность приложения, даже если остальная часть при-

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

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

на предприятии. Библиотека, например, может включать подпрограммы преобразо-

вания дат. Если эти подпрограммы написаны в соответствии со стандартными согла-

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

каком языке написаны подпрограммы.

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

использовать эти преимущества. Если приложение заслуживает того, чтобы пойти на

290 Глава9

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

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

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

другие люди также должны будут уметь программировать на этих языках. Это являет-

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

давно уйти из компании, а приложению еще жить и жить.

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

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

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

Ассемблер Компоновщик Компилятор

Отладка Динамическаябиблиотека Генерирование

Ввод-вывод Интерпретатор Загрузочныемодули

Препроцессор Языкпрограммирования Переменная

914 Контрольные вопросы

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

1. Почему некоторые программы пишут на ассемблере?

2. Продолжают ли компании совершенствовать компиляторы для COBOL и PL/I?

3. Почему CLIST и REXX называются интерпретируемыми языками?

4. Каковы основные сферы применения CLIST и REXX?

5. Какой интерпретируемый язык также поддерживает компиляцию?

6. Является ли использование Language Environment обязательным при разработке

приложений для z/OS?

7. Какой из вариантов организации файлов данных является приемлемым для опе

ративных приложений? Какой приемлем для пакетных приложений?

8. Что такое высокоуровневый язык? Какие преимущества составления программ на

высокоуровневом языке в сравнении с ассемблером?

9. Предположим, что программа PROG1 запущена с использованием следующего

JCL-кода:

//job JOB

//STEP010 EXEC PGM=PROG1

//STEPLIB DD DSN=MY.PROGLIB,DISP=SHR

//INPUT1 DD DSN=A.B.C,DISP=SHR

//OUTPUT1 DD DSN=X.Y.Z,DISP=SHR

Если изменить карту INPUT1 DD таким образом, чтобы использовался набор дан-

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

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

данных.

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

915 Темы для дальнейшего обсуждения

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

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

2. Если требуется разработать систему обработки транзакций, какой из следующих

языков будет наилучшим вариантом выбора?

а) COBOL или PL/I на CICS.

б) C/C++ на CICS.

в) Комбинация из вышеперечисленного.

3. Какой язык вы бы использовали для написания приложения, вычисляющего пре

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

множеством других приложений.

4. Может ли COBOL-программа вызвать программу на ассемблере? Чем может быть

полезна такая возможность?