O IMS não é um sistema legado no sentido de estar obsoleto. É o mecanismo de banco de dados por trás das contas a receber dos principais bancos, da administração de apólices de seguradoras e do processamento de sinistros de operadoras de planos de saúde. A IBM continua a desenvolvê-lo. O problema não é que o IMS tenha parado de funcionar, mas sim que todos os desenvolvedores que sabiam navegar em suas árvores hierárquicas de segmentos estão se aposentando, cada alteração em um sistema baseado em IMS exige a compreensão de um modelo de dados que não possui SQL, e cada plano de migração que trata o IMS como um banco de dados relacional descobre a diferença da maneira mais difícil.
A maneira mais difícil é descobrir, no meio da migração, que um programa COBOL acessa o IMS não por meio de uma simples busca por chave, mas sim por meio de uma travessia hierárquica que precisa ser replicada no sistema de destino com lógica de navegação equivalente. Ou descobrir que uma relação lógica entre dois bancos de dados físicos do IMS cria uma dependência que nenhum dos DBDs de ambos os bancos de dados documenta completamente, e que a migração converteu os dois bancos de dados independentemente, enquanto silenciosamente quebrava todos os programas que utilizavam a relação lógica. Ou descobrir que um banco de dados de índice secundário, uma estrutura que a maioria dos planos de migração nunca inventaria, era o único caminho pelo qual um programa crítico de geração de relatórios acessava seus dados.
Nenhuma dessas surpresas resiste ao contato com uma análise rigorosa de dependências pré-migratórias. Elas resistem ao contato com suposições.
Análise de Dependências IMS em Escala de Portfólio
SMART TS XL Identifica dependências IMS entre bancos de dados que são invisíveis apenas no código-fonte COBOL.
Mais informaçõesO que torna a análise de dependência do IMS diferente?
A análise de dependências em um ambiente de banco de dados relacional, como DB2, Oracle ou SQL Server, segue um caminho bem definido. Analisa-se o SQL no código da aplicação, identificam-se as referências a tabelas e colunas, constrói-se um mapa de quais programas acessam quais tabelas e usa-se esse mapa para determinar o escopo e a sequência da migração. A estrutura é explícita. As dependências são visíveis no texto SQL.
A análise de dependências do IMS é mais complexa em todas as dimensões.
A estrutura é hierárquica, não relacional. Um banco de dados IMS é organizado como uma árvore de tipos de segmento, onde cada tipo de segmento possui uma relação pai-filho definida. Um programa COBOL que lê registros de pacientes de um banco de dados IMS não é executado. SELECT * FROM PATIENTS WHERE ID = ?O programa emite uma chamada Get Unique (GU) para navegar na hierarquia até o segmento raiz e, em seguida, chamadas Get Next Within Parent (GNP) para percorrer os filhos. A dependência do programa não está em uma tabela, mas sim em um caminho específico através de uma estrutura hierárquica, e alterar essa estrutura pode quebrar programas que a utilizam de maneiras que nenhuma análise em nível de SQL detectaria.
As dependências estão distribuídas por três estruturas separadas. Para se ter uma visão completa do que um programa COBOL faz com o IMS, é necessário analisar:
- O DBD (Descritor de Banco de Dados): Define a hierarquia do segmento físico, os campos-chave, os métodos de acesso (HDAM, HIDAM, HISAM, HSAM) e quaisquer índices secundários ou relações lógicas.
- O PSB (Bloco de Especificação do Programa): Define quais bancos de dados um programa tem permissão para acessar, por meio de quais PCBs, com quais especificações de sensibilidade e intenção.
- O código-fonte COBOL: Contém as chamadas DL/I reais que determinam quais segmentos são acessados, com quais funções de chamada, em que sequência e com quais SSAs.
Nenhuma fonte isolada contém o quadro completo. Uma análise que lê apenas o código-fonte COBOL vê os tipos de chamada e os nomes dos segmentos, mas não a estrutura física do banco de dados. Uma análise que lê apenas o DBD e o PSB vê o que o programa tem permissão para fazer, mas não o que ele realmente faz.
A navegação depende da posição. Em um banco de dados relacional, cada linha é endereçável independentemente por chave. No IMS, a posição atual de um programa na hierarquia afeta o que as chamadas subsequentes retornam. Uma chamada GN (Get Next) retorna o próximo segmento na sequência hierárquica a partir de onde o programa estiver atualmente. A dependência não se limita ao tipo de segmento, mas também ao caminho percorrido que levou à posição atual. Programas que dependem da ordenação hierárquica implícita do IMS possuem uma dependência que desaparece quando os dados são migrados para um banco de dados relacional, onde nenhuma ordenação equivalente é garantida.
Inventário de Chamadas DL/I: O que o código-fonte COBOL revela
A análise pré-migração mais diretamente útil é um inventário completo de todas as chamadas DL/I em todos os programas COBOL que acessam o IMS. Esse inventário informa à equipe de migração o que cada programa faz com o IMS, não o que ele tem permissão para fazer (o que é definido pelo PSB), mas o que ele realmente faz.
As chamadas DL/I em COBOL aparecem de duas formas:
cobol
* 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-CUSTOMERAmbas as formas contêm as mesmas informações analíticas: o código da função, a placa de circuito impresso (PCB) utilizada, o segmento alvo e, opcionalmente, o argumento de busca de segmento (SSA) que qualifica a chamada. Um inventário completo de chamadas DL/I extrai todas essas informações de cada programa.
A Taxonomia de Códigos de Função e suas Implicações para a Migração
O código de função DL/I é o elemento mais importante para a migração em cada chamada. Cada código de função implica um padrão de acesso a dados diferente que deve ser replicado no banco de dados relacional de destino:
Funções somente leitura: GUObter valores únicos: navegue diretamente para um segmento usando SSAs qualificados. Equivalente a um SELECT com cláusula WHERE em termos relacionais. Simples de migrar se a chave do segmento corresponder perfeitamente a uma chave primária relacional.
GN, Get Next: move para o próximo segmento na sequência hierárquica. Este é o código de função que não possui equivalente relacional direto; ele depende do estado posicional e da ordenação implícita do IMS. Programas que utilizam GN extensivamente requerem uma análise cuidadosa da ordenação da qual dependem.
GNP, Obter Próximo Dentro do Pai: recupera os filhos subsequentes do segmento pai atual. Equivalente a buscar todas as linhas em um relacionamento de chave estrangeira. Geralmente, corresponde diretamente a um SELECT com uma cláusula WHERE de chave estrangeira.
Funções de retenção (pré-requisitos para atualização): GHU, GHN, GHNPObtenha os equivalentes de GU, GN e GNP para o parâmetro Hold. O sinalizador "hold" indica que uma operação de atualização (REPL) ou exclusão (DLET) será realizada em seguida. Programas que utilizam chamadas de hold são programas de leitura-modificação-escrita; a migração deve preservar a integridade transacional durante o período de hold e a atualização subsequente.
Atualizar funções: ISRT, Insert: adiciona uma nova ocorrência de segmento. Equivalente a INSERT. DLET, Excluir: remove o segmento atualmente retido e todos os seus dependentes. O comportamento de "todos os dependentes" é uma cascata específica do IMS que deve ser implementada explicitamente no sistema de destino. REPL, Substituir: atualiza o segmento atual com novos dados. Equivalente a UPDATE.
Por que isso é importante para o escopo da migração: Um programa com apenas chamadas GU e GNP é um consumidor somente leitura de dados do IMS, apresentando menor risco de migração e sendo mais simples de validar. Um programa que utiliza GHU, REPL e DLET é um programa de processamento de transações que modifica estruturas hierárquicas; sua migração exige a preservação da integridade transacional entre as operações, algo que o IMS atualmente garante de forma atômica.
Os três tipos de dependência que atrapalham todas as migrações
Relações Lógicas
Os relacionamentos lógicos do IMS conectam segmentos em dois bancos de dados fisicamente separados. Um segmento filho lógico no Banco de Dados A tem um pai lógico no Banco de Dados B. Quando um programa COBOL navega por um relacionamento lógico, ele percorre um caminho que cruza fisicamente os limites dos bancos de dados, uma travessia que o IMS gerencia de forma transparente, mas que desaparece quando os bancos de dados são migrados independentemente.
Os relacionamentos lógicos representam o tipo de dependência de maior risco na migração do IMS por um motivo: eles são invisíveis no código-fonte COBOL. O programa COBOL chama a função GNP para obter os filhos de um segmento. Se essa GNP atravessa um relacionamento físico pai-filho ou um relacionamento lógico é determinado pelo PSB e pelo DBD, e não pelo código COBOL. Uma equipe de migração que analisa apenas o código-fonte COBOL não tem como saber se uma chamada GNP está cruzando um limite de relacionamento lógico sem analisar separadamente o PSB e o DBD.
Programas que utilizam relações lógicas exigem que a migração replique a semântica da relação lógica no sistema de destino, normalmente um JOIN no modelo relacional, e que valide se cada programa que utiliza a relação recebe resultados equivalentes do JOIN aos que recebeu da travessia lógica do IMS.
Bancos de dados de índice secundário
Os bancos de dados de índice secundário do IMS fornecem um caminho de acesso alternativo a um banco de dados primário, permitindo que os programas recuperem segmentos por um campo diferente da chave raiz. Um banco de dados de índice secundário é um banco de dados IMS separado com seu próprio DBD, mas seus dados são derivados do banco de dados primário.
As equipes de migração frequentemente descobrem bancos de dados de índices secundários durante a análise, e não durante o planejamento, porque:
- Eles são definidos em DBDs que nem sempre são agrupados com os DBDs do banco de dados primário.
- Programas que utilizam índices secundários especificam o banco de dados de índice em seus PSBs (Plataformas de Banco de Dados Primário), mas programas que navegam até o banco de dados primário por meio de um índice secundário podem não deixar isso claro no código-fonte COBOL.
- A documentação pode descrever o banco de dados principal sem mencionar seus índices secundários.
Um programa que acessa o IMS por meio de um índice secundário possui uma dependência de padrão de acesso que deve ser replicada no destino como um índice não primário ou uma estratégia de consulta diferente. A omissão desse padrão durante a migração resulta em um programa que executa sem erros, mas não consegue encontrar os registros que procura.
Bancos de dados GSAM
Os bancos de dados GSAM (Generalized Sequential Access Method) são a interface do IMS para processamento sequencial em lote, permitindo que programas COBOL em lote utilizem chamadas DL/I para o que é funcionalmente E/S de arquivos sequencial. Os bancos de dados GSAM não possuem hierarquias de segmentos; são estruturas sequenciais planas acessadas através do IMS para aproveitar os recursos de recuperação e reinicialização do IMS.
Os programas que utilizam bancos de dados GSAM são programas em lote que dependem do suporte a checkpoint/reinicialização do IMS para seu comportamento de recuperação. A migração deve preservar esse comportamento de recuperação ou substituí-lo por um mecanismo equivalente na plataforma de destino.
Construindo o Inventário de Dependências Pré-Migração
Uma análise completa de dependências do IMS gera seis entregáveis que, juntos, definem o escopo, os riscos e a sequência da migração.
Entregável 1: Mapeamento de PCB para banco de dados
Cada PCB em cada PSB corresponde a um DBD específico (um banco de dados IMS específico). Listar cada PCB em todos os PSBs e mapear cada um ao seu DBD produz a lista definitiva de quais programas têm permissão para acessar quais bancos de dados. Este é o ponto de partida para entender o escopo, mas superestima as dependências reais, pois os programas podem ter PSBs que incluem mais bancos de dados do que os que realmente utilizam.
Entregável 2: Inventário real de chamadas por programa
A análise das chamadas DL/I de cada programa COBOL gera a lista de uso real: quais PCBs cada programa realmente chama, quais códigos de função utiliza, quais tipos de segmento acessa e se usa SSAs qualificados (acesso por chave de segmento) ou navegação não qualificada (travessia posicional). Isso restringe o escopo das permissões definidas pelo PSB ao comportamento real do programa.
Entregável 3: Mapa de Uso de Relações Lógicas
A comparação do inventário de chamadas com os DBDs identifica quais chamadas GNP ou GN dos programas atravessam relações lógicas. Isso requer a análise não apenas do código-fonte COBOL e do PSB, mas também das estruturas DBD que definem quais relações pai-filho são físicas e quais são lógicas.
Entregável 4: Mapa de Utilização do Índice Secundário
Os programas que nomeiam bancos de dados de índices secundários em seus PSBs ou emitem chamadas com SSAs que referenciam campos de chave não raiz são identificados como usuários de índices secundários. O mapa documenta quais índices secundários existem, quais bancos de dados primários eles suportam e quais programas dependem deles.
Entregável 5: Distribuição dos tipos de chamadas por banco de dados
Para cada banco de dados IMS em questão, a distribuição dos tipos de chamadas entre todos os programas que o acessam indica a complexidade de sua migração:
- Bancos de dados acessados apenas por funções de leitura (GU, GN, GNP) são mais simples de migrar.
- Bancos de dados acessados por funções de retenção e atualizações (GHU + REPL, GHN + DLET) exigem replicação de integridade transacional.
- Bancos de dados com alto uso de GN indicam dependências de navegação posicional que requerem análise de ordenação.
- Bancos de dados com relações lógicas exigem semântica de junção entre bancos de dados no destino.
Entregável 6: Classificação de Riscos do Programa
Utilizando a distribuição de tipos de chamadas e o inventário de tipos de dependência, cada programa é classificado por risco de migração:
Programas que utilizam apenas GU e GNP com SSAs qualificados, acessam um único banco de dados sem relações lógicas e não possuem chamadas de retenção/atualização são os candidatos de menor risco para as primeiras ondas de migração. Programas que utilizam GN extensivamente, acessam múltiplos bancos de dados por meio de relações lógicas ou realizam sequências complexas de retenção/atualização são os de maior risco, exigindo a análise e validação mais rigorosas antes da migração.
O que a análise altera em relação ao planejamento migratório?
A análise de dependências não se limita a documentar o que existe, ela altera as decisões subsequentes.
Decisões de sequência. Programas que compartilham bancos de dados IMS por meio de relações lógicas não podem ser migrados independentemente. Se o Programa A lê um segmento filho lógico que possui um pai lógico no mesmo banco de dados que o segmento raiz do Programa B, migrar A sem migrar B (ou criar uma ponte) interrompe a migração de A. O grafo de dependências determina quais programas devem ser migrados juntos.
Decisões de projeto do alvo. A distribuição dos tipos de chamada informa como o esquema relacional de destino deve ser estruturado. Um relacionamento hierárquico pai-filho acessado exclusivamente por meio de chamadas GU e GNP qualificadas por chave se traduz perfeitamente em um relacionamento de chave estrangeira no destino. O mesmo relacionamento acessado por meio de chamadas GN com dependências posicionais exige que o esquema de destino preserve a ordenação equivalente, seja por meio de ORDER BY explícito, um campo de sequência ou um padrão de acesso diferente que alcance o mesmo resultado.
Decisões sobre o escopo da validação. A análise identifica quais programas são consumidores somente leitura de dados do IMS e quais são processadores de transações. Os programas somente leitura podem ser validados comparando os resultados de saída entre o sistema IMS original e o sistema migrado. Os processadores de transações exigem testes de equivalência transacional, garantindo que a mesma sequência de operações no sistema de destino produza alterações de estado de dados equivalentes às do sistema original.
Classificação de riscos. A relação lógica e as conclusões dos índices secundários são as principais entradas para a classificação de riscos. Todo programa de migração possui um registro de riscos. A análise de dependências do IMS indica à equipe quais entradas devem ser incluídas nesse registro.
Como SMART TS XL Realiza análise de dependência do IMS
SMART TS XL'S análise de código estático Analisa todas as chamadas DL/I de um programa COBOL, tanto as formas de interface de chamada EXEC DLI quanto xxxTDLI, extraindo o código da função, a referência PCB, o nome do segmento e a estrutura SSA de cada chamada. Isso produz o inventário de chamadas real no nível do programa, em todo o portfólio COBOL, sem exigir um sistema IMS em execução ou revisão manual de código.
O mapeamento de dependências de aplicativos amplia esse inventário para um grafo de dependências entre programas: quais programas compartilham acesso a quais bancos de dados IMS, quais programas usam os mesmos PCBs e quais padrões de acesso dos programas se sobrepõem de maneiras que exigem migração coordenada. Quando uma relação lógica conecta segmentos entre bancos de dados, o mapa de dependências representa essa conexão entre bancos de dados como uma relação explícita que deve ser preservada no sistema de destino.
A funcionalidade de análise de impacto responde à pergunta que toda equipe de migração deve responder antes da conversão de qualquer banco de dados: se este banco de dados IMS for migrado, quais programas serão afetados, quais padrões de acesso devem ser replicados e quais casos de teste devem ser validados para confirmar a equivalência? A resposta não é uma estimativa, mas sim uma lista enumerada derivada do inventário real de chamadas DL/I.
A capacidade de expansão do JCL adiciona o contexto operacional: quais etapas de trabalho do JCL invocam quais programas que acessam o IMS, em qual sequência e com quais especificações PSB. A cadeia de dependência operacional, a sequência de trabalhos em lote que processa os dados do IMS por meio de vários programas, é tão importante para o planejamento da migração quanto os padrões de acesso em nível de programa. Migrar o banco de dados sem migrar a orquestração de trabalhos em lote que o envolve resulta em um sistema que processa registros corretamente de forma isolada, mas falha em produção quando a sequência de trabalhos é executada.
Para equipes que realizam modernização legada dos sistemas apoiados por IMS, as evidências estruturais produzidas por SMART TS XL é a entrada para todas as decisões subsequentes de migração: quais programas migram em qual onda, quais bancos de dados podem ser convertidos independentemente e quais exigem conversão coordenada, quais padrões de acesso exigem reestruturação em vez de tradução direta. Conforme descrito no contexto de Migração de estruturas IMS e VSAM juntamente com programas COBOLA interconexão entre programas COBOL e estruturas de dados legadas significa que a migração de dados e a análise de código devem ocorrer em paralelo; o inventário de dependências é o mecanismo que torna possível o planejamento paralelo.
O inventário não é a migração.
A análise de dependências do IMS gera conhecimento. A migração ainda requer decisões, engenharia e validação. O que a análise altera é a qualidade das decisões, a abrangência do escopo da engenharia e a confiabilidade da validação.
As organizações que migram bancos de dados IMS com sucesso não são aquelas com os cronogramas mais agressivos ou os maiores orçamentos de migração. São aquelas que sabiam o que tinham antes de começar a migração: cada programa que acessava cada banco de dados, cada código de função que revelava o padrão de acesso de cada programa, cada relação lógica que criava dependências entre bancos de dados, cada índice secundário que fornecia um caminho de acesso que não sobreviveria à conversão sem replicação explícita.
Esse conhecimento não vem da documentação. Ele vem da análise do código.
