sábado, maio 16, 2026

Como o Superdescritor salva a performance do seu Programa Adabas

Se você trabalha com desenvolvimento em ambiente Mainframe, já deve ter ouvido a máxima: "MIPS é dinheiro". No Adabas, a diferença entre uma consulta que roda em milissegundos e um processo batch que arrasta o ambiente inteiro está na forma como você modela e acessa suas chaves de busca. Muitos desenvolvedores (especialmente os que estão começando no mundo Natural/Adabas) criam chaves de busca de qualquer jeito. O resultado? Consultas que geram leituras sequenciais pesadas, sobrecarregam a Inverted List no Associator e disparam o consumo de CPU. Hoje, vamos entender o verdadeiro "pulo do gato" da performance no Adabas: a diferença crucial entre Subdescritores e Superdescritores, e como o segundo pode salvar a sua aplicação.

Conceito Rápido

Antes de ir para o código, vamos abrir o capô do Adabas e entender o que cada um faz:

Subdescritor: É uma chave criada a partir de um pedaço de um campo existente.
Exemplo: Você tem o campo DATA-CONTRATO (AAAAMMDD), mas cria um Subdescritor apenas para o ano (AAAA).

Superdescritor: É o verdadeiro campeão da performance. Ele permite combinar múltiplos campos (ou pedaços deles) em uma única chave de busca no Associator.
Exemplo: Você combina COD-CLIENTE + ANO-CONTRATO em um único índice.

O problema: O FIND com múltiplos campos

Imagine que você precisa buscar os contratos de um cliente específico criados no ano de 2026. Uma abordagem muito comum (e altamente ineficiente) é escrever um FIND combinando campos normais no WITH. O que acontece por baixo dos panos? Quando você faz isso, o Adabas precisa ir até a Inverted List do Associator, ler todos os ISNs do cliente X, depois ler todos os ISNs do ano de 2026 e fazer um cruzamento lógico em memória (um AND de listas de ISNs) para só então devolver o resultado. Se o cliente tiver milhões de registros, o Associator vai sofrer, o consumo de MIPS vai para o espaço e a consulta vai demorar.

A Solução: O Superdescritor em Ação

Em vez de fazer o Adabas cruzar duas listas gigantescas no Associator, nós criamos um Superdescritor (vamos chamá-lo de S1) que já nasce com a combinação pronta: COD-CLIENTE + ANO-CONTRATO. Dessa forma, o Adabas não faz cruzamento nenhum. Ele vai direto na árvore de índices do Associator, localiza a chave exata (ex: 123452026) e traz os ISNs instantaneamente. Uma operação que demoraria minutos em arquivos com dezenas de milhões de registros passa a ser imediata.

Exemplo Prático em Natural: O Antes e o Depois

Para ficar claro, vamos ver como muda o código e o comportamento do banco de dados. 🔴 Abordagem Ruim (Consome MIPS e gera overhead no Associator) Neste cenário, estamos usando dois campos descritores separados. O Adabas terá que cruzar as duas listas de ISNs em tempo de execução.
* TRADICIONAL: Filtro composto por descritores separados
FIND CONTRATOS-VIEW WITH CLIENTE-ID = #CLI-PROCURADO
                     AND ANO-CONTRATO = '2026'
  /* O Adabas lê a lista do cliente, lê a lista do ano,
  /* faz a intersecção de ISNs e depois busca no DATA Storage.
  DISPLAY CONTRATO-NUM STATUS VALOR
END-FIND

O Pulo do Gato com Superdescritor

Aqui, usamos o Superdescritor SUPER-CLI-ANO (que é a fusão de CLIENTE-ID e ANO-CONTRATO).
* OTIMIZADO: Busca direta utilizando o Superdescritor (S1)
* O formato da busca concatena as duas variáveis em uma única chave
FIND CONTRATOS-VIEW WITH SUPER-CLI-ANO = #CHAVE-COMBINADA
  /* O Adabas vai direto no endereço exato da combinação.
  /* Zero cruzamento de listas, resposta instantânea!
  DISPLAY CONTRATO-NUM STATUS VALOR
END-FIND
Dica de Performance: Repare que no segundo exemplo, a busca lógica no Associator tornou-se de indexação direta. O ganho de velocidade aqui é exponencial conforme o tamanho do arquivo cresce.

Subdescritor vs. Superdescritor

Para não errar na arquitetura do seu arquivo, siga essa regra de ouro:
Cenário Descritor Justificativa
Preciso filtrar relatórios ou telas por apenas uma parte de um campo (ex: apenas o mês de uma data, ou os primeiros dígitos de um CEP). Sub Evita que você precise criar um campo redundante no Data Storage apenas para guardar um pedaço de informação.
Tenho telas de consulta ou processos batch repetitivos que filtram por dois ou mais campos fixos (ex: Empresa + Filial + Status). Super Evita o cruzamento de listas de ISNs no Associator. A combinação cria um atalho definitivo direto para o dado.

0 comentários:

Enviar um comentário