IMS — это не устаревшая система в том смысле, что она вышла из строя. Это движок базы данных, лежащий в основе управления дебиторской задолженностью крупных банков, администрирования страховых полисов и обработки заявок в сфере здравоохранения. IBM продолжает её развивать. Проблема не в том, что IMS перестала работать, а в том, что каждый разработчик, умевший работать с её иерархической структурой, уходит на пенсию, каждое изменение в системе, использующей IMS, требует понимания модели данных, в которой отсутствует SQL, и каждый план миграции, рассматривающий IMS как реляционную базу данных, на собственном опыте убеждается в этом.
Трудный путь — это обнаружение в середине миграции того факта, что программа на COBOL обращается к IMS не через простой поиск по ключу, а через иерархический обход, который необходимо воспроизвести в целевой системе с эквивалентной логикой навигации. Или обнаружение того, что логическая связь между двумя физическими базами данных IMS создает зависимость, которая не полностью документирована в DBD ни одной из баз данных, и что миграция преобразовала обе базы данных независимо друг от друга, незаметно нарушив работу всех программ, использующих эту логическую связь. Или обнаружение того, что вторичная индексная база данных, структура, которую большинство планов миграции никогда не инвентаризируют, была единственным путем, по которому критически важная программа отчетности получала свои данные.
Ни одна из этих неожиданностей не выдерживает проверки строгим анализом зависимостей до миграции. Они выдерживают проверку предположениями.
Анализ зависимостей IMS в масштабе портфеля
SMART TS XL Выявляет межбазовые зависимости IMS, которые невидимы в исходном коде COBOL.
ПодробнееЧем отличается анализ зависимостей IMS?
Анализ зависимостей в среде реляционных баз данных (DB2, Oracle, SQL Server) следует хорошо известному алгоритму. Сначала анализируется SQL-код приложения, определяются ссылки на таблицы и столбцы, строится карта, показывающая, какие программы обращаются к каким таблицам, и эта карта используется для определения объема и последовательности миграции. Структура является явной. Зависимости видны в тексте SQL-запроса.
Анализ зависимостей в IMS становится все сложнее по каждому измерению.
Структура иерархическая, а не реляционная. База данных IMS организована в виде дерева типов сегментов, где каждый тип сегмента имеет определенную связь «родитель-потомок». Программа на COBOL, считывающая записи пациентов из базы данных IMS, не выполняется. SELECT * FROM PATIENTS WHERE ID = ?Программа выполняет вызов Get Unique (GU) для навигации по иерархии к корневому сегменту, а затем вызов Get Next Within Parent (GNP) для обхода дочерних элементов. Зависимость программы не от таблицы, а от конкретного пути через иерархическую структуру, и изменение этой структуры может привести к сбоям в работе программ, которые перемещаются по ней способами, которые не будут обнаружены с помощью анализа на уровне SQL.
Зависимости распределены по трем отдельным структурам. Для полного понимания того, что делает программа на COBOL с IMS, необходимо проанализировать следующее:
- Дескриптор базы данных (DBD): Определяет иерархию физических сегментов, ключевые поля, методы доступа (HDAM, HIDAM, HISAM, HSAM), а также любые вторичные индексы или логические связи.
- Блок программной спецификации (PSB): Определяет, к каким базам данных программе разрешен доступ, через какие печатные платы, с какой степенью конфиденциальности и в соответствии с заданными параметрами.
- Исходный код COBOL: Содержит фактические вызовы DL/I, определяющие, к каким сегментам осуществляется доступ, с какими функциями вызова, в какой последовательности и с какими SSA.
Ни один источник не содержит полной картины. Анализ, считывающий только исходный код COBOL, видит типы вызовов и имена сегментов, но не физическую структуру базы данных. Анализ, считывающий только DBD и PSB, видит, что программе разрешено делать, но не то, что она делает фактически.
Навигация зависит от положения. В реляционной базе данных каждая строка доступна независимо по ключу. В IMS текущее положение программы в иерархии влияет на то, что возвращают последующие вызовы. Вызов GN (Get Next) возвращает следующий сегмент в иерархической последовательности из того места, где программа находится в данный момент. Зависимость заключается не только в типе сегмента, но и в пути обхода, который привёл к текущей позиции. Программы, которые полагаются на неявный иерархический порядок IMS, имеют зависимость, которая исчезает при миграции данных в реляционную базу данных, где эквивалентный порядок не гарантируется.
Инвентаризация вызовов DL/I: что раскрывает исходный код COBOL
Наиболее полезным предмиграционным анализом является полный перечень всех вызовов DL/I в каждой программе COBOL, которая обращается к IMS. Этот перечень показывает команде миграции, что каждая программа делает с IMS, не то, что ей разрешено делать (что определяется PSB), а то, что она делает фактически.
В COBOL вызовы DL/I отображаются в двух формах:
кобол
* Form 1: EXEC DLI interface (CICS-compatible, high-level syntax)
EXEC DLI
GU DB2PCB
SEGMENT(CUSTROOT)
WHERE(CUSTID = WS-CUST-ID)
END-EXEC
* Form 2: xxxTDLI call interface (batch programs, assembler-compatible)
CALL 'CBLTDLI' USING WS-FUNCTION-CODE
PCB-CUSTOMER
WS-CUSTOMER-SEGMENT
WS-SSA-CUSTOMERОбе формы содержат одинаковую аналитическую информацию: код функции, используемую плату управления, целевой сегмент и, при необходимости, аргумент поиска сегмента (SSA), который определяет тип вызова. Полный перечень вызовов DL/I извлекает всю эту информацию из каждой программы.
Таксономия функциональных кодов и ее последствия для миграции
Функциональный код DL/I является наиболее важным элементом каждого вызова с точки зрения миграции. Каждый функциональный код подразумевает различный шаблон доступа к данным, который должен быть воспроизведен в целевой реляционной базе данных:
Функции только для чтения: GUПолучите уникальный доступ: переходите непосредственно к сегменту, используя квалифицированные SSA. Эквивалентно оператору SELECT с предложением WHERE в реляционной модели. Миграция проста, если ключ сегмента корректно соответствует первичному ключу реляционной модели.
GNФункция Get Next: переход к следующему сегменту в иерархической последовательности. Это функциональный код, не имеющий прямого реляционного эквивалента, он основан на позиционном состоянии IMS и неявном порядке. Программы, широко использующие GN, требуют тщательного анализа того, от какого порядка они зависят.
GNPЗапрос Get Next Within Parent: извлекает последующие дочерние элементы текущего родительского сегмента. Эквивалентно извлечению всех строк в отношении по внешнему ключу. Обычно корректно сопоставляется с запросом SELECT с условием WHERE для внешнего ключа.
Функции удержания (необходимые условия для обновления): GHU, GHN, GHNPАналоги функций GU, GN, GNP в функции «Удержание» (Hold). Флаг «hold» указывает на то, что за ним последует операция обновления (REPL) или удаления (DLET). Программы, использующие вызовы hold, являются программами чтения-изменения-записи; миграция должна сохранять транзакционную целостность как при использовании функции hold, так и при последующем обновлении.
Функции обновления: ISRT, Insert: добавляет новое вхождение сегмента. Эквивалентно INSERT. DLETФункция «Удалить» удаляет текущий удерживаемый сегмент и все зависимые от него сегменты. Поведение «все зависимые сегменты» является специфичной для IMS каскадной операцией, которую необходимо явно реализовать в целевой системе. REPLReplace: обновляет текущий удерживаемый сегмент новыми данными. Эквивалентно UPDATE.
Почему это важно для масштабов миграции: Программа, использующая только вызовы GU и GNP, является потребителем данных IMS только для чтения, что снижает риск миграции и упрощает проверку. Программа, использующая GHU, REPL и DLET, является программой обработки транзакций, которая изменяет иерархические структуры; для ее миграции необходимо сохранять целостность транзакций между операциями, что в настоящее время обеспечивается атомарно в IMS.
Три типа зависимостей, которые мешают любой миграции
Логические взаимосвязи
В IMS логические связи соединяют сегменты в двух физически разделенных базах данных. Логический дочерний сегмент в базе данных A имеет логического родителя в базе данных B. Когда программа на COBOL перемещается по логической связи, она проходит путь, который физически пересекает границы баз данных, — этот путь IMS обрабатывает прозрачно, но он исчезает при независимой миграции баз данных.
Логические связи представляют собой наиболее рискованный тип зависимостей при миграции IMS по одной причине: они невидимы в исходном коде COBOL. Программа COBOL вызывает GNP для получения дочерних элементов сегмента. Происходит ли вызов GNP через физическую связь «родитель-потомок» или через логическую связь, определяется PSB и DBD, а не кодом COBOL. Команда миграции, анализирующая только исходный код COBOL, не может узнать, пересекает ли вызов GNP границу логической связи, без отдельного анализа PSB и DBD.
Для программ, использующих логические связи, миграция требует воспроизведения семантики этих связей в целевой системе, как правило, с помощью операции JOIN в реляционной модели, а также проверки того, что каждая программа, использующая эти связи, получает от операции JOIN эквивалентные результаты, полученные при обходе логической структуры IMS.
Базы данных вторичных индексов
Вторичные индексные базы данных IMS предоставляют альтернативный путь доступа к основной базе данных, позволяя программам извлекать сегменты по полю, отличному от корневого ключа. Вторичная индексная база данных представляет собой отдельную базу данных IMS со своим собственным DBD, но ее данные формируются на основе основной базы данных.
Группы по миграции часто обнаруживают вторичные индексные базы данных на этапе анализа, а не на этапе планирования, по следующим причинам:
- Они определены в DBD, которые не всегда сгруппированы с DBD основной базы данных.
- Программы, использующие вторичные индексы, указывают имя индексированной базы данных в своих PSB, но программы, которые обращаются к основной базе данных через вторичный индекс, могут не показывать это явно в исходном коде COBOL.
- В документации может описываться основная база данных без упоминания ее вторичных индексов.
Программа, обращающаяся к IMS через вторичный индекс, имеет зависимость от шаблона доступа, которую необходимо реплицировать в целевой системе в виде индекса, не являющегося первичным ключом, или с использованием другой стратегии запросов. Отсутствие этой зависимости во время миграции приводит к тому, что программа работает без ошибок, но не может найти нужные записи.
Базы данных GSAM
Базы данных GSAM (Generalized Sequential Access Method) — это интерфейс IMS для последовательной пакетной обработки, по сути, позволяющий пакетным программам COBOL использовать вызовы DL/I для функционально последовательного файлового ввода-вывода. Базы данных GSAM не имеют сегментных иерархий; это плоские последовательные структуры, доступ к которым осуществляется через IMS, что позволяет использовать возможности восстановления и перезапуска IMS.
Программы, использующие базы данных GSAM, являются пакетными программами, которые зависят от поддержки контрольных точек/перезапуска в IMS для восстановления. При миграции необходимо сохранить это поведение восстановления или заменить его эквивалентным механизмом на целевой платформе.
Создание перечня зависимых лиц до миграции
Полный анализ зависимостей IMS позволяет получить шесть результатов, которые в совокупности определяют объем миграции, риски и последовательность действий.
Результат 1: Сопоставление печатной платы с базой данных
Каждый PCB в каждом PSB соответствует определенной DBD (конкретной базе данных IMS). Перечисление всех PCB во всех PSB и сопоставление каждого с его DBD дает авторитетный список того, каким программам разрешен доступ к каким базам данных. Это отправная точка для понимания области действия, но она завышает фактические зависимости, поскольку программы могут иметь PSB, которые включают больше баз данных, чем они фактически используют.
Результат 2: Фактическое количество звонков по каждой программе
Анализ вызовов DL/I каждой программы COBOL позволяет получить фактический список использования: какие блоки управления (PCB) каждая программа фактически вызывает, какие коды функций она использует, к каким типам сегментов она обращается и использует ли она квалифицированные SSA (доступ к ключу сегмента) или неквалифицированную навигацию (позиционный обход). Это сужает область поиска от разрешений, определенных PSB, до фактического поведения программы.
Результат 3: Карта использования логических связей
Сопоставление списка вызовов с базами данных DBD позволяет определить, какие вызовы GNP или GN в рамках программ проходят через логические связи. Для этого необходимо анализировать не только исходный код COBOL и PSB, но и структуры DBD, определяющие, какие отношения «родитель-потомок» являются физическими, а какие — логическими.
Результат 4: Карта использования вторичного индекса
Программы, которые указывают в своих PSB-пакетах имена баз данных вторичных индексов или выполняют вызовы с SSA, ссылающимися на поля ключей, не являющиеся корневыми, идентифицируются как пользователи вторичных индексов. Карта документирует, какие вторичные индексы существуют, какие основные базы данных они поддерживают и какие программы от них зависят.
Результат 5: Распределение типов звонков по базам данных
Для каждой рассматриваемой базы данных IMS распределение типов вызовов по всем программам, обращающимся к ней, указывает на сложность ее миграции:
- Базы данных, доступ к которым осуществляется только посредством функций чтения (GU, GN, GNP), проще перенести.
- Для баз данных, к которым осуществляется доступ с помощью функций удержания и обновления (GHU + REPL, GHN + DLET), требуется репликация транзакционной целостности.
- Базы данных с высокой интенсивностью использования GN указывают на зависимости позиционной навигации, требующие анализа порядка выполнения операций.
- Базы данных с логическими связями требуют использования семантики объединения (JOIN) между базами данных в целевой базе данных.
Результат 6: Классификация программных рисков
Используя распределение типов вызовов и перечень типов зависимостей, каждая программа классифицируется по риску миграции:
Программы, использующие только GU и GNP с квалифицированными SSA, обращающиеся к одной базе данных без логических связей и не имеющие вызовов на удержание/обновление, являются наименее рискованными кандидатами для первых волн миграции. Программы, которые широко используют GN, обращаются к нескольким базам данных через логические связи или выполняют сложные последовательности удержания/обновления, являются наиболее рискованными программами, требующими наиболее тщательного анализа и проверки перед миграцией.
Что меняет анализ в планировании миграции?
Анализ зависимостей не просто документирует существующее положение вещей, он меняет последующие решения.
Решения о последовательности выполнения. Программы, использующие общие базы данных IMS посредством логических связей, не могут быть перенесены независимо друг от друга. Если программа A считывает логический дочерний сегмент, имеющий логического родителя в той же базе данных, что и корневой сегмент программы B, то перенос программы A без переноса программы B (или создания моста) нарушит работу программы A. Граф зависимостей определяет, какие программы должны быть перенесены вместе.
Целевые проектные решения. Распределение типов вызовов определяет структуру целевой реляционной схемы. Иерархическая связь «родитель-потомок», доступ к которой осуществляется исключительно через вызовы GU и GNP с указанием ключа, корректно преобразуется в связь внешнего ключа в целевой схеме. Та же самая связь, доступ к которой осуществляется через вызовы GN с позиционными зависимостями, требует от целевой схемы сохранения эквивалентного порядка, либо посредством явного ORDER BY, поля последовательности, либо с помощью другого шаблона доступа, обеспечивающего тот же результат.
Решения по объему проверки. Анализ определяет, какие программы являются потребителями данных IMS только для чтения, а какие — обработчиками транзакций. Программы только для чтения могут быть проверены путем сравнения результатов работы исходной системы IMS и мигрированной системы. Обработчики транзакций требуют проверки эквивалентности транзакций, гарантирующей, что одна и та же последовательность операций над целевой системой приводит к эквивалентным изменениям состояния данных по сравнению с исходной системой.
Классификация рисков. Логические взаимосвязи и результаты анализа вторичных индексов являются основными входными данными для классификации рисков. В каждой программе миграции существует реестр рисков. Анализ зависимостей IMS указывает команде, какие записи следует внести в него.
Как SMART TS XL Выполняет анализ зависимостей IMS.
SMART TS XLАвтора статический анализ кода Программа анализирует вызовы DL/I каждой программы COBOL, как в формате EXEC DLI, так и в формате xxxTDLI, извлекая из каждого вызова код функции, ссылку на PCB, имя сегмента и структуру SSA. Это позволяет получить фактический перечень вызовов на уровне программы по всему портфелю COBOL без необходимости использования работающей системы IMS или ручного анализа кода.
Карта зависимостей приложений расширяет этот перечень до графа межпрограммных зависимостей: какие программы совместно используют доступ к каким базам данных IMS, какие программы используют одни и те же PCB, у каких программ шаблоны доступа пересекаются таким образом, что требуется скоординированная миграция. Когда логическая связь соединяет сегменты между базами данных, карта зависимостей представляет эту межбазовую связь как явное отношение, которое должно быть сохранено в целевой системе.
Функция анализа влияния отвечает на вопрос, на который должна ответить каждая команда по миграции перед преобразованием любой базы данных: если эта база данных IMS будет мигрирована, какие программы будут затронуты, какие шаблоны доступа необходимо воспроизвести и какие тестовые примеры необходимо проверить для подтверждения эквивалентности. Ответ не является оценкой, это перечень, полученный на основе фактического инвентаря звонков DL/I.
Возможность расширения JCL добавляет операционный контекст: какие шаги задания JCL вызывают какие программы, обращающиеся к IMS, в какой последовательности и с какими спецификациями PSB. Операционная цепочка зависимостей, последовательность пакетных заданий, обрабатывающая данные IMS через несколько программ, так же важна для планирования миграции, как и шаблоны доступа на уровне программ. Миграция базы данных без миграции оркестрации пакетных заданий, которая ее окружает, приводит к созданию системы, которая корректно обрабатывает записи изолированно и дает сбой в производственной среде при выполнении последовательности заданий.
Для команд, проводящих модернизация наследия структурные данные, полученные в результате исследований систем, поддерживаемых IMS, SMART TS XL Это исходные данные для каждого последующего решения о миграции: какие программы мигрируют в какой волне, какие базы данных могут быть преобразованы независимо, а какие требуют скоординированного преобразования, какие шаблоны доступа требуют перепроектирования архитектуры, а не прямого перевода. Как описано в контексте миграция структур IMS и VSAM параллельно с программами на COBOLВзаимосвязь между программами COBOL и устаревшими структурами данных означает, что миграция данных и анализ кода должны происходить параллельно; инвентаризация зависимостей — это механизм, который делает возможным параллельное планирование.
Инвентаризация – это не миграция.
Анализ зависимостей IMS позволяет получить знания. Миграция по-прежнему требует принятия решений, проектирования и проверки. Анализ меняет качество принимаемых решений, полноту проектного объема и уверенность в результатах проверки.
Организации, успешно осуществляющие миграцию баз данных IMS, — это не те, у кого самые сжатые сроки или самые большие бюджеты на миграцию. Это те, кто знал, что у них есть, прежде чем начать перенос: каждую программу, обращающуюся к каждой базе данных, каждый функциональный код, раскрывающий шаблон доступа каждой программы, каждую логическую связь, создающую зависимости между базами данных, каждый вторичный индекс, обеспечивающий путь доступа, который не сохранится после конвертации без явной репликации.
Эти знания не почерпнуты из документации. Они получены в результате анализа кода.
