Две организации со схожим объемом портфелей COBOL-приложений принимают разные решения по модернизации. Одна переходит на новую платформу: переносит COBOL-программы на облачную инфраструктуру, используя AWS Mainframe Modernization или слой эмуляции COBOL, сохраняя код и одновременно отказываясь от физического мэйнфрейма. В течение восемнадцати месяцев они сокращают затраты на инфраструктуру на 40%, и программа считается успешной. Другая организация, попытавшись применить тот же подход, сталкивается с трудностями через двенадцать месяцев и переходит к реархитектуре, перестраивая наиболее важные программы в виде микросервисов на Java. Этот переход обходится вдвое дороже первоначального бюджета и занимает еще три года.
Отправная точка та же. Результаты кардинально разные. Разница заключалась не в инструментах, поставщиках или командах. Дело в том, что вторая организация выбрала переход на новую платформу для систем, имевших архитектурные ограничения, которые новая платформа не могла обеспечить, зависимости от транзакций CICS, структуры файлов VSAM и требования к работе в реальном времени, которые перенесенный код не мог удовлетворить без фундаментальной переработки. Решение было принято до того, как кто-либо достаточно хорошо понял системы, чтобы правильно его реализовать.
Выявляйте препятствия для перепроектирования на ранней стадии.
SMART TS XL Автоматически определяет глубину связи CICS, сложность VSAM и мертвый код во всем вашем портфеле COBOL.
ПодробнееЧто на самом деле означает каждый из этих путей для COBOL
Общие определения хорошо известны. Важно то, что каждый путь означает конкретно для программ на COBOL, где архитектура, модель выполнения и структуры данных отличаются от современных приложений таким образом, что это напрямую влияет на то, какой путь является жизнеспособным.
Перенос платформы COBOL
Перенос программ на новую платформу означает их размещение в новой операционной среде, как правило, в облачной инфраструктуре, при этом код остается практически неизменным. COBOL-программы компилируются и запускаются на новой платформе либо нативно (с использованием компилятора COBOL от IBM в Linux), либо через слой эмуляции, который перехватывает вызовы, специфичные для мэйнфреймов (CICS, VSAM, JES), и преобразует их в эквиваленты, характерные для облачных вычислений.
Что сохраняется при переходе на новую платформу:
- Исходный код COBOL
- Логика, вычисления и бизнес-правила программы
- Модель пакетного выполнения (циклы PERFORM, последовательная обработка файлов)
- Структуры данных (структура записей, определения копибуков)
- Структура задания JCL (переписана для нового планировщика, но логически эквивалентна)
Какие изменения произойдут при переходе на новую платформу:
- Физическая инфраструктура (z/OS → Linux в облаке)
- Подсистема ввода-вывода (VSAM → управляемое файловое хранилище или база данных, в зависимости от инструмента)
- Планировщик заданий (JES2/JES3 → AWS Batch, Azure Logic Apps или аналогичный)
- Модель ценообразования (биллинг на основе MIPS → облачный биллинг на основе потребления)
Главный вывод: перенос платформы правилен, когда проблема заключается в самой платформе, стоимости запуска z/OS, зависимости от инфраструктуры или модели выставления счетов MIPS. Это неправильный путь, когда проблема заключается в коде или архитектуре.
Перепроектирование COBOL
Реархитектура меняет фундаментальную структуру системы. Бизнес-логика сохраняется или переписывается из исходного кода COBOL, но реализуется на новом языке, с новой моделью выполнения и на новом уровне данных. В результате получается система, которая делает то же, что и COBOL, но не похожа на COBOL по структуре.
Какие изменения вносит реархитектура:
- Язык программирования (COBOL → Java, Python, Go, C#)
- Модель выполнения (пакетная → событийно-ориентированная, потоковая или на основе API)
- Уровень данных (файлы VSAM → реляционная база данных, NoSQL, облачное хранилище)
- Транзакционная модель (псевдодиалоговая модель CICS → RESTful-сервисы без сохранения состояния)
- Схема интеграции (общие наборы данных → контракты API, очереди сообщений)
Что необходимо сохранить при реархитектурном перепроектировании:
- В COBOL реализованы все бизнес-правила, включая недокументированные крайние случаи.
- Каждое вычисление, включая характеристики точности численных данных упакованной десятичной арифметики.
- Все преобразования данных, включая неявные преобразования в операторах MOVE.
- Все условия возникновения ошибок, включая конкретные коды состояния файла и поведение при завершении работы, от которых могут зависеть нижестоящие системы.
Внимание: наиболее распространенная ошибка при перепроектировании заключается в обнаружении того, что COBOL-код содержал бизнес-правила, которые нигде больше не были записаны. Новая система ведет себя иначе, чем старая, в определенных крайних случаях, не из-за ошибок реализации, а из-за неполноты спецификации. Бизнес-логику необходимо извлечь и задокументировать из исходного кода COBOL до начала перепроектирования.
Факторы, специфичные для COBOL, влияющие на это решение.
В стандартных подходах к модернизации смена платформы и перепроектирование рассматриваются в первую очередь как решения, касающиеся стоимости, сроков и рисков. В случае с COBOL ряд технических факторов, специфичных для языка и его среды выполнения, существенно влияют на принятие решения в ту или иную сторону.
Зависимости транзакций CICS
CICS (Customer Information Control System) — это промежуточное программное обеспечение для обработки транзакций, которое многие программы на COBOL используют для интерактивных рабочих нагрузок. Программа на COBOL, выполняющая вызовы EXEC CICS, имеет неявную зависимость от сервера транзакций CICS для управления экраном, связи с терминалом, распределения задач и управления программой.
Последствия перехода на другую платформу: такие инструменты, как эмуляция CICS от Micro Focus, OpenFrame и некоторые функции модернизации мэйнфреймов AWS, эмулируют семантику CICS. Если использование CICS стандартное и корректное, эмуляция может работать. Если же программа зависит от внутренних механизмов CICS, манипуляций с областью соединения, управления точками синхронизации, хранения данных на уровне задач, точность эмуляции снижается.
Последствия изменения архитектуры: программа CICS, преобразованная в REST API, должна иметь переработанную псевдодиалоговую модель транзакций, предусматривающую взаимодействие без сохранения состояния. Это изменение архитектуры, а не перевод кода.
Признаки, указывающие на необходимость перепроектирования: интенсивное использование CICS со сложной обработкой областей общего доступа, цепочками транзакций на бэкэнде или логикой точек синхронизации.
Архитектура файлов VSAM
VSAM (Virtual Storage Access Method) — это индексированная файловая система, используемая большинством программ на COBOL, применяемых в производственных системах. Файлы VSAM имеют специфические шаблоны доступа: KSDS с последовательным доступом по ключу, ESDS с последовательным доступом по записи и RRDS с относительными записями, которые не имеют прямых аналогов в облачных хранилищах.
Последствия перехода на новую платформу: слои эмуляции преобразуют операции чтения и записи VSAM в операции с файлами или базами данных. Для простого последовательного доступа или доступа по ключу это работает. Для сложного доступа по альтернативным ключам, кластеров VSAM, используемых несколькими программами, или чувствительных к производительности шаблонов произвольного доступа эмуляция добавляет задержку и сложность.
Последствия для архитектуры: замена VSAM на реляционную базу данных требует сопоставления структуры записей со схемами таблиц, обработки неявных преобразований типов данных и переписывания всех обращений к файлам с использованием SQL или ORM.
Намечается тенденция к перепроектированию архитектуры: использование VSAM-файлов несколькими программами, альтернативные схемы доступа к индексам или требования к производительности в реальном времени, которые эмуляция не может удовлетворить.
Требования к пакетной обработке и обработке в реальном времени
Пакетные программы на COBOL предназначены для последовательной обработки больших объемов записей в запланированные временные окна. Многие банковские, страховые и государственные системы до сих пор запускают пакетные задания в ночное время, которые обрабатывают миллионы транзакций, формируют отчеты и обновляют основные файлы.
Последствия смены платформы: Семантика пакетной обработки хорошо переносится на облачные пакетные задания (AWS Batch, Azure Batch). Модель последовательной обработки сохраняется при смене платформы. Если требуется просто запустить то же самое пакетное задание на более дешевой инфраструктуре, смена платформы решает эту задачу напрямую.
Последствия изменения архитектуры: если бизнес-требования изменились — от пакетной обработки в ночное время к обработке в режиме, близком к реальному времени, от обмена файлами к интеграции API, от монолитных пакетных запусков к микросервисам, запускаемым по отдельности, — то смена платформы не сможет удовлетворить новые требования. Архитектура должна измениться.
Направления на перепроектирование: требования заинтересованных сторон к обработке в реальном времени, интеграции на основе API, архитектуре, управляемой событиями, или времени отклика менее секунды, которые не может обеспечить пакетная обработка.
Встроенная бизнес-логика без внешних спецификаций
Это наиболее недооцененный фактор, специфичный для COBOL. Основные риски включают потерю критически важных бизнес-правил, заложенных в коде, которому уже несколько десятилетий, и недостаточную документацию поведения системы. Программы на COBOL часто содержат единственную сохранившуюся спецификацию бизнес-правила. Нормативный акт, требующий выполнения конкретного вычисления, был написан в 1983 году. Бизнес-аналитик, который его понимал, вышел на пенсию в 2001 году. Код COBOL — это не просто реализация, это и есть документация.
Последствия переноса на новую платформу: бизнес-правила остаются неизменными, поскольку код сохраняется. Это один из самых веских аргументов в пользу переноса на новую платформу.
Последствия для реархитектуры: бизнес-правила необходимо извлечь из исходного кода COBOL перед его повторной реализацией. <cite index=”28-1″>Недокументированный, тесно связанный код многократно увеличивает трудозатраты на каждом этапе.</cite> Если это извлечение неполное, новая система будет иметь другую спецификацию, чем старая, и эти различия проявятся в производственной среде.
Структура принятия решений: восемь вопросов
Прежде чем выбрать путь, эти восемь вопросов помогут собрать необходимые доказательства, чтобы принять решение с уверенностью, а не на основе предположений.
1. Что является основной движущей силой этой модернизации?
- Затраты на инфраструктуру → достаточное количество средств на переплатформе.
- Зависимость от платформы (z/OS) → достаточно переплатформы.
- Требования к работе в реальном времени → требуется реархитектор
- Требования к интеграции (API) → вероятно, потребуется перепроектирование.
- Поддерживаемость / доступность талантов → перепроектирование или рефакторинг
2. Каков уровень связи CICS? Перечислите все вызовы EXEC CICS. Подсчитайте программы, содержащие более двадцати различных команд CICS. Программы с высокой степенью связи CICS плохо подходят для переноса на другую платформу, если точность эмуляции вызывает сомнения.
3. Какие существуют шаблоны доступа к VSAM-файлам? Выявите программы, обращающиеся к VSAM-файлам с использованием альтернативных ключей, общих кластеров или произвольного доступа, критически важного для производительности. Это индикаторы риска перехода на новую платформу.
4. Была ли бизнес-логика задокументирована извне? Если исходный код COBOL является единственной авторитетной спецификацией, то перепроектирование архитектуры требует извлечения бизнес-логики в качестве предварительного шага, а не параллельной обработки.
5. Каков допустимый диапазон пакетной обработки? Если бизнесу требуется та же модель пакетной обработки по более низкой цене, следует перейти на другую платформу. Если бизнесу требуется, чтобы та же обработка была доступна в режиме реального времени, следует выбрать другого архитектора.
6. Какова сложность зависимостей? Программа с пятьюдесятью зависимостями, наборами данных, называемыми подпрограммами, вызывающими JCL-скрипты, несет более высокий риск перепроектирования, чем автономная утилита. Структура зависимостей определяет последовательность миграции и область тестирования.
7. Какой процент кода является неиспользуемым? Исключение неиспользуемого кода из объема работ до преобразования снижает трудозатраты по обоим направлениям. В программах, разработанных с учетом потребностей нового архитектора, неиспользуемый код преобразуется с полной оплатой, а затем отбрасывается.
8. Каково распределение сложности? Цикломатическая сложность выше 50 на программу или более двадцати включенных копибуков указывает на программы, требующие дорогостоящего перепроектирования и рискованного переноса на другую платформу. Такие программы заслуживают индивидуального внимания, а не массового назначения путей.
Применение данной структуры: четыре системных профиля COBOL
| Профиль | Характеристики: | Рекомендуемый путь | обоснование |
|---|---|---|---|
| Стабильная пакетная утилита | Последовательный файловый ввод-вывод, отсутствие CICS, хорошо документированная логика, низкая сложность. | Реплатформа | Проблема заключается в стоимости платформы; код не является ограничивающим фактором. |
| Онлайн-транзакции с большим количеством операций CICS | Интенсивное использование EXEC CICS, зависимости от общих областей, псевдодиалоговая модель. | Реархитектор | Риск эмуляции CICS высок; вероятны требования к работе в режиме реального времени. |
| VSAM главный файловый процессор | Сложные схемы доступа к VSAM, используемые во многих программах, большой объем чтения. | Сначала оцените качество эмуляции; если качество эмуляции останется хорошим, перейдите на другую платформу. | Эмуляция VSAM является переменной, определяющей решение. |
| Бизнес-логика казначейства | Недокументированные правила, отсутствие внешних спецификаций, высокая нормативно-правовая значимость. | Сначала извлеките логику, затем выберите | Риск перепроектирования недопустим без предварительного извлечения бизнес-логики. |
Главный вывод: <cite index=”30-1″>На практике в крупных проектах сочетаются различные подходы: перенос стабильных частей на новые платформы, рефакторинг сложного в поддержке кода, переписывание нескольких систем, нуждающихся в новых возможностях, и вывод из эксплуатации того, что больше не используется.</cite> Решение принимается не на уровне портфеля, а на уровне рабочей нагрузки, и применяется индивидуально к каждой программе или группе программ на основе имеющихся данных.
Гибридный подход: сначала переработка платформы, затем перепроектирование там, где это необходимо.
Практическое правило: чтобы быстро остановить утечку ресурсов, необходимо перенести систему на другую платформу или перевести её на новый сервер, а затем переработать или перепроектировать системы, которые действительно являются конкурентными преимуществами.
Для большинства организаций с большим портфелем проектов на COBOL практическая последовательность действий следующая:
Этап 1. Перевод на новую платформу перспективных проектов. Программы без CICS, с простым последовательным вводом-выводом, документированной логикой и низкой сложностью могут быть переведены на новую платформу с предсказуемыми затратами усилий и рисками. Это обеспечивает быстрое снижение затрат на инфраструктуру и укрепляет уверенность организации.
Этап 2. Оценка сложных программ. Программы с привязкой к CICS, сложными шаблонами VSAM или недокументированной бизнес-логикой требуют индивидуального анализа, прежде чем будет выбран путь решения. На этом этапе извлечение бизнес-логики и структурный анализ определяют необходимость пересмотра архитектуры и его объем.
Этап 3, перепроектирование программ с учетом архитектурных препятствий. Программы, которые не могут удовлетворить бизнес-требования на обновленной инфраструктуре, требованиям реального времени, интеграции API, обработке событий, перепроектируются с использованием шаблона Strangler Fig: создание нового сервиса параллельно с обновленной программой, поэтапная маршрутизация трафика к новой реализации по мере проверки каждого компонента и вывод старой программы из эксплуатации после миграции всего трафика.
Этап 4, вывод из эксплуатации устаревшего кода. Программы, признанные устаревшими в ходе структурного анализа, исключаются из обоих путей и выводятся из эксплуатации, что снижает текущие затраты на техническое обслуживание без каких-либо усилий по преобразованию.
Какие результаты должен дать анализ, прежде чем будет принято какое-либо решение?
Предложенная выше схема принятия решений дает более точные результаты, когда в качестве входных данных используются фактические данные, а не оценки. Структурный анализ, обеспечивающий эти данные, требует разбора исходного кода COBOL, а не опоры на документацию или знания разработчиков.
Что должен установить анализ для каждой программы:
Полный перечень программ, включая те, которые не описаны в документации. В больших средах COBOL количество недокументированных программ часто превышает 20% от общего числа. Граф зависимостей, показывающий, какие программы вызывают другие, какие наборы данных используются совместно, какие задания JCL вызывают какие программы. Перечень команд CICS для каждой программы: количество, типы и сложность вызовов. Анализ шаблонов доступа VSAM: какие методы доступа используются, какие файлы используются совместно различными программами, какие файлы имеют альтернативные индексы. Распределение цикломатической сложности: какие программы имеют простую структуру, а какие являются кандидатами с высоким риском преобразования. Идентификация мертвого кода: какие программы и абзацы не имеют входящих путей выполнения. Извлечение бизнес-логики: какие правила реализует каждая программа, в форме, позволяющей проверить выходные данные любого из путей.
Без этой инвентаризации решение о дальнейшем пути принимается на основе неполной информации. Программы назначаются для переноса на другую платформу на основе предположений, которые оказываются неверными, когда эмуляция выявляет архитектурные ограничения, не виденные на этапе планирования.
Как SMART TS XL Предоставляет доказательства, необходимые для принятия решения.
SMART TS XLАвтора модернизация наследия Анализ автоматизирует описанную выше структурную инвентаризацию, одновременно анализируя каждую программу COBOL, копибук, задание JCL и ссылку на файл VSAM для построения единой модели зависимостей, которая делает принятие решения о пути обоснованным.
Сопоставление зависимостей приложений создает граф вызовов между программами и карту совместного использования наборов данных, которая определяет сложность зависимостей — фактор, наиболее непосредственно влияющий как на риск эмуляции при переходе на новую платформу, так и на область применения и последовательность действий при перепроектировании.
Статический анализ кода позволяет получить метрики сложности, инвентаризацию вызовов CICS и идентифицировать мертвый код для каждой программы в портфеле. Программы, превышающие порог цикломатической сложности и имеющие сильную связь с CICS, автоматически отображаются как кандидаты на перепроектирование или оценку, а не массово назначаются на переплатформирование.
Расширение JCL разрешает символические параметры и выстраивает полную цепочку зависимостей пакетного выполнения, определяя, какие задания JCL вызывают какие программы, в какой последовательности и с какими наборами данных, предоставляя операционный контекст, который определяет, как должен вести себя вывод каждого пути, чтобы соответствовать расписанию пакетного выполнения.
Возможность анализа влияния позволяет четко определить масштабы каждого направления еще до начала программы: для любой программы, выбранной для перепроектирования, анализ влияния перечисляет все зависимые программы, которые необходимо обновить, повторно протестировать или скоординировать с перепроектированным компонентом. Для кандидатов на переплатформирование тот же анализ определяет, какие общие наборы данных и общие подпрограммы создают межпрограммные зависимости, которые необходимо обрабатывать согласованно.
Функция корпоративного поиска позволяет запрашивать полный список файлов в рамках всей программы: за считанные секунды можно найти каждую программу, использующую определенную команду CICS, каждую программу, обращающуюся к определенному кластеру VSAM, каждую книгу сценариев, определяющую определенную структуру данных, по миллионам строк кода COBOL.
Организации, принимающие это решение правильно, — это те, которые основываются на структурных данных, а не на предположениях, заложенных в плане проекта. Структурные данные — это то, что... SMART TS XL производит.
