Новый разработчик присоединяется к команде мейнфреймов. Она пять лет занималась написанием микросервисов на Java с использованием Git, GitHub, запросов на слияние (pull requests), проверки кода и конвейеров CI/CD. Она знает, как создать ветку разработки, отправить запрос на слияние, отслеживать выполнение автоматизированных тестов, получать обратную связь от коллег и выполнять слияние, когда проверки пройдут успешно. В первый день работы в команде мейнфреймов она осваивает рабочий процесс: открыть ISPF, перейти к исходному PDS, отредактировать элемент напрямую, сохранить его, отправить JCL для компиляции, проверить SYSOUT на наличие ошибок. Нет ветки. Нет истории изменений, кроме той, что указана в порядковых номерах столбцов 1-6. Нет запроса на слияние. Нет автоматизированного контроля тестирования. Если она и ее коллега одновременно редактируют один и тот же элемент, второе сохранение перезаписывает первое без слияния, без предупреждений, без конфликтов, просто с незаметной потерей данных.
Именно этот рабочий процесс призван заменить GitOps для мэйнфреймов. Не платформу z/OS, не язык COBOL, не проверенную обработку транзакций, которую мэйнфрейм обеспечивает с уровнем доступности 99,9 ...
Собирать только затронутые программы
SMART TS XL Определяет каждую программу, содержащую модифицированную копию кода, прежде чем конвейер CI примет решение о том, что компилировать.
УЗНАТЬ БОЛЬШЕ…Что на самом деле означает GitOps для мейнфреймов?
GitOps — это операционная модель, в которой Git является единственным источником достоверной информации как о коде приложения, так и о конфигурации инфраструктуры. Каждое изменение в системе, коде, конфигурации или определении развертывания осуществляется посредством коммита Git. Репозиторий Git является авторитетным источником информации; работающая система согласовывается с тем, что, по утверждению Git, она должна содержать.
В случае мэйнфреймов это выражается в конкретном наборе обязательств:
Git является авторитетным источником исходного кода COBOL. Библиотека PDS на z/OS — это артефакт развертывания, то, что скомпилировано и работает в производственной среде, а не источник истины. Источником истины является репозиторий Git. Если PDS и репозиторий Git не совпадают, то Git является правильным.
Каждое изменение проходит через pull request. Никаких прямых правок PDS. Никакой экстренной компиляции и продвижения вне рабочего процесса Git. Изменение, необходимое немедленно, проходит через ускоренный PR, возможно, с уменьшенными требованиями к проверке в случае настоящей чрезвычайной ситуации, но оно проходит через Git.
Автоматизированные конвейеры обрабатывают сборку и продвижение. Разработчик объединяет свой запрос на слияние (PR); конвейер компилирует затронутые программы, запускает автоматизированные тесты и продвигает скомпилированные модули загрузки в соответствующую библиотеку. Разработчику не нужно вручную отправлять JCL-файлы для компиляции.
История коммитов Git — это аудиторский след. Каждое изменение в продакшене можно отследить до конкретного коммита, конкретного автора, конкретного запроса на слияние и, если используется рабочий процесс обработки запросов на слияние, до конкретного набора рецензентов и результатов тестирования.
Это существенное изменение рабочего процесса для команд, привыкших к разработке на основе ISPF. Кроме того, всё чаще именно такой рабочий процесс необходим организациям для преодоления дефицита квалифицированных кадров: новые разработчики, знающие только Git, могут участвовать в разработке на COBOL, не изучая соглашения по управлению библиотеками ISPF.
Технические сложности: о чем не рассказывается ни в одной другой статье.
Перенос исходного кода COBOL в Git — задача не из простых, как создание репозитория и копирование файлов. Четыре специфические технические проблемы z/OS усложняют миграцию:
1. Кодировка EBCDIC против UTF-8
В z/OS символьные данные хранятся в кодировке EBCDIC (Extended Binary Coded Decimal Interchange Code), тогда как в Git файлы хранятся в UTF-8. Каждый файл, перемещаемый между мэйнфреймом и репозиторием Git, должен быть перекодирован. Если перекодирование выполняется некорректно, если предполагается неправильная кодовая страница, если преобразование выполняется непоследовательно или если файлы передаются без преобразования, исходный код COBOL незаметно повреждается.
z/OS Unix System Services (USS) выступает в роли связующего звена: исходный код COBOL в PDS преобразуется в UTF-8 при записи в файловую систему USS, где Git может с ним работать. Когда репозиторий Git клонируется в USS, файлы помечаются своей кодировкой, чтобы инструменты z/OS знали, как их интерпретировать.
колотить
# z/OS USS: correctly tag a Git-managed COBOL source file
chtag -t -c IBM-1047 CUSTPROC.cbl
# Verify the tag
ls -T CUSTPROC.cbl
# Output: t IBM-1047 T=on CUSTPROC.cbl
# The Git checkout hook should apply this automatically
# so developers don't have to tag files manually2. Семантика источника и столбцов фиксированного формата
Исходные файлы COBOL используют структуру фиксированного формата с семантикой, специфичной для каждого столбца:
Columns 1-6: Sequence numbers (optional; ISPF editors fill these automatically)
Column 7: Indicator (* = comment, - = continuation, D = debug line)
Columns 8-11: Area A (division/section/paragraph names, level numbers 01/77)
Columns 12-72: Area B (executable statements, clauses)
Columns 73-80: Identification (program name, historically used for card identification)При сравнении изменений в исходном коде COBOL с помощью Git, отображающем изменения в столбцах 73-80, обычно показываются изменения порядковых номеров или полей идентификации, а не функциональные изменения кода. Инструмент сравнения, не понимающий семантику этих столбцов, создает шум, скрывающий реальные изменения. Конфигурация Git для репозитория COBOL должна включать в себя .gitattributes который связывает файлы COBOL с драйвером сравнения, удаляющим или игнорирующим поле идентификации:
ини
# .gitattributes: configure COBOL-aware diff
*.cbl diff=cobol
*.cob diff=cobol
*.cpy diff=cobol
# .gitconfig (or repo-level config): define the cobol diff driver
[diff "cobol"]
xfuncname = "^[0-9A-Z][0-9A-Z -]+"
wordRegex = "[A-Z][A-Z0-9-]+"3. Ограничения на имена элементов PDS
Имена участников PDS ограничены 8 символами, написаны заглавными буквами, цифрами и т.д. $, #, @В Git имя файла — это имя члена PDS (без расширения или со стандартным расширением). .cbl (Расширение добавлено по соглашению). Ограничение в 8 символов создает ограничение на именование: CUSTUPDT однозначно соответствует элементу PDS; customer-account-update-processor не.
На практике работает следующее соглашение: имена членов сохраняются в качестве базового имени файла (8 символов), к нему добавляется .cbl Расширение в Git для идентификации исходного кода и использование структуры каталогов в Git для предоставления пространства имен, которое невозможно указать с помощью именования PDS:
repository/
├── CUSTMGMT/ # Logical application group (no PDS equivalent)
│ ├── CUSTUPDT.cbl # Maps to PDS member CUSTUPDT
│ ├── CUSTINQ.cbl
│ └── CUSTSRCH.cbl
├── COPYBOOKS/
│ ├── CUSTMSTR.cpy # Maps to PDS member CUSTMSTR
│ └── TRANREC.cpy
└── JCL/
├── CUSTNITE.jcl
└── CUSTMON.jcl4. Проблема авторитетного источника
В процессе перехода от разработки на основе PDS к разработке на основе Git, и PDS, и Git содержат копии исходного кода. Какой из них является авторитетным? Ответ должен быть однозначным, прежде чем вносить какие-либо изменения в производственную среду в рамках нового рабочего процесса.
(cite index=”42-1″>Какая система содержит авторитетный источник: Git, менеджер библиотек или результат, сгенерированный процессом синхронизации? Когда ответ неясен, команды тратят время на разрешение разногласий между системами, а не на создание ценности. Модель, ориентированная на Git, дает более ясный ответ. Git содержит авторитетный источник и записывает его историю. Конвейер использует этот источник для создания протестированных, отслеживаемых артефактов для развертывания.
Переходная последовательность, устраняющая эту неопределенность: установить репозиторий Git в качестве авторитетного источника на определенную дату; после этой даты любое изменение в PDS будет считаться нарушением политики, которое должно быть передано на рассмотрение и перенесено в Git до конца рабочего дня; для экстренных исправлений будет предусмотрен специальный ускоренный процесс запроса на слияние, а не исключение для изменений в PDS. Переходный период, в течение которого поддерживаются обе системы, должен быть как можно короче с точки зрения оперативной эффективности, поскольку каждый день поддержки двух источников — это день потенциального расхождения.
Набор инструментов GitOps для мэйнфреймов
Четыре категории инструментов обеспечивают связь Git с конвейером доставки z/OS:
Управление исходным кодом и IDE: IBM Developer for z/OS (IDz) предоставляет традиционную IDE на основе Eclipse с редактированием в стиле ISPF и интеграцией с Git. В качестве альтернативы, VS Code с расширением Zowe Explorer предоставляет современную IDE, которая подключается к z/OS через API-фреймворк Zowe без необходимости использования IDz. Команды, которые хотят привлечь разработчиков, знакомых с современными инструментами, обычно предпочитают VS Code.
Фреймворк Zowe: Zowe — это фреймворк с открытым исходным кодом, предоставляющий REST API для z/OS, обеспечивающий доступ к операциям с наборами данных, отправке заданий и файлам USS через стандартизированные HTTP-интерфейсы, которые могут вызывать стандартные инструменты CI/CD. Без Zowe (или коммерческого аналога) нет стандартного способа взаимодействия раннера GitHub Actions или агента Jenkins с z/OS.
IBM Dependency Based Build (DBB): DBB — это инструмент сборки, предоставляемый IBM специально для GitOps на мэйнфреймах. Он понимает зависимости компиляции COBOL, какие копибуки включает каждая программа, какие DBD и PSB требуются для программ IMS, какие BIND необходимы для Db2, и использует это понимание зависимостей для определения того, что должно быть скомпилировано при изменении заданного набора файлов.
Управление изменениями и развертывание: ISPW (CA Brightside), UrbanCode Deploy и Rocket Software ISPW обеспечивают управление продвижением, которое перемещает скомпилированные загрузочные модули из библиотек разработки через тестовые среды в производственную среду, с рабочими процессами утверждения и журналами аудита, необходимыми в регулируемых средах.
| Слой цепочки инструментов | Открытый исходный код / Вариант от IBM | Коммерческая альтернатива |
|---|---|---|
| IDE | VS Code + Zowe Explorer | IBM IDz, Broadcom IDz |
| мост API z/OS | Zowe CLI + API-слой | Rocket ConnectZen, CA Brightside |
| Создание оркестровки | IBM DBB | BMC Compuware Topaz Workbench |
| CI/CD runner | Дженкинс, действия GitHub | Azure DevOps, GitLab CI |
| Управление изменениями | Zowe + DBB развертывание | ISPW, UrbanCode Deploy |
| Продвижение источника | Слияние Git с основной веткой | Рабочий процесс продвижения ISPW |
Процесс производства: от PR до выпуска продукции.
Комплексный конвейер GitOps для внесения изменений в COBOL охватывает распределенную платформу CI/CD и среду выполнения z/OS:
YAML
# GitHub Actions: COBOL GitOps pipeline
name: Mainframe COBOL Pipeline
on:
pull_request:
paths:
- '**/*.cbl'
- '**/*.cpy'
- '**/*.jcl'
jobs:
impact-analysis:
runs-on: ubuntu-latest
outputs:
affected: ${{ steps.analyze.outputs.affected_programs }}
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Identify changed files
id: changes
run: |
CHANGED=$(git diff --name-only origin/main...HEAD \
| grep -E '\.(cbl|cpy|jcl)$')
echo "changed=$CHANGED" >> $GITHUB_OUTPUT
- name: Analyze dependency scope
id: analyze
# SMART TS XL or DBB dependency analysis determines
# which programs are affected by the changed files
run: |
echo "Resolving dependency scope for: ${{ steps.changes.outputs.changed }}"
# Output: the specific programs that must be compiled/tested
compile-and-test:
needs: impact-analysis
runs-on: [self-hosted, zos-runner] # Runner with z/OS connectivity
steps:
- uses: actions/checkout@v4
- name: Compile affected COBOL programs (via Zowe + DBB)
run: |
zowe dbb build \
--sourceDir ./CUSTMGMT \
--affected "${{ needs.impact-analysis.outputs.affected }}" \
--workDir /u/devops/builds/${{ github.run_id }}
- name: Run unit tests
run: |
zowe zunit run \
--programs "${{ needs.impact-analysis.outputs.affected }}" \
--results-dir /u/devops/results/${{ github.run_id }}
- name: Static compliance check (before promotion)
run: |
# Hardcoded credential check, FILE STATUS validation,
# naming convention compliance
zowe smart-ts-xl analyze \
--scope "${{ needs.impact-analysis.outputs.affected }}"
promote-to-test:
needs: compile-and-test
if: github.event_name == 'pull_request' && github.base_ref == 'main'
runs-on: [self-hosted, zos-runner]
steps:
- name: Promote to TEST library (via ISPW)
run: |
zowe ispw promote \
--programs "${{ needs.compile-and-test.outputs.compiled }}" \
--from DEV --to TEST \
--change-request ${{ github.event.pull_request.number }}Ключевым элементом этого конвейера является этап анализа влияния: определение того, какие программы на COBOL должны быть скомпилированы и протестированы при внесении изменений в определенный набор исходных файлов в рамках запроса на слияние (PR). Без этого этапа конвейер либо компилирует все (медленно и затратно), либо компилирует только явно измененные файлы (отсутствуют программы, зависящие от измененных копибуков).
Разрыв в зависимостях: почему анализ воздействия — самая сложная часть.
Git точно знает, какие файлы были изменены в запросе на слияние. Чего Git не знает, так это того, какие другие программы затронуты этими изменениями.
Запрос на изменение, который модифицирует CUSTMSTR.cpyДокумент, определяющий структуру основной записи клиента, ничего не меняет в плане количества файлов: был отредактирован один файл. Но CUSTMSTR.cpy Этот файл включен в 47 программ COBOL. Все 47 программ необходимо перекомпилировать. Если компилируется только явно измененный файл, 46 программ остаются в рабочем режиме с определением копибука, которое больше не соответствует их скомпилированному двоичному файлу. Несоответствие остается незамеченным до тех пор, пока программа не запустится и не попытается прочитать запись, используя старую структуру данных, в сравнении с данными, записанными с использованием новой структуры.
Это и есть проблема с зависимостями в GitOps для мэйнфреймов: система сборки должна знать граф зависимостей, чтобы определить правильную область компиляции. IBM DBB решает эту проблему для вновь созданных репозиториев, создавая явную карту зависимостей в рамках процесса сборки. Для устаревших сред, где тысячи программ существовали до DBB, первоначальная карта зависимостей должна быть построена на основе статического анализа существующего исходного кода.
Четыре типа зависимостей, которые имеют значение для области видимости сборки COBOL:
Операторы COPY — наиболее часто используемая зависимость. Изменение любого файла копирования, включенного с помощью COPY, требует перекомпиляции каждой программы, которая его использует.
Операторы CALL — статические вызовы подпрограмм. Если интерфейс вызываемой программы изменяется (параметры, коды возврата), может потребоваться обновление и перекомпиляция вызывающих функций.
SQL INCLUDE — это встроенные SQL-программы, включающие члены DCLGEN (генераторы классов данных для таблиц Db2). Изменение схемы Db2, генерирующее новый DCLGEN, требует перекомпиляции каждой программы, которая его включает.
Изменения в JCL, которые ссылаются на разные наборы данных или используют разные имена программ, влияют на операционный конвейер, а не только на компиляцию программы.
Старый рабочий процесс против рабочего процесса Git
| Аспект | Рабочий процесс на основе ISPF PDS | Рабочий процесс GitOps на основе Git |
|---|---|---|
| Источник правды | Библиотека PDS на z/OS | Репозиторий Git |
| Механизм редактирования | Редактор ISPF, прямой участник PDS (редактирование). | VS Code / IDz с интеграцией Git |
| Отслеживание изменений | Порядковые номера в столбцах 1-6 | История коммитов Git с указанием автора, временной метки и сообщения. |
| Одновременное редактирование | Второе сохранение перезаписывает первое (скрытая потеря). | Разработка на основе ветвей; обнаружение конфликтов слияния. |
| Обзор кода | Неформальная обстановка, можно подойти к столу. | Запрос на слияние с структурированным обзором и утверждением |
| Триггер сборки | Ручная отправка JCL | Автоматизируется с помощью конвейера обработки запросов на слияние или при слиянии. |
| Расчет зоны воздействия | Ручные знания; перестроить все по умолчанию. | Анализ зависимостей определяет затронутые программы. |
| Аудиторский след | Журнал ручных изменений; неполный | Журнал Git + метаданные запроса на слияние; полные и доступные для запросов. |
| Привлечение новых разработчиков | Требуется обучение по ISPF. | Стандартная процедура адаптации пользователей Git; современная IDE. |
| Экстренные изменения | Прямое редактирование PDS; часто без отслеживания. | Ускоренный процесс обработки запросов на связи; полное отслеживание. |
В нижнем ряду сосредоточены операционные риски рабочего процесса ISPF: экстренные изменения, внесенные непосредственно в производственные PDS, в обход процесса управления изменениями, являются наиболее частым источником неотслеживаемых производственных изменений и наиболее частым результатом проверок при управлении изменениями на мэйнфреймах.
Как SMART TS XL Обеспечивает точную работу GitOps на мэйнфреймах.
Проблема разрыва в зависимостях в GitOps на мэйнфреймах, разрыв между «Git знает, что изменилось» и «конвейер знает, что нужно скомпилировать», решается с помощью статического анализа исходного кода COBOL, который формирует граф зависимостей.
SMART TS XLАвтора сопоставление зависимостей приложения Создает полный граф зависимостей COPY: каждый копибук, каждая программа, которая его включает, каждое вложенное отношение COPY и каждая зависимость CALL по всему портфолио. Когда запрос на изменение вносит изменения CUSTMSTR.cpyКарта зависимостей немедленно выдает список из 47 программ, которые ее включают, предоставляя входные данные для области сборки, необходимые конвейеру CI для компиляции правильного набора программ, и ничего больше.
Эта карта зависимостей также обеспечивает безопасность перехода к разработке с использованием Git: прежде чем установить репозиторий Git в качестве авторитетного источника, необходимо знать полный граф зависимостей, чтобы исходная структура репозитория отражала фактические отношения зависимостей между программами и копибуками. Структура репозитория, которая отделяет копибуки от программ, которые их включают, без документирования отношений зависимостей, создает репозиторий, который корректно компилируется только в том случае, если вам известно, от чего зависит каждый компонент, что противоречит цели контроля версий.
Функция статического анализа кода обеспечивает логику проверки перед фиксацией изменений: проверку измененных программ на наличие жестко закодированных учетных данных, отсутствующих объявлений FILE STATUS, соответствие соглашениям об именовании и другие статические проверки качества, которые в рабочем процессе Git выполняются как проверки при запросе на слияние, а не как результаты после развертывания.
Функция анализа влияния отвечает на вопрос, задаваемый при рассмотрении запроса на изменение: «Каков полный масштаб этого изменения?» Запрос на изменение, вносящий изменения в структуру кода, имеет область влияния, которая распространяется на каждую программу, включающую его, и на каждое задание JCL, запускающее эти программы. Видимость этой области влияния в контексте рассмотрения запроса на изменение до его слияния позволяет принимать обоснованные решения, определять область тестирования и устанавливать соответствующие уровни одобрения консультативного совета по изменениям.
поиск на предприятии Эта функция поддерживает требование к журналу аудита: поиск всех изменений в конкретной программе в заданном диапазоне дат (запрос из журнала Git), каждой программы, включающей определенную копибук-теку (запрос из карты зависимостей), каждой программы, измененной конкретным автором (запрос из Git). Сочетание истории коммитов Git и SMART TS XLПроведенный структурный анализ позволяет получить полный, доступный для запросов аудиторский след, необходимый группам по обеспечению соответствия требованиям и консультативным советам по изменениям.
Репозиторий должен знать то, что знает код.
Разработчик, присоединившийся к команде, работающей с мейнфреймами, имея пятилетний опыт работы с Git, не просит мейнфрейм стать облачной платформой. Она просит его поддерживать рабочие процессы, используемые каждой современной командой разработчиков: контроль версий, проверка кода, автоматизированное тестирование, отслеживаемость. Эти рабочие процессы существуют по причинам, которые в равной степени применимы как к COBOL, так и к Java: предотвращение перезаписи при двойном редактировании, создание проверяемой истории каждого изменения в производственной среде, обеспечение возможности проверки кода перед развертыванием и автоматизация механической работы, чтобы разработчики могли сосредоточиться на основной задаче.
Технические проблемы реальны: кодировка EBCDIC, соглашения об использовании фиксированного формата исходного кода, ограничения на именование PDS, вопрос об авторитетности исходного кода. Ни одна из них не является неразрешимой. Инструментарий Zowe, DBB, VS Code с Zowe Explorer, платформы управления изменениями, решает большинство из них. Остается лишь анализ зависимостей, который позволяет конвейеру сборки правильно определять область действия при изменении общего компонента.
Мейнфрейм, управляющий исходным кодом в Git, выполняющий сборку через конвейер CI/CD и развертывающий приложения с помощью автоматизированного процесса продвижения, — это не другой мейнфрейм. Это тот же самый мейнфрейм, работающий на тех же проверенных программах COBOL, с той же надежностью в пять девяток, и теперь это мейнфрейм, к которому разработчик с пятилетним опытом работы с современными инструментами может присоединиться и начать продуктивно работать уже к концу первой недели.
