Миграция RPG фиксированного и свободного формата

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

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

Колонки входят в синтаксис программы

В RPG фиксированного формата горизонтальная позиция определяет синтаксис, поэтому инструмент миграции не должен нормализовать пробелы, пока не разберет исходный текст. В справочнике IBM по ILE RPG сказано, что для исходного текста с ограниченными колонками тип спецификации стоит в позиции 6: H обозначает управление, F файлы, D определения, I ввод, C вычисления, O вывод, P процедуры. Другие поля тоже занимают заданные позиции. Символ, сдвинутый в соседнюю колонку, может изменить операцию, условие индикатора или привести к тому, что компилятор вообще не прочитает строку.

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

Хорошая входная проверка сохраняет саму строку и шкалу колонок. Например, отчет об инвентаризации должен показывать такие данные, даже если фактическое извлечение выполняется на IBM i:

member=ORDRPT line=184 bytes=80 spec=C cond_1=03 cond_2=N04 opcode=EXCPT
000001  C   03N04             EXCPT    ORDTOTAL
         1         2         3         4         5         6         7         8
12345678901234567890123456789012345678901234567890123456789012345678901234567890

Формат отчета здесь вторичен. Важно записать 03, N04, EXCPT и ORDTOTAL как разные поля вместе с исходными позициями. Обычный текстовый парсер видит лексемы. Парсер RPG распознает вычисление, которое выполняется при включенном первом и выключенном втором индикаторе, а затем операцию особого вывода. Ее определение может находиться значительно ниже в элементе.

RPG свободного формата снимает большую часть позиционной нагрузки. В полностью свободном исходном тексте **FREE находится в колонке 1 первой строки, а остальные инструкции могут выходить за старую область с ограниченными колонками. Такие инструкции, как ctl-opt, dcl-f, dcl-s и dcl-proc, обозначают свою роль ключевым словом и заканчиваются точкой с запятой. Их легче разбирать, но это не доказывает, что программа процедурная или в ней нет старых конструкций. Синтаксис дает первую классификацию, но не окончательную.

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

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

Поэтому замена *IN03 логической переменной indicator03 дает транслитерацию, а не модернизацию. Имя сохраняет место хранения, но теряет назначение. Для миграции нужен граф определений и использований: все места, которые могут установить индикатор, все зависящие от него операции, каждый сброс и каждая граница, через которую он проходит активным. Только после этого команда сможет понять, означает ли он customerChanged, writeTotals, recordFound, validationFailed или несколько не связанных смыслов в разное время.

Повторное использование индикатора скрывает сложность от подсчета строк. В детальных вычислениях он может иметь один смысл, затем сбрасываться и означать совсем другое внутри подпрограммы. Глобальный поиск покажет две группы, но не докажет, что они независимы. Аналитик должен учитывать порядок вызовов, фазу цикла и последствия файловых операций. Если значение проходит через границу EXSR или сохраняется до вычисления итогов, небрежное переименование способно объединить состояния, которые исходная программа разделяла во времени.

IBM описывает *IN как массив нумерованных индикаторов и предупреждает, что значения, отличные от нуля, единицы, *OFF или *ON, делают последующие проверки непредсказуемыми. Это важно при переносе, поскольку некоторые программы обрабатывают части массива индикаторов как данные. Современная целевая система не должна воспроизводить магический массив из 99 логических значений, если только совместимость на конкретной границе не требует обратного. Нужно расшифровать записи в массив, назвать задуманные состояния и закрепить неоднозначное поведение тестами до удаления старого представления.

Практический результат анализа выглядит как реестр индикаторов, а не их количество:

| Индикатор | Кто устанавливает | Кто читает | Фаза цикла | Возможный смысл | Уверенность | | | | | | | | | 03 | тип записи в I-spec | условная C-spec | детали | выбрана запись заказа | высокая | | 04 | результат CHAIN | условие EXCPT | детали | клиент не найден | средняя | | L1 | смена контрольного поля | вычисление итогов | итоги | смена счета | высокая | | LR | конец основного файла | итоги и завершение | последний цикл | финализация | высокая |

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

Цикл RPG управляет невидимым потоком

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

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

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

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

Минимальная трасса поведения может выглядеть так:

seq=411 phase=read       account=170 record=invoice
seq=412 phase=break      level=L1 old_account=160 new_account=170
seq=413 phase=total      account=160 amount=9284.15 output=ACCT_TOTAL
seq=414 phase=detail     account=170 invoice=88412 amount=73.20
seq=415 phase=final      lr=on output=REPORT_TOTAL

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

Свободный формат бывает разным

RPG свободного формата охватывает несколько стилей, и лишь некоторые похожи на обычный процедурный код. Элемент может содержать свободные вычисления между /FREE и /END-FREE, сохраняя фиксированные спецификации F, I или O. Более новый элемент может использовать свободные объявления, но по-прежнему зависеть от циклической основной процедуры. Полностью свободный модуль может применять ctl-opt nomain, процедуры, явное чтение, квалифицированные структуры данных и прототипы. Если назвать все три варианта «свободным форматом», оценка потеряет самый полезный сигнал.

Документация IBM четко проводит технические границы. Полностью свободный исходный текст использует **FREE в первой строке. Если ему нужны фиксированные инструкции, например старые спецификации ввода или вывода, они должны находиться в подключаемом файле. Правила спецификаций RPG IV также говорят, что MAIN или NOMAIN исключает циклическую основную процедуру, а модуль без этих ключевых слов все еще может ее содержать. Поэтому один **FREE не отвечает на вопрос о наличии цикла.

Я классифицирую элементы по независимым осям:

• режим исходника: фиксированный, смешанный с ограничением колонок или полностью свободный
• модель выполнения: циклическая основная часть, линейная основная часть или процедуры MAIN/NOMAIN
• доступ к данным: файлы под управлением цикла, явный нативный ввод-вывод, встроенный SQL или сочетание
• модель состояния: числовые индикаторы, именованные индикаторы, явные переменные или сочетание
• внешняя форма: вызовы программ и области данных, сервисные процедуры, очереди, файлы или команды заданий

Эта классификация предотвращает типичную ошибку оценки. Два полностью свободных элемента могут сильно различаться: один содержит небольшую процедуру с явным SQL, другой подключает старые O-specs через /COPY, переключает нумерованные индикаторы и завершается через *INLR. При этом элемент фиксированного формата может иметь регулярную структуру, которую хорошо покрывают повторяемые правила. Формат влияет на сложность, но определяет ее поведение.

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

Модернизация начинается с модели поведения

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

Не следует превращать каждую C-spec в инструкцию, а каждый индикатор в логическую переменную и называть результат Go или TypeScript. Этот подход популярен, потому что его удобно измерять: каждой исходной строке соответствует целевая, автоматические отчеты о различиях выглядят содержательно, а проверяющие видят знакомые метки. Но подход сохраняет случайную структуру и затрудняет распознавание неявных правил выполнения. В итоге получается старая семантика RPG на языке, разработчики которого не знают RPG.

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

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

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

Исследование охватывает всю исполняемую систему

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

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

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

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

Результат исследования должен разделять известные, выведенные и непроверенные факты. Утверждение «Программа A вызывает программу B» может следовать из разрешенного графа вызовов. Смысл «Индикатор 42 означает повторную попытку» можно вывести из операций и сообщений. Утверждение «Эта ветвь мертва» остается непроверенным, пока его не подтвердят производственные данные или контролируемый тест. Для разных уровней уверенности нужны разные резервы; единая оценка сложности скрывает эту работу.

Для паритета нужны производственные данные

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

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

Для каждого повтора используйте манифест:

{"case":"account-break-final-record","input_set":"sha256:...","old_build":"LIBA/ORDRPT:...","new_build":"git:...","normalizers":["run_timestamp"],"expected_events":417}

Система проверки должна хранить идентификатор входа, идентификаторы обеих сборок, нормализованные выходы, необработанные выходы там, где это допускают правила, и первое различающееся событие. Сообщение «Файлы различаются» начинает расследование. Сообщение «В событии 413 старый код выдал ACCT_TOTAL до обработки счета 170, а новый после» указывает на ошибочную модель смены контрольного значения.

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

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

Для фиксированного и свободного кода нужны разные единицы оценки

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

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

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

Используйте диапазоны, пока исследование не закроет конкретные неизвестные. В полезной оценке рядом с каждым диапазоном записаны основание и условие его сужения: «Семантика цикла, средняя уверенность, диапазон сузится после двух репрезентативных трасс» звучит обоснованно. «Перенос RPG, 500 строк в день» не звучит. Диапазон должен уменьшаться, когда команда устанавливает происхождение исходников, создает реестр индикаторов, проверяет граф вызовов и повторяет характерные случаи.

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

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

Для фиксированного циклического отчета первая форма начинается раньше. Аналитик должен выяснить, каким файлом управляет цикл, какие спецификации ввода определяют тип записи, какие поля вызывают смену уровня, когда рассчитываются итоги, какие строки O-spec от них зависят и что запускает LR. Затем создается реестр индикаторов, включая значения, которые файловые операции устанавливают неявно. Только после этого целевая система сможет выразить ту же последовательность через чтение, группировку, вычисления и адаптеры вывода. Если считать обе программы одним «элементом RPG», целый слой результатов исчезнет из оценки.

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

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

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

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

Разделение также проясняет управление изменениями: если новое правило цикла сдвинет оценку, заинтересованные стороны увидят, какой класс изменился и почему процедурный прогноз остался прежним.

Одна смешанная цифра создает неверный план

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

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

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

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