Введение

Языки скриптов, используемые на IBM mainframe

Job Control Language (JCL) – это общее название для языков скриптов, применяемых в операционных системах IBM mainframe для указания системе, как выполнить пакетную задачу или запустить подсистему. Основная задача JCL – определить, какие программы запускать, какие файлы или устройства использовать для ввода и вывода данных, а также, в некоторых случаях, указать условия пропуска отдельных шагов. Параметры в JCL могут также содержать учетную информацию для отслеживания ресурсов, потребляемых задачей, и указания машины, на которой задача должна быть выполнена. Существует два различных языка управления заданиями IBM Job Control: один для семейства операционных систем, начинающегося с DOS/360 и включающего в себя z/VSE в качестве последней версии; и другой – для семейства от OS/360 до z/OS, последний из которых теперь включает расширения JES, а также язык управления входом заданий (JECL). Они имеют некоторые общие правила синтаксиса и несколько базовых концепций, но в остальном существенно отличаются. Операционная система VM не использует JCL как таковой; компоненты CP и CMS имеют собственные языки команд.

Терминология

Некоторые слова или фразы, используемые в сочетании с JCL, специфичны для технологии IBM-мейнфреймов. Набор данных: "набор данных" – это файл; он может быть временным или постоянным и располагаться на диске, магнитной ленте или другом устройстве. Член: "член" разделенного набора данных (PDS) – это отдельный набор данных внутри PDS. Доступ к члену можно получить, указав имя PDS с именем члена в скобках. Например, системный макрос GETMAIN в SYS1.MACLIB можно адресовать как SYS1.MACLIB(GETMAIN). Разделенный набор данных: "разделенный набор данных" или PDS – это коллекция членов, или архив. Разделенные наборы данных обычно используются для хранения текстовых данных, таких как исходный код, макросы ассемблера (SYS1.MACLIB), конфигурация системы (SYS1.PARMLIB), повторно используемые процедуры JCL (SYS1.PROCLIB) и т.д. Таким образом, они имеют общие черты с архивными файлами (ZIP, TAR и т.п.) и с каталогами в других операционных системах. Они также используются для хранения двоичного кода (модулей загрузки или программных объектов); в этом качестве они приблизительно аналогичны статическим библиотекам на основе ar в Unix-подобных системах. Как и в большинстве подобных структур, член, после сохранения, нельзя изменить; член необходимо удалить и заменить, например, с помощью утилиты IEBUPDTE. С точки зрения пользователя или программиста приложений они практически не изменились (за исключением удаления некоторых устаревших функций), но их внутренняя реализация существенно отличается. USS: Unix System Services – полноценная среда Unix, работающая как часть базовой управляющей программы MVS и позволяющая файлам, скриптам, задачам и программам Unix выполняться на мейнфрейме в полностью POSIX-совместимой среде Unix без виртуализации.

Мотивация

Первоначально, системы мэйнфреймов были ориентированы на пакетную обработку. Многие пакетные задания требуют предварительной настройки, с конкретными требованиями к основной памяти и выделенным устройствам, таким как магнитные ленты, отдельные дисковые тома и принтеры, настроенные для работы со специальными формами. JCL был разработан как средство обеспечения доступности всех необходимых ресурсов перед началом выполнения задания. Например, во многих системах, таких как Linux, можно указать необходимые наборы данных в командной строке, что позволяет оболочке выполнять их замену или генерировать их программе во время выполнения. В этих системах планировщик заданий операционной системы практически не учитывает требования задания. В отличие от этого, JCL явно определяет все необходимые наборы данных и устройства. Планировщик может предварительно выделить ресурсы до запуска задания. Это помогает избежать ситуации взаимной блокировки (deadlock), когда задание А удерживает ресурс R1 и запрашивает ресурс R2, а параллельно выполняющееся задание B удерживает ресурс R2 и запрашивает R1. В таких случаях единственным решением является принудительное завершение одного из заданий оператором, после чего его необходимо перезапустить. При использовании контроля заданий, если задание А запланировано к выполнению, задание B не будет запущено до тех пор, пока задание А не завершится или не освободит необходимые ресурсы.

Зависимость от устройства

В оригинальной DOS/360 и в большинстве версий DOS/VS требовалось указывать номер модели устройства, которое должно было использоваться для каждого дискового или ленточного файла – даже для существующих файлов и для временных файлов, которые удалялись по окончании задания. Это означало, что при переходе клиента на более современное оборудование приходилось изменять множество файлов JCL. В более поздних версиях семейства DOS/360 количество ситуаций, в которых требовалось указывать номера моделей устройств, было сокращено.

Ручное распределение файлов

DOS/360 изначально требовал от программиста указывать местоположение и размер всех файлов на DASD. Карта EXTENT указывает том, на котором расположен extent, начальный абсолютный трек и количество треков. Для z/VSE файл может иметь до 256 extent на разных томах.

Доступ к данным (положение DD)

Заявление DD используется для обращения к данным. Это утверждение связывает внутреннее описание набора данных в программе с данными на внешних устройствах: дисках, магнитных лентах, перфокартах, принтерах и т.п. Заявление DD может содержать информацию, такую как тип устройства (например, "181", "2400 5", "TAPE"), серийный номер тома для магнитных лент или дисков, а также описание файла данных, называемое подпараметром DCB, основанным на блоке управления данными (DCB) в программе, используемой для идентификации файла. Информация, описывающая файл, может поступать из трех источников: информация, указанная в заявлении DD, информация из метки набора данных для существующего файла, хранящегося на магнитной ленте или диске, и макрос DCB, закодированный в программе. При открытии файла эти данные объединяются, при этом информация из заявления DD имеет приоритет над информацией из метки, а информация из DCB имеет приоритет над обеими. Обновленное описание затем записывается обратно в метку набора данных. Это может привести к нежелательным последствиям, если предоставлена неверная информация DCB. Благодаря перечисленным выше параметрам и специфической информации для различных методов и устройств доступа, заявление DD является самым сложным элементом JCL. В одном справочном руководстве IBM описание заявления DD занимает более 130 страниц – более чем в два раза больше, чем описания заявлений JOB и EXEC вместе взятые. Заявление DD позволяет внедрять встроенные данные в поток заданий. Это полезно для предоставления управляющей информации таким утилитам, как IDCAMS, SORT и т.д., а также для предоставления входных данных программам.

Независимость устройства

С самого начала JCL для семейства операционных систем OS обеспечивал высокую степень независимости от устройств. Даже для новых файлов, которые должны были сохраняться после завершения задания, можно было указать тип устройства в общих чертах, например, UNIT=DISK, UNIT=TAPE или UNIT=SYSSQ (магнитная лента или диск). Разумеется, если это имело значение, можно было указать номер модели или даже конкретный адрес устройства.

Условная обработка

ОС ожидает, что программы установят код возврата, указывающий на степень успешности их выполнения. Наиболее часто используемые условные значения:

Коммунальные услуги

Задания используют ряд служебных программ IBM для помощи в обработке данных. Служебные программы наиболее полезны при пакетной обработке. Служебные программы можно сгруппировать в три набора:
Утилиты работы с наборами данных – создание, печать, копирование, перемещение и удаление наборов данных. Системные утилиты – обслуживание и управление каталогами и другой системной информацией. Службы методов доступа – обработка наборов данных с использованием метода прямого доступа (VSAM) и наборов данных, не использующих VSAM.

Трудности использования

ОС JCL, несомненно, сложна. Как одна из книг по JCL спрашивала: "Почему даже опытные программисты испытывают колебания, когда дело касается языка управления заданиями?" Подобное отношение встречалось в учебниках по языкам программирования, которые предпочитали сосредотачиваться на самом языке, а не на способах запуска программ, написанных на нем. В одном учебнике Fortran IV, перечисляя возможные сообщения об ошибках компилятора WATFOR, говорилось: "Вы настолько безрассудны, что попытались написать собственные системные управляющие карты 'DD'? Немедленно прекратите и больше не делайте этого; бегите за помощью, не медлите!" Тем не менее, некоторые книги, подробно рассматривающие JCL, подчеркивали, что освоив его хотя бы на приемлемом уровне, можно получить свободу от общесистемных настроек по умолчанию и значительно лучше контролировать процесс обработки вашей рабочей нагрузки системой IBM.

Язык контроля поступления на работу

На IBM-мейнфреймах язык управления входом в работу (Job Entry Control Language) или JECL — это набор операторных команд, предоставляющих информацию подсистеме спулинга – JES2 или JES3 в z/OS или VSE/POWER для z/VSE. Операторы JECL могут указывать, на каком сетевом компьютере, когда и куда направлять результаты выполнения задания. JECL отличается от языка управления заданиями (JCL), который содержит инструкции для операционной системы о том, как выполнять задание. Существуют различные версии JECL для каждой из этих сред.

OS/360

Ранняя версия языка управления вводом заданий для OS/360 Remote Job Entry (номер программы 360S RC 536) использовала идентификатор в столбцах 1–2 входной записи и состояла из одного управляющего оператора: JED (Job Entry Definition). "Команды рабочих станций", такие как LOGON, LOGOFF и STATUS, также начинались с .

до-JES JECL

Хотя термин еще не был разработан, HASP обладал функциональностью, схожей с той, что впоследствии появилась в JECL JES, включая синтаксис /*.

z/OS

Для JES2 операторы JECL начинаются с /*, для JES3 – с //*, за исключением удаленных команд /*SIGNON и /*SIGNOFF. Команды для этих двух систем полностью отличаются.