Как миграция с AS/400 переносит больше ERP

Называть AS/400 ERP-системой значит смешивать разные категории, из-за чего команды неверно определяют масштаб проекта. ERP представляет прикладную систему. IBM i дает операционную среду, где могут работать купленные пакеты, собственные приложения на RPG, база данных, экраны, очереди, отчеты, правила безопасности и связывающие их процедуры. Компания может заменить знакомый пакет и все равно остаться привязанной к машине.

Миграция с AS/400 успешна лишь тогда, когда новая система воспроизводит бизнес-результаты текущей среды, включая странные сценарии, которые никто не описал. Перенос таблиц и переписывание видимых программ покрывают лишь часть работы. Сложнее всего найти все места, где хранится поведение, решить, какое поведение нужно сохранить, и до отключения старой системы доказать совпадение с продакшеном.

Полезная единица анализа тут не название приложения и не исходный member. Нужна бизнес-транзакция вместе со всеми объектами, которых она касается. Проследите согласование заказа, кредитную блокировку, корректировку складского остатка или проводку закрытия месяца через экраны, программы, файлы, очереди, печатные документы и действия операторов. Этот путь показывает, что придется переносить.

За названием AS/400 скрывается целая операционная среда

На машине обычно работает сеть приложений и операционных соглашений, а не единый блок ERP. IBM несколько раз переименовывала платформу, и теперь IBM i работает на оборудовании Power, но многие компании по-прежнему называют AS/400 все, что стоит за зеленым экраном. Такое сокращение безобидно, пока оно не начинает задавать границы миграции.

Начните с объектной модели. Программы, файлы базы данных, экранные и принтерные файлы, команды, области данных, очереди данных, очереди заданий, выходные очереди, профили пользователей и списки полномочий входят в системные объекты со своими типами и правами. Библиотеки группируют объекты, а список библиотек задания влияет на то, какой объект будет найден по неполному имени во время выполнения. Два задания могут вызвать программу с одним именем и попасть в разные объекты из-за разных списков библиотек. Один поиск по репозиторию этого не покажет.

Купленное ПО усложняет картину. Пакет поставщика может вести основной бухгалтерский учет, а собственный код на RPG рассчитывает цены, распределяет запасы, выполняет регуляторные проверки, управляет складскими операциями или обменивается файлами. Программы CL могут готовить среду, перенаправлять файлы, отправлять задания и вызывать как программы поставщика, так и собственные программы. Операторы иногда запускают команды из меню в строгом порядке, потому что старый сценарий исключения так и не получил нормального интерфейса. Все это не становится частью ERP лишь потому, что пользователи входят через одно меню.

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

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

Db2 for i участвует в поведении приложения

Экспорт базы данных не передает семантику Db2 for i, поскольку программы зависят от большего, чем строки и столбцы. Db2 for i встроена в IBM i. Традиционные приложения часто обращаются к созданным через DDS физическим и логическим файлам с помощью нативных операций над записями, а новый или обновленный код может использовать SQL-таблицы, представления, индексы, процедуры и триггеры. Оба подхода могут встречаться в одной транзакции.

Документация IBM Database files проводит точное различие: физический файл хранит данные приложения, а логический файл представляет один или несколько физических файлов, не сохраняя еще одну копию записей. С точки зрения SQL физический файл соответствует таблице. Логический файл может соответствовать представлению, индексу или их сочетанию. Последний момент особенно важен. Логический файл может задавать ключевой путь доступа, выбирать или исключать записи, менять порядок полей, соединять физические файлы либо предоставлять ожидаемый программой формат записи. Если превратить каждый логический файл в представление PostgreSQL, можно потерять порядок или способ поиска, от которого зависел нативный код RPG. Если превратить все такие файлы в индексы, пропадут правила выборки и проекции.

Еще одно расхождение создают members. Физический файл может содержать несколько members, то есть отдельных наборов записей одного формата. Во многих системах используется только стандартный member, но иногда members разделяют периоды, филиалы, импорты или рабочие наборы. Плоский экспорт, который читает один member, незаметно теряет данные. В целевой модели нужно решить, чем станет member: разделом, столбцом арендатора или периода, промежуточной таблицей либо устаревшим соглашением. Для решения нужны данные об использовании, а не универсальная схема соответствия.

Форматы записей тоже содержат предположения о данных. Упакованные и зонные десятичные числа, символьные поля фиксированной длины, пробелы, нулевые даты, кодированные признаки и внешне описанные поля ведут себя не так, как случайно подобранные типы SQL. Десятизначное число может быть идентификатором, с которым нельзя выполнять арифметику. Пробел может означать неизвестное значение, а ноль, явно заданное отсутствие. В некоторых файлах нет ограничения базы, потому что исторически правило проверяла каждая записывающая программа на RPG. До добавления ограничения в целевую базу миграция должна восстановить это правило, иначе допустимые старые записи не загрузятся.

Журналирование и commitment control нужно проверять отдельно. В документации IBM Commitment control сказано, что группа изменений базы может подтверждаться или откатываться как одна единица, а файлы под таким управлением должны журналироваться. Некоторые пути приложения используют эти границы, другие выполняют независимые нативные записи и полагаются на логику перезапуска. Если поместить весь запрос новой системы в одну транзакцию, изменятся длительность блокировок и восстановление после ошибки. Если убрать транзакцию там, где она была в старом задании, пользователи увидят частичные изменения. Сначала воспроизведите наблюдаемую единицу работы, а затем осознанно улучшайте ее.

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

Исходный код RPG покрывает лишь часть исполняемого графа

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

Документация IBM по RPG различает файлы, описанные программой, и файлы с внешним описанием. Для файла с внешним описанием компилятор при сборке получает определения полей и записей из DDS или SQL. Так появляется зависимость, которую легко не заметить: изменение формата файла может потребовать пересборки зависимых программ, хотя их исходный код не менялся. Проверки уровня способны обнаружить несовместимый формат, но их отключение не делает структуры совместимыми. Оно лишь убирает один механизм предупреждения.

Старый RPG может использовать цикл, индикаторы, структуры данных, подпрограммы, индикаторы исключений и нативные операции CHAIN, SETLL, READE, WRITE, UPDATE и DELETE. Современный RPG может использовать свободный синтаксис, процедуры, сервисные программы и встроенный SQL. По синтаксису нельзя определить значение программы для бизнеса. CL-обертка на тридцать строк, которая задает список библиотек и перенаправляет файл базы, может изменить смысл программы на RPG из десяти тысяч строк.

Связи времени выполнения требуют отдельной карты. Запишите каждое наблюдаемое ребро вызова, включая динамические имена программ, собранные из данных, команды меню, exit-программы, триггеры и удаленные вызовы. Для параметров фиксируйте позицию, тип, длину и возможность изменения. Программы IBM i часто передают параметры по ссылке, поэтому вызванная программа может вернуть состояние, изменив входное поле. Если новый API моделирует только видимое возвращаемое значение, он может потерять детали ошибки или состояние продолжения.

Перенаправления файлов часто вызывают дефекты миграции. Команда OVRDBF может направить имя файла из программы к другому файлу или member без изменения исходного кода RPG. Этот механизм применяют для тестовых данных, альтернативных компаний, архивных members и временной работы. Если анализ читает лишь F-спецификации и операторы SQL, он фиксирует объявленную цель, а не объект, открытый во время выполнения. Соберите перенаправления из CL и активных заданий, затем свяжите их с использующими их транзакциями.

Так же разберите списки библиотек и права. Программа может работать под профилем вызывающего пользователя, принимать полномочия владельца или зависеть от списка полномочий. Целевому сервису нужна явная модель идентификации и разрешений. Копирование широких прав IBM i в одну учетную запись базы поможет пройти первый тест, но удалит разделение, от которого незаметно зависел продакшен.

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

Экранные файлы содержат бизнес-решения

Экранный файл задает исполняемое поведение интерфейса, а не только внешний вид экрана. Экранные файлы DDS определяют форматы записей, поля, константы, функциональные клавиши, subfiles, атрибуты, ключевые слова проверки и индикаторы, которые управляют доступной пользователю информацией и вводом. RPG и экранный файл делят ответственность за взаимодействие. Перенос только части RPG меняет рабочий процесс.

Рассмотрим экран согласования заказа. RPG может загрузить заказ и включить индикатор 31, когда клиент превышает кредитный лимит. Экранный файл способен по этому индикатору показать предупреждение, защитить поле суммы, выделить статус цветом или включить функциональную клавишу. Другой индикатор может отметить недопустимый ввод и поставить курсор в ошибочное поле. В исходном коде RPG видно изменение индикатора, а DDS объясняет его значение для оператора. Без обоих источников новый веб-экран может разрешить изменение, которое блокировал старый экран.

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

В правилах DDS от IBM сказано, что индикатор варианта или имя условия может управлять ключевым словом, полем либо положением поля. Эта короткая фраза объясняет частые разочарования от автоматической конвертации экранов. Логика интерфейса распределена между состоянием RPG и условиями DDS. Анализатор экранов должен создать модель состояний, а не статическую форму.

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

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

Пакетные задания и печатный вывод работают как производственные интерфейсы

Интерактивные экраны показывают только дневную часть многих систем IBM i. Пакетные задания, очереди, планировщики, spool-файлы, передачи и сообщения оператору часто выполняют расчеты, пополнение запасов, выставление счетов, отчетность и обмен с партнерами после ухода пользователей. К этим интерфейсам нужна та же дисциплина миграции, что и к API.

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

Составьте реестр всех планировщиков, отправленных заданий, подсистем, очередей заданий, описаний заданий, записей маршрутизации, выходных очередей и отслеживаемых очередей сообщений в бизнес-периметре. Включите внешние планировщики и скрипты, которые подключаются через FTP, SFTP, протоколы баз данных или командные интерфейсы. Запишите календари, зависимости, правила повторов, ограничения параллельности, ожидаемые диапазоны длительности и человека или систему, реагирующих на сбой. Не выводите расписание из комментариев к коду. Наблюдайте за его работой.

Spool-вывод требует особого внимания. Принтерный файл может задавать заголовки, итоги, поведение при переполнении, разрывы страниц, количество копий и маршрутизацию. Физический принтер мог давно исчезнуть, но другой процесс по-прежнему потребляет spool как поток документов или источник архива. Узнайте, кто получает каждый вывод, что с ним делает и чем подтверждается доставка. Замена отчета веб-страницей не дает эквивалентный результат, если складу нужен поток этикеток или банк ждет файл с фиксированными записями.

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

Считайте время входными данными. Даты обработки, финансовые периоды, переходы на летнее время, календари праздников и переключатели конца дня могут поступать из областей данных или управляющих файлов, а не из системных часов. Облачный планировщик с правильным временем все равно способен выдать неверную бизнес-дату.

Исследование должно создать карту поведения

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

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

DSPOBJD OBJ(APP/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/OBJECTS)
DSPPGMREF PGM(APP/*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/PGMREF)
DSPFD FILE(APP/*ALL) TYPE(*ATR) OUTPUT(*OUTFILE) FILEATR(*PF *LF) OUTFILE(AUDIT/FILEATTR)
DSPFFD FILE(APP/*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/FIELDS)

Эти команды дают начальный артефакт, но не полный сканер. Выполните аналогичную инвентаризацию во всех нужных библиотеках, сохраните полные имена объектов и отметьте команды, где нужны отдельные выборки. Добавьте списки исходных members, данные каталога SQL, расписания заданий, настройки очередей, права, триггеры, ограничения, журналы и пути Integrated File System. Выходной файл ссылок программы сообщает о статических ссылках, известных программному объекту, но для динамических вызовов и перенаправлений времени выполнения по-прежнему нужны трассы и анализ CL.

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

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

Неудобный вопрос касается достаточной глубины исследования. Работа достаточна, когда команда может выбрать транзакцию, предсказать ее чтения, записи, выходные данные, сигналы ошибок, профиль и путь восстановления, а затем подтвердить прогноз производственными данными. Неизвестные динамические ребра нужно явно отметить и проверить. Большой реестр с необъясненными точками входа не завершает исследование.

Паритет охватывает результаты и побочные эффекты

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

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

Запись сравнения может оставаться простой:

{"case_id":"credit-release-017","result":"held","writes":[{"entity":"order","key":"48152","fields":{"status":"H"}}],"messages":["CREDIT LIMIT EXCEEDED"],"jobs_submitted":[],"documents":[]}

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

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

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

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

Правильная целевая архитектура сохраняет поведение и переносит правила в компоненты, понятные людям и пригодные для эксплуатации. Она не воссоздает библиотеки, индикаторы и перенаправления файлов под новыми именами. Транслитерация сохраняет зависимости, из-за которых старую систему трудно менять.

Организуйте целевую систему по бизнес-возможностям и границам транзакций, найденным по доказательствам. Сервисы на Go могут отвечать за транзакционные процессы и внешние API. Клиенты на TypeScript могут выражать состояние экрана без числовых индикаторов. PostgreSQL может применять реляционные ограничения и предоставлять явные схемы, представления и индексы. Rust подходит для численных ядер, когда это подтверждают измерения или требования предметной области, а не как стандартная замена каждого вычисления. Это проектные решения, а не механическая таблица языков.

Сопоставляйте каждую конструкцию IBM i по смыслу. Физический файл может стать таблицей, но для нескольких members нужна продуманная модель. Логический файл может стать индексом вместе с представлением или запросом внутри сервиса. Очередь данных может превратиться в тему брокера, исходящую очередь базы или прямой вызов в зависимости от контракта доставки. Область данных может стать конфигурацией, долговременным состоянием или последовательностью. Условие экранного файла может стать правилом клиента или серверной проверкой полномочий. Решения о безопасности должны выполняться на сервере, даже если раньше их частично обеспечивал экран.

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

CodeHero одновременно читает все дерево RPG и CL, переписывает систему на Go, Rust, TypeScript и PostgreSQL и проверяет поведение через контур паритета по записанному производственному трафику. Такой подход помогает лишь тогда, когда входной периметр включает описанные здесь файлы, экранные определения и операционные пути. Агент не сохранит объект, который никто не собрал.

Отделяйте решения о модернизации от решений о паритете. Сначала зафиксируйте старое поведение вместе с доказательствами. Затем согласуйте измененное правило, модель данных или пользовательский путь и запишите новое ожидание. Такое разделение позволяет инженерам объяснить каждое различие на проверке и откатить его, не угадывая, какие расхождения возникли случайно.

Выходной тест принадлежит операционной команде

Миграция заканчивается, когда бизнес может эксплуатировать, восстанавливать, проверять и менять новую систему без зависимости от IBM i. Функциональные тесты необходимы, но выходной тест принадлежит операторам, поскольку они работают с условиями, которых избегают демонстрации приложений.

Подготовьте переключение как управляемый переход состояния. Определите последнюю авторитетную запись в IBM i, финальный захват или загрузку, запросы сверки, правила опустошения очередей, обработку документов, смену учетных данных, переключение маршрутов и точку решения об откате. Назовите человека, способного остановить переключение, и доказательства, которыми он воспользуется. Если для отката придется объединять записи из двух систем, решите эту задачу до события вместо написания чрезмерно оптимистичной инструкции.

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

Проведите учения по восстановлению до отключения. Остановите обработчик во время обновления нескольких записей. Задержите внешний ответ. Продублируйте сообщение. Заполните очередь. Восстановите резервную копию базы и повторите недостающую работу. Убедитесь, что оповещение получает человек с достаточным контекстом для действий. IBM i могла сделать некоторые процедуры восстановления привычными с помощью журналов, протоколов заданий и очередей. В новой системе каждая ответственность должна стать явной.

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

Наконец, сохраняйте старую систему в определенном режиме только для чтения или восстановления лишь на период одобренной необходимости. Назначьте владельца, стоимость, политику доступа и условие удаления или архивации. Бессрочный запасной вариант превращается во вторую производственную систему, которую никто не тестирует. Честная финишная точка наступает в первый обычный рабочий день, когда сбой задания, спорную сумму и новое правило можно обработать без звонка последнему человеку, который помнит индикатор 31.