Как преобразовать JCL в COBOL и почему это важно

В каждом корпоративном мэйнфрейме используются два взаимосвязанных языка, которые большинство современных разработчиков никогда не писали. COBOL реализует бизнес-логику, вычисления, обработку файлов, преобразование записей, подготовку нормативной отчетности. JCL (Job Control Language) координирует выполнение этой логики, определяя, какие программы запускаются, в каком порядке, с какими файлами, при каких условиях и что происходит в случае их успешного или неудачного выполнения. Ни один язык не является полным без другого. Программа на COBOL не имеет представления о том, откуда берутся входные файлы и куда направляются выходные данные; JCL отвечает на оба вопроса еще до того, как будет прочитана первая запись.

Для организаций, занимающихся обслуживанием, аудитом или модернизацией мэйнфрейм-систем, понимание взаимосвязи JCL и COBOL — это не просто базовые знания, а необходимое условие для всего: анализа влияния перед любыми изменениями, документирования перед любой миграцией, передачи знаний перед уходом специалиста на пенсию. Задача обработки ежедневных счетов, пакетный запуск для генерации квартальных отчетов для регулирующих органов, процедура передачи данных из одной системы в другую — все это определяется JCL, выполняется COBOL и понимается лишь немногочисленным числом инженеров, работавших с обоими языками.

Что такое JCL?

JCL расшифровывается как Job Control Language (язык управления заданиями). Это скриптовый язык, используемый в мэйнфреймах IBM для отправки пакетных заданий на выполнение. JCL сам по себе не обрабатывает данные. Он указывает операционной системе, как выполнять программы: какую программу запустить, какие файлы сделать доступными, какие ресурсы памяти и ЦП выделить, что делать в случае сбоя шага и в какой последовательности выполнять несколько шагов в рамках одного задания.

Каждая задача JCL состоит из трех основных типов операторов:

Оператор JOB идентифицирует задание для системы и определяет параметры учета, приоритета и планирования.

Оператор EXEC задает программу или процедуру для выполнения на определенном этапе.

Оператор DD (Data Definition) определяет наборы данных, которые программа будет читать или записывать, включая их местоположение, формат и обработку.

JCL

//PAYBATCH JOB (ACCT#7), 'PAYROLL RUN',
//          CLASS=A, MSGCLASS=X, NOTIFY=&SYSUID
//*
//STEP010  EXEC PGM=PAYROLL1
//STEPLIB  DD   DSN=PROD.PAYROLL.LOADLIB,DISP=SHR
//EMPFILE  DD   DSN=PROD.PAYROLL.EMPLOYEE,DISP=SHR
//TRANSACT DD   DSN=PROD.PAYROLL.TRANS.D&&DATE,DISP=SHR
//PAYRPT   DD   SYSOUT=A
//SYSOUT   DD   SYSOUT=*
//SYSIN    DD   DUMMY

В этом примере: PAYBATCH это название должности, STEP010 это один из этапов работы. PGM=PAYROLL1 Указывает имя программы COBOL для выполнения, а операторы DD определяют все файлы, к которым программа может получить доступ. Программа COBOL PAYROLL1 не знает и не интересуется, где EMPFILE or TRANSACT Данные поступают из физического источника, но считываются по имени ddname. JCL определяет физическое местоположение, формат записи и режим доступа до начала выполнения.

Процедуры, каталогизированные в JCL (PROCs)

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

JCL

//PAYPROC  PROC RUNDATE=TODAY
//COMPILE  EXEC PGM=IGYCRCTL,PARM='OBJECT,NODUMP'
//SYSIN    DD   DSN=PROD.COBOL.SRC(&MEMBER),DISP=SHR
//SYSOBJ   DD   DSN=&&OBJSET,DISP=(NEW,PASS),
//              UNIT=SYSDA,SPACE=(TRK,(10,5))
//LKED     EXEC PGM=IEWL,PARM='LIST,LET,XREF'
//SYSLIN   DD   DSN=&&OBJSET,DISP=(OLD,DELETE)
//SYSLMOD  DD   DSN=PROD.PAYROLL.LOADLIB(&MEMBER),
//              DISP=SHR
//         PEND

Вызов процедуры PROC из задания:

JCL

//COMPILE  EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205

Эта единственная инструкция EXEC разворачивается в полную процедуру PROC во время выполнения, с MEMBER и RUNDATE подставлено везде &MEMBER и &RUNDATE Появляются PROC-процессы. Они являются одной из основных причин сложности сопоставления JCL с COBOL: задание может вызывать десятки программ COBOL через одну ссылку на PROC, и фактически вызываемые программы зависят от символических параметров, которые меняются при каждом запуске.

В чём разница между JCL и COBOL?

JCL и COBOL часто упоминаются вместе, но они выполняют совершенно разные функции. Ни один из них не заменяет другой, и оба необходимы для корректной работы пакетной обработки на мэйнфреймах.

Размеры	JCL	Кобол
Цель	Организует исполнение	Реализует бизнес-логику.
Что это определяет	Задания, этапы, файлы, условия	Программы, структуры данных, вычисления
Когда он работает	До выполнения программы (настройка) и после (очистка)	Во время выполнения программы
Чтение/запись данных	Путем выделения набора данных (операторы DD)	Через раздел файла и операторы чтения/записи
Обработка ошибок	Коды возврата, выполнение условного шага	Обработчики исключений, процедуры обработки ошибок PERFORM
Портативность	Специфика для IBM z/OS	Переносимость между платформами с помощью компиляторов.
Кто это пишет?	Системные программисты, инженеры пакетной обработки данных	Разработчики приложений
Современный эквивалент	Конвейер CI/CD + оркестрация контейнеров	Код приложения (Java, Python, C++)

Проще всего представить эту взаимосвязь так: JCL — это уровень развертывания и оркестровки; COBOL — это уровень приложений. В современной облачной системе роль JCL выполняют манифесты заданий Kubernetes, сценарии командной оболочки и этапы конвейера CI/CD. Роль COBOL выполняют сервисы приложений, написанные на Java, Python или Go.

Как JCL вызывает COBOL: цепочка выполнения.

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

Шаг 1: Отправка задания. Задание JCL отправляется в подсистему ввода заданий (JES). JES ставит задание в очередь и начинает чтение его инструкций.

Шаг 2: Настройка шага. Для каждого шага EXEC система находит указанную программу в библиотеке загрузки, заданной оператором STEPLIB DD. Если STEPLIB не указан, система выполняет поиск в системной библиотеке компоновки.

Шаг 3: Выделение наборов данных. Перед запуском программы система выделяет все наборы данных, определенные операторами DD на этом шаге. Это включает в себя открытие файлов, проверку существования входных наборов данных и создание выходных наборов данных.

Шаг 4: Выполнение программы. Программа на COBOL выполняется. Она обращается к файлам, используя имена файлов (ddnames), определенные в JCL. OPEN INPUT EMPFILE В COBOL это напрямую соответствует оператору DD с указанным именем. EMPFILE в JCL.

Шаг 5: Возврат результата оценки кода. Когда программа на COBOL завершается, она устанавливает код возврата (обычно 0 — успех, 4 — предупреждение, 8 — ошибка, 12 или 16 — серьезная ошибка). JCL использует COND параметры или IF/THEN/ELSE конструкторы, определяющие, следует ли выполнять последующие шаги на основе этого кода.

Шаг 6: Обработка набора данных. После этого шага система обрабатывает варианты обработки набора данных, определенные в каждом операторе DD: сохранить, удалить, каталогизировать, снять с каталога или передать на следующий шаг.

Следующий пример показывает, как эта цепочка выглядит на практике: JCL слева, соответствующие элементы COBOL справа:

JCL

//STEP020  EXEC PGM=ACCTREC
//STEPLIB  DD   DSN=PROD.ACCOUNT.LOADLIB,DISP=SHR
//INFILE   DD   DSN=PROD.ACCT.DAILY.INPUT,DISP=SHR     ← maps to COBOL SELECT/ASSIGN
//OUTFILE  DD   DSN=PROD.ACCT.PROCESSED,               ← maps to COBOL SELECT/ASSIGN
//              DISP=(NEW,CATLG,DELETE),
//              UNIT=SYSDA,SPACE=(CYL,(5,2),RLSE)
//RPTFILE  DD   SYSOUT=A                                ← maps to COBOL WRITE report
//SYSOUT   DD   SYSOUT=*

Программа COBOL ACCTREC содержит:

кобол

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT INFILE    ASSIGN TO INFILE.         *> maps to DD INFILE
           SELECT OUTFILE   ASSIGN TO OUTFILE.        *> maps to DD OUTFILE
           SELECT RPTFILE   ASSIGN TO RPTFILE.        *> maps to DD RPTFILE

       DATA DIVISION.
       FILE SECTION.
       FD  INFILE
           RECORDING MODE IS F
           BLOCK CONTAINS 0 RECORDS
           RECORD CONTAINS 200 CHARACTERS.
       01  ACCOUNT-RECORD.
           05  ACCT-NUMBER    PIC X(10).
           05  ACCT-BALANCE   PIC S9(13)V99 COMP-3.
           05  ACCT-STATUS    PIC X(2).

SELECT INFILE ASSIGN TO INFILE В разделе FILE-CONTROL COBOL используется оператор DD с именем INFILE В JCL это фундаментальное соотношение отображения: COBOL использует логические имена файлов; JCL преобразует их в физические наборы данных.

Коды аварийного завершения JCL: что они означают.

Коды аварийного завершения JCL (abnormal end codes) указывают на причину неожиданного завершения этапа задания. Они отображаются в выходных данных задания следующим образом: S000 (сбой системы) или U0000 Коды ошибок (авторское завершение). Понимание этих кодов имеет важное значение для диагностики сбоев пакетных заданий.

Код аварийного завершения	Тип	Общая причина
S001	Система	Ошибка ввода-вывода при чтении или записи набора данных.
S013	Система	Несоответствие атрибутов DCB, длина записи или формат между JCL DD и COBOL FD.
S0C4	Система	Исключение защиты хранилища: программа попыталась получить доступ к памяти за пределами выделенной ей области.
S0C7	Система	Ошибка при обработке нечисловых данных (очень распространенная ошибка COBOL).
S322	Система	Превышен лимит времени, выполнение задания заняло больше времени, чем допускал параметр TIME.
S806	Система	Модуль загрузки не найден, программа, указанная в EXEC PGM=, отсутствует в любой из просматриваемых библиотек загрузки.
S913	Система	Нарушение безопасности доступа к набору данных, отказ в доступе по протоколу RACF или аналогичному протоколу.
U0000	Информация о пользователе	Аварийное завершение программы COBOL, определяемое приложением, вызванная программой STOP RUN с пользовательским кодом.
U4076	Информация о пользователе	Аварийное завершение работы, специфичное для IMS, сбой доступа к базе данных.

Наиболее распространённая производственная ошибка, S0C7Ошибка возникает, когда программа на COBOL пытается выполнить арифметические операции над полем, содержащим пробелы или нечисловые символы. Типичная причина — несоответствие между ожидаемым форматом данных в программе COBOL и фактическими данными, предоставляемыми JCL, — именно такое несоответствие выявляет сопоставление JCL и COBOL, прежде чем оно приведет к сбою в работе программы в полночь.

Параметр COND и условное выполнение

JCL управляет выполнением шагов на основе кодов возврата предыдущих шагов, используя COND Параметр:

JCL

//STEP010  EXEC PGM=VALIDATE,COND=(4,LT)
//STEP020  EXEC PGM=PROCESS, COND=(4,LT,STEP010)
//STEP030  EXEC PGM=CLEANUP, COND=(0,NE,STEP010)

COND=(4,LT) Это означает: пропустите этот шаг, если код возврата любого из предыдущих шагов меньше 4. COND=(4,LT,STEP010) Это означает: пропустите этот шаг, если код возврата STEP010 меньше 4. COND=(0,NE,STEP010) Это означает: пропустить STEP030, если код возврата STEP010 не равен 0, то есть выполнить очистку только в том случае, если STEP010 завершился успешно.

Современный JCL использует IF/THEN/ELSE/ENDIF Вместо этого можно использовать более понятную конструкцию:

JCL

//IF010    IF (STEP010.RC = 0) THEN
//STEP020  EXEC PGM=PROCESS
//         ENDIF
//IF020    IF (STEP010.RC > 4) THEN
//STEP030  EXEC PGM=ERRORHANDLER
//         ENDIF

Сопоставление путей выполнения в зависимости от условий является одним из наиболее важных и часто упускаемых из виду элементов анализа JCL-кода в COBOL. Программа на COBOL, которая запускается только при сбое предыдущего шага, может обрабатывать ошибки, логику отката или процедуры восстановления — функциональность, которая совершенно незаметна, если рассматривать только исходный код COBOL без управляющего им JCL-кода.

JCL, COBOL и DB2: трехслойная архитектура.

В большинстве транзакционных систем мэйнфреймов, помимо JCL и COBOL, используется третий компонент: реляционная база данных DB2 от IBM. Программы на COBOL обращаются к DB2 через встроенные SQL-запросы (блоки EXEC SQL). JCL управляет подключением к подсистеме DB2 и модулем запросов к базе данных (DBRM) с помощью специальных операторов DD.

JCL

//DBRM     DD   DSN=PROD.DBRMLIB.DATA(ACCTREC),DISP=SHR
//SYSPRINT DD   SYSOUT=*

кобол

       WORKING-STORAGE SECTION.
       EXEC SQL
           INCLUDE SQLCA
       END-EXEC.

       PROCEDURE DIVISION.
       MAIN-LOGIC.
           EXEC SQL
               SELECT ACCT_BALANCE, ACCT_STATUS
               INTO   :WS-BALANCE, :WS-STATUS
               FROM   ACCOUNT_MASTER
               WHERE  ACCT_NUMBER = :WS-ACCT-NUM
           END-EXEC.

           IF SQLCODE NOT = 0
               PERFORM DB2-ERROR-ROUTINE
           END-IF.

В стеке JCL-COBOL-DB2 JCL обеспечивает среду выполнения и доступ к набору данных; COBOL реализует бизнес-логику и обращается к базе данных; DB2 хранит и извлекает данные в соответствии с SQL-запросами, встроенными в программу COBOL. Полная карта зависимостей любой программы COBOL, использующей DB2, должна включать не только то, какие задания JCL её вызывают, но и то, какие таблицы DB2 она читает и записывает, к каким столбцам она обращается и какие другие программы обращаются к тем же таблицам, поскольку изменение схемы таблицы влияет на каждую программу COBOL, которая на неё ссылается.

Почему сопоставление JCL и COBOL важно для модернизации

Сопоставление JCL и COBOL — это не столько техническая задача, сколько задача управления рисками. Каждое изменение в мэйнфреймной системе, будь то изменение параметра JCL, добавление шага, изменение имени набора данных или модификация программы COBOL, запускаемой заданием, влечет за собой последствия, выходящие за рамки измененного компонента. Единственный способ точно оценить эти последствия до внесения изменений — это иметь полную карту существующего состояния системы и ее взаимосвязи.

Перед миграцией : Перенос пакетных рабочих нагрузок с мэйнфрейма в облако требует знания того, какие задания JCL существуют, какие программы COBOL они вызывают, какие наборы данных передаются между этапами, какова последовательность выполнения и что происходит при сбое этапов. Без этой карты команда миграции работает с неполной документацией или вообще без документации. Этапы могут быть пропущены. Зависимости обнаруживаются в производственной среде. Сроки перехода сдвигаются.

Перед внесением каких-либо изменений в код : программа COBOL, измененная без проверки того, какие задания JCL ее вызывают, может нарушить работу заданий, выполняющихся в разных условиях или с разными конфигурациями наборов данных. Изменение параметра JCL, которое кажется локальным, может повлиять на поведение программы COBOL, зависящей от определенных атрибутов набора данных. Для анализа влияния необходимо знать полную цепочку JCL-COBOL-набор данных до внесения каких-либо изменений.

Для передачи знаний : Когда разработчик COBOL, который двадцать лет поддерживал пакетную систему, уходит на пенсию, он забирает с собой ментальную модель того, как связаны задания JCL и программы COBOL. Документированная схема — единственный механизм для передачи этих знаний следующей команде. Без нее новые разработчики наследуют систему, которую они не смогут безопасно модифицировать.

Для аудита соответствия : Регуляторные проверки часто требуют демонстрации того, что финансовые расчеты, преобразования данных или средства контроля доступа работают в соответствии с документацией. Если связь между JCL и COBOL не задокументирована, продемонстрировать это невозможно без обратного проектирования системы под давлением аудита.

Инструменты управления JCL и платформы анализа

Многоязычный характер данных Search Console для этой статьи, включающих запросы на итальянском, французском, испанском, японском и немецком языках, касающиеся инструментов управления JCL, отражает глобальный характер сообщества ИТ-специалистов по мэйнфреймам и то, как часто команды в каждом регионе сталкиваются с одной и той же проблемой: их документация по JCL и COBOL неполная, устаревшая или отсутствует.

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

Инструменты, разработанные IBM : IBM предлагает средства подсистемы ввода заданий (JOS), управление очередью заданий (JES) и среду выполнения пакетной обработки IBM z/OS. Они обеспечивают выполнение и мониторинг, но не предоставляют возможности анализа или визуализации межпрограммных зависимостей.

Сторонние планировщики заданий : CA7, TWS (Tivoli Workload Scheduler) и Broadcom ESP Workload Automation управляют пакетным планированием тысяч заданий, обеспечивают планирование на основе зависимостей и оповещают о сбоях. Они понимают зависимости на уровне заданий, но, как правило, не анализируют программы COBOL, вызываемые на каждом этапе.

Платформы статического анализа кода и отображения зависимостей : инструменты, которые анализируют исходный код JCL и COBOL для построения структурной модели, показывающей, какие задания вызывают какие программы, какие программы обращаются к каким наборам данных и как данные перемещаются по системе. Они обеспечивают межслойную видимость, недоступную планировщикам заданий и инструментам, разработанным IBM: взаимосвязь между конкретным оператором DD JCL и соответствующей ему записью FILE-CONTROL COBOL, или между программой COBOL, которая записывает данные в набор данных, и следующим заданием, которое считывает этот набор данных в качестве входных данных.

SMART TS XL относится к этой третьей категории и расширяет ее, охватывая все языки программирования в корпоративной среде: COBOL, JCL, PL/I, Assembler, SQL, Java и другие, обеспечивая межъязыковой структурный анализ, который не может предоставить ни один инструмент, использующий только один язык.

Как SMART TS XL Преобразование JCL в COBOL в масштабах предприятия

Ручное сопоставление JCL с COBOL выполнимо для одной задачи, состоящей из трех этапов. Однако это невыполнимо для организации, имеющей 50 000 задач JCL, 200 000 программ COBOL и миллионы ссылок на наборы данных, накопленных за четыре десятилетия. Взаимосвязь между конкретной процедурой PROC, символическими параметрами, используемыми для ее вызова, программами COBOL, к которым эти параметры относятся, и наборами данных, к которым эти программы обращаются, невозможно отследить вручную в таком масштабе.

SMART TS XL Программа анализирует исходный код JCL и COBOL, включая процедуры с символической подстановкой параметров, потоковые процедуры, члены INCLUDE, переопределения и логику условного выполнения, и создает единую модель перекрестных ссылок, представляющую все структурные связи в системе. Эта модель доступна для запросов, навигации и всегда актуальна, поскольку она генерируется из исходного кода, а не поддерживается в виде документа, обновляемого вручную.

Расширение JCL Функция позволяет выполнять подстановку символических параметров, отображая фактические программы и наборы данных, вызываемые любой процедурой PROC, с учетом переопределений, применяемых каждым вызывающим заданием. Процедура PROC, использующая &PGMNAME В качестве символического параметра он отображается в модели как все конкретные программы, на которые он ссылается во всех вызывающих его объектах, а не как неразрешенная ссылка.

Функция сопоставления зависимостей приложений строит полный граф от задания JCL через программу COBOL, через таблицу DB2 и далее через нижестоящую программу, отображая каждый компонент системы и каждую связь между ними. Перед любыми изменениями в процессе модернизации команда может запросить: какие задания вызывают эту программу? Какие наборы данных эта программа считывает? Какие другие программы записывают данные в эти наборы данных? Какие задания выполняются следующими в последовательности?

Функция анализа воздействия генерирует перечень последствий для любого предлагаемого изменения: измените этот файл конфигурации и увидите все программы, которые его включают; измените структуру этого набора данных и увидите все операторы JCL DD, которые на него ссылаются; удалите этот шаг из задания и увидите все последующие шаги, которые зависели от его результатов.

Для команд, сталкивающихся с сопоставлением JCL и COBOL в рамках модернизация наследия программа, SMART TS XL Это обеспечивает основу, необходимую поставщикам услуг по модернизации, таким как Astadia, TSRI, Advanced и другим, до начала любых работ по преобразованию: полный и точный структурный перечень существующего оборудования, чтобы объем работ по преобразованию определялся анализом, а не предположениями.

Карта — это не территория, а отправная точка.

JCL и COBOL никуда не денутся. Пакетные системы, обрабатывающие заработную плату, страховые выплаты, формирующие отчеты для регулирующих органов и осуществляющие финансовые расчеты, будут продолжать работать на мэйнфреймах, пока планируется, утверждается, финансируется и осуществляется миграция в облако — процесс, который обычно занимает годы, а не месяцы. В течение этих лет системы необходимо поддерживать, модифицировать и понимать.

Преобразование JCL в COBOL — это не разовый проект. Это непрерывный процесс: поддержание актуальности структурной модели по мере модификации программ, добавления заданий и реорганизации наборов данных. Команды, которые инвестируют в эту практику, сохраняют возможность уверенно вносить изменения в системы, которые большинство в отрасли рассматривают как «черные ящики». Команды, которые этого не делают, вносят изменения в системы, которые они не могут полностью увидеть, в средах, где пропущенная зависимость не приводит к ошибке компилятора, а вызывает сбой в производственной среде в 3 часа ночи во время ночного пакетного запуска.