Análise da estrutura de arquivos VSAM para projetos de modernização de dados

A migração de dados não pode ocorrer isoladamente; ela deve evoluir em paralelo com os aplicativos COBOL que leem e gravam esses conjuntos de dados. Essa restrição define todo o desafio da modernização do VSAM. O VSAM (Virtual Storage Access Method) não é simplesmente um formato de arquivo. É o contrato de dados entre programas, a especificação implícita, definida apenas em entradas de descritores de arquivo e cláusulas SELECT, que governa como cada programa em um sistema corporativo produz e consome seus dados de negócios mais críticos. Uma única alteração no layout de um registro que não seja refletida em todos os programas que leem esse registro produz corrupção de dados que pode não ser detectada até que um relatório regulatório seja executado com dados que não significam mais o que o programa que os consumiu esperava.

As organizações que obtêm sucesso na modernização de dados VSAM não são aquelas que começam com o esquema de destino. São aquelas que começam com uma compreensão completa e baseada em evidências do conteúdo dos arquivos VSAM, como eles são estruturados, quais programas os acessam, em quais padrões e quais contratos implícitos existem entre produtores e consumidores. Essa compreensão, a análise da estrutura dos arquivos VSAM, é o pré-requisito para todas as decisões subsequentes: quais conjuntos de dados VSAM são mapeados para tabelas relacionais, quais exigem arquiteturas de destino diferentes, quais layouts de registro precisam de conversões de tipo de dados que preservem a precisão e quais conjuntos de dados compartilhados devem migrar como unidades coordenadas, em vez de independentemente.

As quatro organizações VSAM e o que cada uma exige

Os conjuntos de dados VSAM são apresentados em quatro organizações distintas. Cada uma possui uma característica estrutural diferente, um padrão de acesso típico diferente e um mapeamento natural diferente para arquiteturas de destino modernas. Tratar todos os conjuntos de dados VSAM de forma idêntica, convertendo-os em massa para tabelas relacionais, produz resultados que funcionam para alguns conjuntos de dados e apresentam desempenho ruim ou falham funcionalmente para outros.

KSDS, Key-Sequenced Data Set (Conjunto de Dados Sequenciado por Chave) , é a organização VSAM mais comum. Os registros são fisicamente ordenados por uma chave primária (a chave principal), permitindo tanto o acesso direto pela chave quanto o acesso sequencial na ordem da chave. Os arquivos KSDS podem opcionalmente ter índices alternativos, caminhos de chave secundários que permitem a recuperação por campos diferentes da chave principal. O destino natural para um KSDS é uma tabela relacional onde a chave principal se torna a chave primária e os índices alternativos se tornam índices SQL.

ESDS (Entry-Sequenced Data Set) armazena registros na ordem em que foram gravados. Não há chave; os registros são endereçados pelo seu deslocamento físico em bytes (RBA: Relative Byte Address). Arquivos ESDS são normalmente usados ​​para dados de log: trilhas de auditoria, diários de transações, fluxos de eventos. O destino natural para um ESDS é uma tabela relacional somente de acréscimo, um fluxo de eventos (tópico do Kafka) ou um banco de dados de séries temporais, dependendo de como os programas que consomem os dados os acessam.

RRDS (Relative Record Data Set) armazena registros de comprimento fixo endereçados por número de registro relativo. Cada posição no arquivo corresponde a um número de registro; posições podem estar vazias (excluídas). Arquivos RRDS são usados ​​em cenários de acesso direto onde o número do registro é significativo para a aplicação, frequentemente utilizados como tabelas de consulta simples ou armazenamento baseado em hash. O destino natural é uma tabela relacional com um identificador de sequência numérica, ou uma estrutura de consulta em memória se o conjunto de dados for pequeno e acessado com frequência.

LDS, ou Conjunto de Dados Linear, é um armazenamento endereçável por byte sem estrutura de registro visível para VSAM. É usado por aplicações (tipicamente DB2, cargas de trabalho Java ou programas personalizados) que gerenciam seu próprio formato interno dentro do intervalo de bytes do VSAM. Arquivos LDS não podem ser analisados ​​por meio de entradas FD COBOL padrão; sua estrutura existe apenas na camada de aplicação que os grava.

O resultado da análise para cada conjunto de dados deve identificar qual organização ele utiliza, pois a organização determina tudo o que vem depois: arquitetura de destino, padrão de acesso e a análise específica necessária para compreender sua estrutura.

O problema da análise do layout do registro

O layout do registro é a dimensão analiticamente mais complexa da análise da estrutura VSAM. Ao contrário de um esquema relacional, onde cada coluna tem um tipo, nome e restrição definidos e impostos pelo mecanismo do banco de dados, os registros VSAM não possuem uma estrutura autodescritiva. O layout existe inteiramente na entrada FD do COBOL, e as entradas FD raramente são simples.

Inscrições FD e membros COPY

A estrutura de registro de um conjunto de dados VSAM é definida na entrada FILE DESCRIPTION (FD) da DATA DIVISION do COBOL. Em bases de código bem mantidas, a entrada FD referencia um membro COPY, um copybook compartilhado que define o layout do registro e é incluído por todos os programas que acessam o conjunto de dados.

cobol

       FILE SECTION.
       FD  CUSTOMER-FILE
           LABEL RECORDS ARE STANDARD
           RECORD CONTAINS 250 CHARACTERS.
       01  CUSTOMER-RECORD.
           COPY CUSTMSTR.

O membro COPY CUSTMSTR define o layout real do campo. Se 47 programas incluírem CUSTMSTR, então 47 programas compartilham uma dependência do layout de registro que ele define. Uma renomeação de campo em CUSTMSTR Afeta todos os 47. Este é o problema de acoplamento do copybook aplicado aos dados: o layout de registro VSAM é uma dependência compartilhada que não pode ser alterada sem a coordenação de todos os programas que o utilizam.

Para a análise de migração, cada entrada de FD (função determinante) deve ser rastreada até seu copybook, e cada copybook deve ser mapeado para cada programa que o inclui. O grafo de dependência de layout compartilhado é a base para a compreensão do escopo da migração.

REDEFINIÇÃO: Vários layouts, um único registro

O REDEFINES A cláusula REDEFINES é onde a análise de registros VSAM se torna verdadeiramente complexa. A cláusula REDEFINES permite que diferentes interpretações de campos se sobreponham ao mesmo armazenamento físico. Um registro VSAM que contém um código de tipo de transação pode usar REDEFINES para interpretar os bytes restantes de maneira diferente, dependendo desse código.

cobol

       01  TRANSACTION-RECORD.
           05  TXN-TYPE        PIC X(2).
           05  TXN-COMMON-DATA PIC X(48).
           05  TXN-DETAIL      REDEFINES TXN-COMMON-DATA.
               10  TXN-PAYMENT.
                   15  PAY-AMOUNT     PIC S9(11)V99 COMP-3.
                   15  PAY-CURRENCY   PIC X(3).
                   15  PAY-METHOD     PIC X(2).
                   15  FILLER         PIC X(28).
           05  TXN-WITHDRAWAL  REDEFINES TXN-COMMON-DATA.
               10  WDR-AMOUNT     PIC S9(11)V99 COMP-3.
               10  WDR-ACCOUNT    PIC 9(12).
               10  WDR-BRANCH     PIC 9(5).
               10  FILLER         PIC X(18).

Este disco não tem apenas um formato, mas três, dependendo de TXN-TYPENo esquema relacional de destino, isso normalmente requer um design de tabela polimórfica (tabela única com colunas anuláveis ​​para cada variante), um design normalizado (linha pai mais linhas filhas específicas do tipo) ou uma coluna JSON contendo os dados da variante. Nenhuma dessas decisões pode ser tomada sem analisar o quê? TXN-TYPE Os dados contêm valores que indicam quais variantes do REDEFINES são efetivamente utilizadas.

Uma análise completa do layout do registro deve:

• Identifique todas as hierarquias REDEFINES em cada entrada FD.
• Determine qual variante de REDEFINES está ativa em quais condições (requer análise da lógica do programa, não apenas análise de dependências funcionais).
• Documente os tipos de campo, comprimentos e precisão decimal compactada para cada variante.
• Recomende a estratégia de normalização apropriada para o esquema de destino.

COMP-3 e Precisão Numérica

COBOL's PIC S9(11)V99 COMP-3 (decimal compactado) possui características específicas de precisão e escala que não têm equivalente direto nos tipos de dados padrão do SQL. V indica um ponto decimal implícito; o valor é armazenado como um número inteiro com uma escala implícita de 2 casas decimais. COMP-3 Cada byte contém dois dígitos decimais, sendo que o último meio byte contém o sinal.

Quando este campo for migrado para um banco de dados relacional, o destino SQL correto será DECIMAL(13, 2), não FLOAT, o que introduziria erros de arredondamento, e não INTEGER, o que resultaria na perda das casas decimais. Para sistemas financeiros onde os campos COMP-3 armazenam valores monetários, o requisito de precisão não é negociável. Uma migração que converte PIC S9(11)V99 COMP-3 Converter para um tipo de ponto flutuante no esquema de destino introduz erros de arredondamento que se acumulam em execuções em lote e podem afetar os relatórios regulatórios.

Cada campo COMP-3 em cada entrada FD deve ser documentado com sua precisão, escala e convenção de sinal exatas antes do início do projeto do esquema de destino.

Analisando padrões de acesso VSAM em código-fonte COBOL

A entrada FD descreve o conteúdo do registro. A instrução PROCEDURE DIVISION em COBOL descreve como o programa o utiliza. Ambas são necessárias para uma análise estrutural completa. A análise de padrões de acesso examina cada verbo de acesso a arquivos em todos os programas que interagem com o conjunto de dados.

A cláusula SELECT: Primeiro sinal

A cláusula SELECT na DIVISÃO DE AMBIENTE define como o programa COBOL acessará o arquivo VSAM:

cobol

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT CUSTOMER-FILE
               ASSIGN TO CUSTFILE
               ORGANIZATION IS INDEXED
               ACCESS MODE IS DYNAMIC
               RECORD KEY IS CUST-PRIME-KEY
               ALTERNATE RECORD KEY IS CUST-ALT-KEY
                   WITH DUPLICATES
               FILE STATUS IS WS-CUST-STATUS.

Esta cláusula SELECT revela:

• ORGANIZATION IS INDEXED → KSDS
• ACCESS MODE IS DYNAMIC → O programa utiliza acesso sequencial e aleatório.
• ALTERNATE RECORD KEY IS CUST-ALT-KEY WITH DUPLICATES → Existe um índice alternativo e este programa o utiliza.

O modo de acesso dinâmico é particularmente significativo: um programa que acessa um KSDS no modo DINÂMICO pode usar READ com uma chave para acesso direto e READ NEXT para varredura sequencial a partir de um ponto posicionado. Ambos os padrões de acesso devem ser replicados no destino, o que pode exigir suporte tanto para pesquisa direta (consulta por chave primária) quanto para varredura por intervalo (travessia ordenada) no esquema relacional.

Verbos de acesso e suas implicações migratórias

Cada verbo de acesso a arquivo revela uma dimensão diferente de como o programa interage com o conjunto de dados VSAM:

LEIA (diretamente): READ CUSTOMER-FILE KEY IS WS-CUST-KEY, pesquisa direta por chave. Mapeia para SELECT ... WHERE primary_key = ?A maioria dos programas KSDS usa esse padrão; ele se traduz diretamente em uma pesquisa indexada relacional.

LEIA (sequencialmente): READ CUSTOMER-FILE NEXT RECORD, varredura sequencial a partir da posição atual. Mapeia para SELECT ... ORDER BY primary_key com posicionamento do cursor. A dependência de ordenação implícita, programas que dependem da ordem natural das chaves do VSAM para processamento sequencial, deve ser preservada explicitamente no destino.

COMEÇAR: START CUSTOMER-FILE KEY >= WS-SEARCH-KEY seguido READ NEXT, varredura de intervalo a partir de uma posição de chave parcial. Mapeia para uma consulta de intervalo: SELECT ... WHERE primary_key >= ? ORDER BY primary_keyOs programas que utilizam START estabelecem um limite inferior para a varredura sequencial; este é um padrão de acesso crítico para arquivos KSDS que não possui um equivalente simples, a menos que a tabela de destino tenha a mesma ordenação de chaves.

ESCREVER: Insere um novo registro por chave. Mapeia para INSERT INTOSe o arquivo VSAM tiver índices alternativos, a gravação deve manter a consistência com esses índices. No VSAM, isso é automático; em um banco de dados relacional, é necessário um gatilho de banco de dados ou código em nível de aplicativo para manter tabelas de índice secundárias equivalentes.

REESCREVER: Atualiza um registro no local. O registro deve estar atualmente ativo (após uma LEITURA com intenção de retenção). Mapeia para UPDATE ... WHERE primary_key = ?REWRITE é um padrão de leitura-modificação-escrita; a migração deve preservar a integridade transacional durante a leitura e a escrita.

DELETE: Remove um registro por chave. Em arquivos KSDS, DELETE é uma exclusão física. Programas que esperam que o espaço excluído fique indisponível para futuras varreduras sequenciais dependem desse comportamento de exclusão física; uma exclusão lógica (flag de exclusão lógica) no destino não produz comportamento equivalente, a menos que todos os programas que consomem o registro sejam atualizados para filtrar registros excluídos logicamente.

Uso alternativo do índice: a dependência oculta

Os índices alternativos em arquivos KSDS são uma das dependências mais frequentemente negligenciadas na migração de VSAM. Um índice alternativo permite que um programa acesse um KSDS por um campo diferente da chave principal. O índice alternativo é, em si, um conjunto de dados VSAM separado (um PATH) que deve ser mantido sincronizado com o cluster base.

Um programa que acessa CUSTOMER-FILE através de sua chave alternativa CUST-ALT-KEY Possui uma dependência que é invisível se apenas a entrada FD do cluster base for analisada. A migração deve:

1. Identifique quais programas usam quais chaves alternativas (visíveis na cláusula SELECT). ALTERNATE RECORD KEY declarações)
2. Mapeie cada chave alternativa para o índice SQL equivalente na tabela de destino.
3. Garanta que as operações INSERT e DELETE na tabela de destino mantenham automaticamente o equivalente ao índice alternativo, normalmente por meio de índices SQL exclusivos ou não exclusivos que o mecanismo do banco de dados mantém de forma transparente.

A análise deve enumerar todos os índices alternativos para cada conjunto de dados KSDS e mapear cada um para os programas que os utilizam.

O Problema do Conjunto de Dados Compartilhado: Contratos de Dados Implícitos

Os arquivos VSAM são frequentemente compartilhados entre vários programas e várias etapas de trabalho JCL. Esse compartilhamento cria contratos de dados implícitos, acordos entre programas sobre o layout dos registros, intervalos de chaves e padrões de acesso que não existem em nenhum outro lugar além do próprio código.

A dependência do conjunto de dados compartilhado possui duas dimensões:

Relações produtor-consumidor. O Programa A grava registros que o Programa B lê. O layout do registro, os valores das chaves e a ordem que o Programa A produz devem corresponder exatamente ao que o Programa B espera consumir. Se A e B forem migrados independentemente para esquemas de destino diferentes sem coordenar o contrato de dados compartilhados, o resultado será uma corrupção silenciosa de dados: as leituras de B serão bem-sucedidas no banco de dados de destino, mas retornarão dados em um formato que a lógica de B não consegue processar corretamente.

Acesso simultâneo entre etapas de trabalho. Um fluxo de trabalho JCL pode ter várias etapas, cada uma executando um programa diferente no mesmo conjunto de dados VSAM em sequência. A Etapa 1 grava, a Etapa 2 lê e transforma, e a Etapa 3 grava os resultados. A migração deve preservar essa dependência sequencial; a ordem em que os programas acessam e modificam o conjunto de dados compartilhado faz parte da especificação de comportamento do sistema.

Uma análise completa de um conjunto de dados compartilhados deve:

• Enumere todos os conjuntos de dados VSAM e todos os programas que acessam esses conjuntos de dados.
• Classifique o acesso de cada programa como produtor (ESCRITA/REESCRITA/EXCLUSÃO), consumidor (LEITURA) ou ambos.
• Documente o contexto do job JCL em que cada programa é executado, especificando qual etapa, em qual job e em qual cadeia de dependências do agendador.
• Identificar pares produtor-consumidor onde o formato de saída do produtor deve corresponder exatamente ao formato de entrada esperado pelo consumidor.

Essa análise não pode ser feita examinando um único programa isoladamente. Ela requer uma análise estrutural que abranja vários programas e diferentes JCLs (Jangling Components Library).

Entregáveis ​​da Pré-Migração: O Que a Análise Deve Produzir

Uma análise estrutural VSAM suficiente para o planejamento da modernização de dados produz seis entregáveis:

Entregável 1: Inventário do conjunto de dados VSAM

Cada conjunto de dados VSAM no ambiente, com: organização do conjunto de dados (KSDS/ESDS/RRDS/LDS), comprimento médio e máximo dos registros, contagem estimada de registros (a partir de parâmetros SPACE do JCL ou entradas do catálogo), estrutura da chave (deslocamento da chave primária, comprimento; estruturas de chave alternativas) e se o conjunto de dados possui índices alternativos.

Entregável 2: Catálogo de Layout de Registros

Para cada conjunto de dados, cada entrada FD e os copybooks aos quais ela faz referência, com: todas as definições de campo, incluindo hierarquias REDEFINES, cada campo COMP-3 com sua precisão e escala exatas, cada campo binário (COMP/COMP-5) com seu comprimento em bytes, cada elemento de comprimento variável (OCCURS DEPENDING ON com seu campo de controle) e cada variante condicional ou de layout implícita por REDEFINES.

Entregável 3: Classificação de Padrões de Acesso por Programa

Para cada programa que acessa cada conjunto de dados: as características da cláusula SELECT (organização, modo de acesso, uso de chaves alternativas), o conjunto completo de verbos de acesso usados ​​(READ/START/WRITE/REWRITE/DELETE), se o programa usa acesso sequencial e depende da ordem das chaves, quais índices alternativos o programa usa e se o programa possui padrões de leitura-modificação-escrita (requisitos de transação implícitos).

Entregável 4: Mapa do Conjunto de Dados Compartilhados

Um grafo direcionado onde os nós representam conjuntos de dados e programas VSAM, e as arestas representam relações de acesso com seus respectivos tipos (leitura/gravação). O grafo mostra cada produtor, cada consumidor, pares produtor-consumidor e o contexto da sequência de tarefas JCL para cada acesso.

Entregável 5: Recomendações de Esquema de Destino

Para cada conjunto de dados VSAM, a arquitetura de destino recomendada com base em sua organização e padrões de acesso é a seguinte:

Tipo VSAM	Padrão de acesso primário	Alvo recomendado
KSDS, acesso direto somente por chave.	Pesquisas de pontos por chave primária	Tabela relacional, indexada
KSDS, com INICIAR/LER A SEGUIR	Varreduras de alcance em ordem de teclas	Tabela relacional com índice agrupado
KSDS com índices alternativos	Acesso por chave de múltiplos caminhos	Tabela relacional com múltiplos índices
ESDS, somente para anexação	Acréscimo sequencial, sem chave	Tabela somente para anexação, fluxo de eventos ou log
ESDS, com acesso RBA	Posicionamento com deslocamento de byte	Armazenamento de objetos com índice de metadados
RRDS	Acesso ao número de registro	Tabela relacional com coluna de sequência
KSDS grande (a granel, analítico)	Varreduras sequenciais completas	Armazenamento colunar ou lago de dados
LDS	Formato interno gerenciado por aplicativo	Requer análise da camada de aplicação.

Entregável 6: Cadastro de Campos Sensíveis à Precisão

Todos os campos COMP-3, COMP, COMP-5 e de ponto flutuante em todos os conjuntos de dados, com sua definição COBOL, o mapeamento correto do tipo de dados SQL e um indicador para qualquer campo cujo mapeamento exija validação de precisão antes e depois da migração.

O que diferencia a análise VSAM da análise de esquemas relacionais?

Equipes com experiência em migração entre bancos de dados relacionais às vezes subestimam a análise VSAM porque aplicam o modelo mental de migração de esquema: extrair o DDL, redesenhar o esquema, migrar os dados. O VSAM não possui DDL no sentido de banco de dados. O esquema é distribuído por todo o código-fonte, em entradas de descritores de arquivo, em copybooks, em cláusulas SELECT e na lógica PROCEDURE DIVISION que determina qual variante REDEFINES está ativa para qualquer registro.

Três propriedades tornam a análise VSAM estruturalmente diferente:

O esquema reside no código. O layout de registro para um conjunto de dados VSAM é definido no código-fonte COBOL, não em um catálogo de banco de dados. Encontrá-lo exige analisar o código-fonte. Alterá-lo exige coordenar todos os programas que compartilham o copybook. Compreender todas as suas variantes exige analisar a lógica do programa, não apenas a entrada da função determinante.

Os padrões de acesso estão implícitos no comportamento do programa. Um banco de dados relacional expõe os padrões de consulta por meio de planos EXPLAIN e logs de consulta. Os padrões de acesso VSAM são visíveis apenas na DIVISÃO DE PROCEDIMENTOS dos programas que acessam o arquivo. Compreender se um programa depende de ordenação de chaves, acesso a índices alternativos ou varredura de intervalo requer análise de código.

Conjuntos de dados compartilhados criam contratos ocultos. Em um banco de dados relacional, o esquema é um artefato de nível de banco de dados que todos os consumidores compartilham e visualizam. No VSAM, o layout do registro está incorporado no copybook de cada programa. Dois programas podem ter cópias divergentes do que é nominalmente o mesmo layout de registro, e descobrir essa divergência requer a comparação das definições do copybook entre os programas, e não a inspeção de uma única definição de esquema.

Como SMART TS XL Realiza análise estrutural VSAM

SMART TS XL'S análise de código estático Analisa cada elemento da estrutura VSAM existente no código-fonte COBOL: entradas FD, expansões de membros COPY, declarações da cláusula SELECT (organização, modo de acesso, especificações de chave primária e alternativa) e cada verbo de acesso a arquivos na PROCEDURE DIVISION. Para cada conjunto de dados VSAM, a análise produz a classificação do padrão de acesso, o layout do registro com resolução completa de REDEFINES e o registro de campos COMP-3 com metadados de precisão.

O mapeamento de dependências de aplicativos constrói o mapa do conjunto de dados compartilhado: cada programa que acessa cada conjunto de dados VSAM, classificado por tipo de acesso, com os relacionamentos produtor-consumidor identificados e o grafo de compartilhamento do copybook resolvido. Quando 47 programas compartilham um copybook que define um layout de registro VSAM, o mapa de dependências torna todos os 47 visíveis antes de qualquer decisão de migração ser tomada, e não depois que uma alteração de layout tenha afetado 47 programas de maneiras inesperadas.

A capacidade de expansão do JCL fornece o contexto operacional: quais etapas do job JCL referenciam quais conjuntos de dados VSAM em suas instruções DD, em qual sequência e em quais fluxos de trabalho. Os relacionamentos produtor-consumidor que existem no nível do job JCL, onde a Etapa 1 grava em um conjunto de dados VSAM que a Etapa 3 lê, são visíveis na análise de dependência do JCL, permitindo o sequenciamento da migração que preserva as dependências de ordem operacional impostas pelo agendamento em lote.

A funcionalidade de análise de impacto responde à pergunta que precede toda decisão de migração VSAM: se o layout deste conjunto de dados for alterado, quais programas serão afetados? O escopo do impacto, ou seja, todos os programas que compartilham o copybook relevante, todas as etapas JCL que fazem referência ao conjunto de dados, é enumerado antes do início de qualquer trabalho de migração, fornecendo a base para um planejamento de migração coordenado, em vez de descobrir os programas afetados um programa com problemas de cada vez.

A funcionalidade de busca corporativa torna todo o inventário VSAM consultável em todo o programa de modernização: encontre todos os programas que acessam um conjunto de dados VSAM específico, todos os copybooks que definem um layout de registro específico, todos os programas que usam padrões START/READ NEXT (indicando dependências de ordenação), todos os campos definidos como COMP-3 (que exigem mapeamento de destino com reconhecimento de precisão), em segundos, em milhões de linhas de COBOL.

Conforme descrito no contexto de Migração de estruturas de dados IMS e VSAM juntamente com programas COBOLA migração de dados e a análise de código devem prosseguir em paralelo. SMART TS XLA análise estrutural VSAM fornece o inventário que torna esse paralelismo viável, os layouts de registro compartilhados, os padrões de acesso e os relacionamentos produtor-consumidor que determinam se a migração de dados pode prosseguir de forma independente ou se deve ser coordenada com as alterações do programa.

A estrutura que você entende é a estrutura para a qual você pode migrar.

A análise da estrutura de arquivos VSAM não é um custo adicional em um programa de modernização. Ela é a base para a tomada de decisões. O esquema de destino não pode ser projetado sem o conhecimento das variantes de layout de registro. A migração não pode ser sequenciada sem o conhecimento das relações produtor-consumidor. A precisão dos campos COMP-3 não pode ser preservada sem saber quais campos exigem tipos de destino com reconhecimento decimal.

Todo programa de modernização que ignora essa análise descobre o que deixou passar durante a execução da migração: quando uma variante REDEFINES não analisada produz registros malformados no destino; quando um conjunto de dados compartilhado é migrado sem a coordenação de todos os seus consumidores; quando uma varredura de intervalo que dependia da ordenação de chaves do VSAM retorna resultados em ordem indefinida em uma tabela de destino que não foi projetada com um índice clusterizado. Essas descobertas durante a execução custam muito mais do que a análise teria custado durante o planejamento.

Primeiro, entenda a estrutura. Depois, migre os dados. A sequência não é uma mera formalidade. É a diferença entre uma migração que produz resultados corretos e outra que gera dados aparentemente corretos até a primeira auditoria regulatória.