Этот вопрос возник из инициатив по модернизации предприятий, где многолетние транзакции CICS, обслуживающие основные банковские или страховые системы, предоставляются в виде современных REST API через z/OS Connect или аналогичный промежуточный программный слой. Сложность возникает из-за несоответствия между бездостоящими протоколами HTTP и состоящими контекстами транзакций CICS, особенно касательно реализации данных между JSON и COBOL copybook. Исторически методы ручного обеспечения качества (QA), разработанные для чистого тестирования мейнфреймов или современных микросервисов, оказываются недостаточными для этой гибридной области, что приводит к производственным дефектам, которые проявляются только при специфических нагрузках или крайних случаях данных.
Ручное обеспечение качества сталкивается с уникальными проблемами в этой среде, потому что дефекты проявляются на пересечении поведения распределенных систем и ограничений устаревших мейнфреймов. Буферы COMMAREA имеют фиксированные длины, определенные в COBOL copybook, тогда как полезные нагрузки JSON имеют переменную длину, что приводит к молчаливой усечению, а не к явным ошибкам, когда z/OS Connect выполняет сопоставление данных. Кроме того, транзакции CICS, использующие EXEC CICS SYNCPOINT для обеспечения целостности базы данных, могут оставить сиротские записи, если клиент REST истекает по времени до того, как мейнфрейм завершает транзакцию, однако ответ HTTP может вводить в заблуждение, указывая на успех. Наконец, триггеры TDQ для асинхронной обработки могут выстрелить несколько раз во время конфликтов блокировок RLS между регионами CICS, вызывая дублирование инициаций рабочих процессов, что автоматизированное тестирование API не может обнаружить.
Систематическая методология требует трех уровней валидации.
Во-первых, Тестирование анализа границ использует эквивалентное разбиение на основе copybook для инъекции полезных нагрузок на точно определенных границах длины COMMAREA, проверяя, что EIBCALEN (Длина области связи блока интерфейса выполнения) соответствует ожидаемым значениям в программе COBOL.
Во-вторых, Проверка целостности транзакций включает настройку сетевых прокси для введения преднамеренных тайм-аутов во время выполнения операций SYNCPOINT, а затем использование CEMT (Главный терминал) для проверки состояния регионов CICS и Системного регистратора z/OS для аудита результатов UR (Единица восстановления).
В-третьих, Стресс-тестирование конкуренции использует нескольких клиентов REST для моделирования конфликтов RLS, проверяя идемпотентность TDQ через инспекцию очереди CEBR (Просмотр транзакций) и утилиты EXAMINE для проверки целостности файлов VSAM.
Крупная страховая компания мигрировала свою транзакцию по запросу полисов CICS в мобильное приложение, ориентированное на клиентов, через REST API. После развертывания появилась периодическая порча данных, когда адреса держателей полисов были усечены на середине названия улицы, и дубликаты писем о подтверждении полиса были отправлены высокоценным клиентам, создавая риски соблюдения норм и ущерба репутации.
COBOL copybook определял поле адреса как PIC X(30), но мобильное приложение отправляло символы Unicode UTF-8, включая много байтовые акцентированные символы. Когда z/OS Connect сопоставил это с EBCDIC, количество байтов превысило размер буфера, не вызывая исключений из-за молчаливой логики усечения. Тем временем, под производственной нагрузкой триггеры TDQ выстреливали дважды, когда блокировки RLS задерживали первое подтверждение триггера, в результате чего пакетная работа корреспонденции обрабатывала идентичные запросы дважды.
Решение 1: Автоматизированное тестирование API с использованием заглушенного мейнфрейма
Команда рассматривала возможность использования WireMock, чтобы имитировать ответы CICS без доступа к реальному мейнфрейму, что позволяло быстро выполнять регрессионное тестирование.
Плюсы: Быстрые циклы выполнения, отсутствие потребления дорогих MIPS мейнфрейма и возможность запускать в CI/CD пайплайнах без подключения к мейнфрейму.
Минусы: Не может обнаружить поведение усечения COMMAREA, конфликты блокировок VSAM или фактические ошибки преобразования кодировки EBCDIC, что приводит к ложной уверенности в охвате тестов.
Решение 2: Прямое отладка региона CICS
Присоединение CEDX (Устройство диагностирования выполнения) для отслеживания каждого вызова EXEC CICS и инспекции содержимого COMMAREA в реальном времени.
Плюсы: Позволяет точно определить сбои команд и видеть необработанные макеты памяти структур COBOL.
Минусы: Требует специализированной экспертизы в мейнфрейме, которой не хватало команде QA, значительно влияет на производительность региона CICS и не может имитировать реалистичную задержку сети между распределенными клиентами REST и мейнфреймом.
Решение 3: Систематическое ручное тестирование границ с использованием инспекции CEBR
Вручную создавая REST запросы с длиной полезной нагрузки 29, 30 и 31 символ, используя Postman или cURL, затем используя CEBR для инспекции содержимого TDQ и CEMT INQUIRE FILE для проверки состояния блокировок VSAM RLS.
Плюсы: Проверяет фактический код в производстве, включая преобразование кодов, соблюдение границ COMMAREA и поведение блокировки RLS между несколькими регионами CICS.
Минусы: Требует временных затрат на ручной процесс, требующий учетных данных доступа к TSO мейнфрейма и навыков взаимодействия с терминалом CICS.
Выбрали решение 3, так как только прямая валидация могла выявить молчливое переполнение COMMAREA и условие дублирования триггеров TDQ при конфликтах RLS. Команда создала обширную матрицу тестирования, изменяя длины полезных нагрузок (граничные значения), наборы символов (ASCII против EBCDIC против UTF-8) и нагрузки пользователей (5, 10 и 20 одновременных запросов).
Они использовали CEDF для пошаговой проверки выполнения программы COBOL и подтверждения, что значения EIBCALEN были некорректными, что подтвердило, что логика программы не проверяла входную длину буфера перед обработкой. Для проблемы с TDQ они использовали CEMT INQUIRE TDQUEUE, чтобы контролировать количество триггеров во время сценариев одновременного доступа.
Тестирование показало, что UTF-8 символы, превышающие 30 байт (не символов), вызывали усечение, особенно когда клиенты вводили адреса с несколькими акцентированными символами. Программа COBOL была изменена для проверки EIBCALEN против ожидаемой длины COMMAREA и отклонения избыточных полезных нагрузок с определенными кодами ошибки HTTP 400.
Для проблемы с TDQ тестирование показало, что когда ожидание блокировки RLS превышало 2 секунды, логика повторных попыток REST шлюза создавала дублирующиеся записи TDQ. Архитектура была изменена для реализации идемпотентной обработки с использованием уникальных идентификаторов корреляции, передаваемых через DFHCOMMAREA, что гарантировало обнаружение и исключение дублирующих триггеров обработчиком пакета. Мониторинг после развертывания показал ноль ошибок усечения и устранение дублирующей корреспонденции.
Как вы проверяете поведение отката транзакции CICS, когда клиент REST отключается после отправки запроса, но до получения ответа?
Большинство кандидатов предлагают просто проверить состояние базы данных после отключения. Однако правильный подход включает использование CEMT INQUIRE TASK, чтобы проверить, что транзакция была уничтожена из региона CICS, а затем исследовать z/OS System Logger LOGSTREAM, чтобы подтвердить, что UR (Единица восстановления) была откачена. Кроме того, необходимо проверить согласованность VSAM RBA (Относительный байтовый адрес) с использованием IDCAMS VERIFY, чтобы гарантировать отсутствие сиротских записей. Тонкий момент, который кандидаты упускают, заключается в том, что CICS мог зафиксировать локально, но шлюз REST может не отправил подтверждение, что требует проверки журналов ошибок z/OS Connect на предмет тайм-аутов HCON (HTTP-соединение) по сравнению с кодами абенда CICS вроде AEXZ (тайм-аут).
Когда вы тестируете обработку TDQ, как вы различаете триггеры TDQ внутренней партиции, обрабатываемые внутри одного региона CICS, и триггеры TDQ внешней партиции, записанные в наборы данных z/OS и обрабатываемые пакетными заданиями?
Кандидаты часто упускают, что поведение TDQ принципиально изменяется в зависимости от определений DESTID в DCT (Таблица управления назначениями). Для внутренних TDQ (основанных на памяти) используйте CEBR для проверки глубин очереди и CEMT SET TDQUEUE для ручного запуска обработки, проверяя немедленное инициирование транзакции CICS. Для внешних TDQ необходимо контролировать физический набор данных z/OS с использованием ISPF 3.4 или SDSF для наблюдения за появлением триггерных записей, затем проверить выполнение инициатора JOB класса. Критическое различие заключается в том, что внутренние TDQ поддерживают целостность транзакции CICS через SYNCPOINT, в то время как внешним TDQ требуются отдельные стратегии блокировки VSAM RLS для предотвращения условий гонки удаления записей между CICS и пакетными заданиями, получающими доступ к одному и тому же DESTID.
Как вы проверяете соответствие JSON сопоставлению с COBOL copybook, когда copybook содержит OCCURS DEPENDING ON (ODO) с переменной длиной массивов?
Многие тестировщики проверяют только структуры фиксированной длины и упускают сложность ODO. Для ODO необходимо удостовериться, что z/OS Connect правильно заполняет поле счетчика зависимости перед данными массива в COMMAREA. Тестовые случаи должны включать: (1) Ноль вхождений (пустой массив), (2) Одно вхождение, (3) Максимальное определенное количество вхождений и (4) Превышение максимального количества вхождений для проверки обработки отклонений. Используйте CEBR или CEDF для инспекции макета COMMAREA в шестнадцатеричном формате, проверяя, что бинарные поля COMP поддерживают правильный порядок байтов Big-Endian после преобразования чисел JSON. Сложность возникает из-за того, что массивы JSON не имеют явного длиного индикатора, требуя от сопоставителя вычисления значений ODO из количества элементов, что может неправильно подсчитать, если в полезной нагрузке JSON присутствуют значения null, что приводит к переполнению таблицы COBOL или усечению.