Bellacosa Mainframe e o ims db

☕💣🚀 PADAWAN, O IMS NÃO É UM BANCO DE DADOS. É UMA FORMA DIFERENTE DE ENXERGAR O UNIVERSO DOS DADOS!

Entendendo IMS DB, DBD, PSB, PCB, DL/I e a Arquitetura que Continua Sustentando Bancos, Operadoras e Governos Quase 60 Anos Depois

Se você vem do mundo SQL, provavelmente acredita que um banco de dados é composto por tabelas.

Clientes.

Pedidos.

Produtos.

Movimentos.

Tudo ligado por chaves primárias e estrangeiras.

Mas existe um detalhe curioso.

Quando os engenheiros da IBM começaram a desenvolver o IMS para atender aos requisitos do Projeto Apollo da NASA, eles não pensavam em tabelas.

Pensavam em relacionamentos naturais.

Pensavam em hierarquias.

Pensavam em estruturas onde um elemento pertence a outro elemento, que pertence a outro elemento, formando uma árvore de informações.

E é exatamente aí que nasce uma das maiores diferenças filosóficas entre o IMS e praticamente todos os bancos relacionais modernos.

No IMS, os dados não vivem em tabelas.

Eles vivem em famílias.

Antes de Entender IMS, Esqueça o SQL

Esse é provavelmente o conselho mais importante para qualquer desenvolvedor iniciando no IMS.

Enquanto no SQL você pergunta:

SELECT *
FROM CLIENTE
WHERE CPF='12345678900'

No IMS você não faz perguntas.

Você navega.

Essa diferença parece pequena.

Mas muda completamente a forma de pensar.

Imagine uma estrutura bancária simplificada:

CLIENTE
 |
 +-- CONTA
 |     |
 |     +-- MOVIMENTO
 |
 +-- CARTAO

Essa árvore não representa apenas um desenho.

Ela representa a forma física como os dados estão organizados.

O IMS sabe que uma conta pertence a um cliente.

Sabe que um movimento pertence a uma conta.

Sabe que um cartão pertence a um cliente.

Ele não precisa descobrir isso durante a execução.

Ele já nasceu sabendo.

É por isso que, mesmo décadas depois de sua criação, continua entregando níveis de desempenho impressionantes.

O Mundo Segundo o IMS

O IMS enxerga qualquer banco de dados através de alguns conceitos fundamentais.

Root

Todo banco IMS possui um ponto de partida.

Chamamos esse segmento de Root.

Em um banco de clientes:

CLIENTE

poderia ser o segmento raiz.

Tudo começa nele.

Parent

O pai.

O segmento imediatamente acima.

CLIENTE
 |
CONTA

CLIENTE é pai de CONTA.

Child

O filho.

O segmento imediatamente abaixo.

CLIENTE
 |
CONTA

CONTA é filho de CLIENTE.

Twins

Aqui aparece um conceito clássico do IMS.

Imagine:

CLIENTE
 |
 +-- CONTA 001
 |
 +-- CONTA 002
 |
 +-- CONTA 003

As três contas pertencem ao mesmo pai.

Elas são chamadas de Twins.

Ou gêmeos.

Compreender esse conceito é fundamental porque várias operações do DL/I trabalham justamente percorrendo esses irmãos dentro da hierarquia.

DBD: O DNA do Banco

Nenhum banco IMS nasce sem uma DBD.

Data Base Description.

Se você fosse construir um prédio, precisaria de uma planta.

No IMS acontece exatamente a mesma coisa.

A DBD é a planta arquitetônica do banco.

Nela definimos:

Segmentos
Hierarquia
Campos-chave
Tamanhos
Métodos de acesso
Estruturas físicas

Sem DBD não existe banco.

É ela que informa ao IMS como os dados serão armazenados e como se relacionam.

Por isso muitos administradores IMS dizem:

"Se você entender a DBD, entenderá o banco inteiro."

O Segredo Que Faz o IMS Ser Tão Rápido

Muitos profissionais acreditam que o desempenho do IMS está relacionado apenas ao hardware do mainframe.

Isso é apenas parte da história.

O verdadeiro segredo está na previsibilidade.

Quando um banco relacional recebe uma consulta, ele precisa decidir:

Qual índice utilizar
Qual caminho seguir
Qual plano gerar

O IMS não faz isso.

O caminho já está definido.

Você entra pelo Root.

Percorre os filhos.

Chega ao destino.

Sem surpresas.

Sem otimizadores.

Sem replanejamento.

Sem milhões de possibilidades.

É uma filosofia muito próxima de uma estrada ferroviária.

O trem sabe exatamente por onde vai passar.

PSB: O Contrato de Acesso

Uma dúvida muito comum entre iniciantes é:

"Se a DBD define o banco, por que existe a PSB?"

Porque nem todo programa deve enxergar tudo.

Imagine um banco de dados contendo:

CLIENTE
 |
 +-- DADOS FINANCEIROS
 |
 +-- CARTÕES
 |
 +-- LIMITE DE CRÉDITO
 |
 +-- ENDEREÇOS

O sistema de cobrança talvez precise acessar apenas:

CLIENTE
 |
 +-- DADOS FINANCEIROS

Já o sistema de cartões pode precisar de outra visão.

É exatamente isso que a PSB resolve.

Ela define a visão do programa sobre o banco.

PCB: Os Óculos do Programa

A PCB funciona como um conjunto de lentes.

O banco continua sendo o mesmo.

Mas cada programa enxerga apenas aquilo que lhe foi permitido.

Essa abordagem parece extremamente moderna.

E de certa forma é.

Hoje falamos muito sobre:

Least Privilege
Zero Trust
Segurança por contexto

O IMS implementava conceitos semelhantes décadas atrás.

DL/I: O Porteiro do Banco de Dados

Nenhum programa conversa diretamente com o banco.

Quem faz essa intermediação é o DL/I.

Data Language One.

Pense nele como um porteiro extremamente rigoroso.

O programa faz um pedido.

O DL/I verifica se ele possui autorização.

Se possuir, executa.

Caso contrário, devolve erro.

Esse modelo garante integridade e evita que aplicações corrompam estruturas críticas.

Os Comandos Que Todo Programador IMS Precisa Conhecer

Se existe um momento em que o desenvolvedor COBOL percebe que entrou definitivamente no universo IMS, esse momento acontece quando ele escreve seu primeiro:

CALL 'CBLTDLI'

A partir daí, tudo muda.

Em um banco relacional você escreve comandos SQL.

No IMS você conversa com o DL/I.

Cada solicitação ao banco é feita através de uma função específica.

Essas funções foram criadas há décadas, mas continuam extremamente elegantes.

Na prática, quase todo sistema IMS utiliza um conjunto relativamente pequeno de comandos.

Domine esses comandos e você compreenderá boa parte do funcionamento do banco.

GU — GET UNIQUE

O GU é normalmente o primeiro comando aprendido por qualquer programador IMS.

Sua função é localizar um segmento específico.

Imagine um banco contendo clientes.

Você conhece o CPF ou a chave do cliente.

O GU será utilizado para localizar exatamente aquela ocorrência.

Exemplo conceitual:

CLIENTE
   CPF = 12345678900

O programa envia uma SSA qualificada contendo a chave desejada.

O DL/I procura o segmento.

Se encontrar:

STATUS = BRANCO

Sucesso.

Se não encontrar:

STATUS = GE

Segmento inexistente.

Analogia do Mundo Real

Imagine uma biblioteca.

Você possui o número exato do livro.

Vai diretamente até ele.

Isso é um GU.

Não existe pesquisa sequencial.

Não existe navegação.

Você sabe exatamente o que procura.

GN — GET NEXT

Agora imagine uma situação diferente.

Você não quer um cliente específico.

Quer percorrer todos os clientes.

Nesse caso usamos:

GN

Get Next.

O GN realiza leitura sequencial.

Cada chamada retorna o próximo segmento da hierarquia.

Exemplo:

CLIENTE 001
CLIENTE 002
CLIENTE 003
CLIENTE 004

Primeiro GN:

CLIENTE 001

Segundo GN:

CLIENTE 002

Terceiro GN:

CLIENTE 003

E assim sucessivamente.

O GN é o Cursor Original

Muito antes dos cursores SQL se popularizarem, o IMS já trabalhava dessa forma.

Você se posiciona.

Vai pedindo o próximo registro.

E continua navegando.

GNP — GET NEXT WITHIN PARENT

Esse comando costuma causar confusão no início.

Mas depois se torna um dos favoritos dos desenvolvedores IMS.

O GNP significa:

GET NEXT WITHIN PARENT

Ou seja:

"Traga o próximo filho dentro do mesmo pai."

Imagine:

CLIENTE
 |
 +-- CONTA 001
 |
 +-- CONTA 002
 |
 +-- CONTA 003

Após localizar o CLIENTE, podemos percorrer apenas suas contas.

Primeiro GNP:

CONTA 001

Segundo:

CONTA 002

Terceiro:

CONTA 003

Observe a diferença.

O GN percorre toda a hierarquia.

O GNP permanece dentro do mesmo pai.

O Poder da Paternidade

Aqui aparece um conceito clássico do IMS.

Chamado:

PARENTAGE

Ou simplesmente:

PATERNIDADE

Quando um GU ou GN encontra um segmento, o IMS estabelece um contexto.

Esse contexto define quem é o pai atual.

O GNP utiliza exatamente esse contexto.

Por isso ele só funciona adequadamente após um posicionamento anterior.

GHU — GET HOLD UNIQUE

Até agora vimos apenas leitura.

Mas o que acontece quando queremos alterar um segmento?

Entramos no território do HOLD.

O GHU funciona exatamente como o GU.

A diferença é que ele trava o segmento.

GET HOLD UNIQUE

É como reservar uma vaga de estacionamento.

Você não apenas localiza.

Você impede que outro programa altere aquele registro simultaneamente.

Exemplo Bancário

Imagine duas aplicações alterando o mesmo saldo.

Sem controle:

Programa A -> Saldo = 100
Programa B -> Saldo = 100

A altera para:

B altera para:

Qual valor deve permanecer?

Problema clássico.

O HOLD existe justamente para evitar esse tipo de situação.

GHN — GET HOLD NEXT

Agora misturamos:

GN

com

HOLD

Resultado:

GHN

Leitura sequencial com bloqueio.

Muito utilizado em processos batch de atualização.

GHNP — GET HOLD NEXT WITHIN PARENT

É o equivalente ao:

GNP

porém mantendo lock nos segmentos retornados.

Extremamente comum em rotinas que precisam atualizar diversos filhos do mesmo pai.

ISRT — INSERT

Chegamos ao comando responsável por criar novos segmentos.

ISRT

Insert.

Imagine um novo cliente.

Antes:

CLIENTE
 |
 +-- JOÃO
 |
 +-- MARIA

Após o ISRT:

CLIENTE
 |
 +-- JOÃO
 |
 +-- MARIA
 |
 +-- CARLOS

O segmento passa a existir fisicamente no banco.

O Erro Clássico do ISRT

Todo iniciante já viu isso.

Status:

II

Segmento já existe.

Normalmente significa:

Chave duplicada
Inserção repetida
Violação de regra de unicidade

REPL — REPLACE

O REPL altera um segmento existente.

Mas existe uma regra extremamente importante.

Antes do REPL deve existir um HOLD.

Exemplo:

GHU

seguido de:

REPL

Sem HOLD:

DJ

Erro.

Um dos status mais famosos do IMS.

Por Que Essa Regra Existe?

Porque o IMS precisa garantir que ninguém modificou o segmento entre a leitura e a atualização.

É um mecanismo de integridade extremamente robusto.

DLET — DELETE

Responsável pela remoção de segmentos.

Assim como o REPL, exige HOLD.

Fluxo correto:

GHU

GHN

seguido por:

DLET

O Efeito Cascata do DLET

Aqui existe uma característica muito interessante.

Imagine:

CLIENTE
 |
 +-- CONTA
 |     |
 |     +-- MOVIMENTO

Se você apagar o ROOT:

CLIENTE

Todos os dependentes desaparecem.

Automaticamente.

O IMS entende que não pode existir um filho sem pai.

Essa regra faz parte da própria filosofia hierárquica do banco.

O Ciclo Completo de Atualização

Em sistemas IMS, a sequência clássica de alteração costuma ser:

1. GHU
2. Verificar STATUS
3. Alterar IO-AREA
4. REPL
5. Verificar STATUS

Exemplo conceitual:

CALL 'CBLTDLI' USING GHU
                     PCB
                     IOAREA
                     SSA.

IF STATUS = SPACES
   MOVE NOVO-VALOR TO CAMPO
   CALL 'CBLTDLI' USING REPL
                        PCB
                        IOAREA
END-IF.

Esse padrão aparece em milhares de programas IMS ao redor do mundo.

O Verdadeiro Segredo dos Comandos DL/I

Quando observamos GU, GN, GNP, GHU, GHN, GHNP, ISRT, REPL e DLET, podemos ter a impressão de que são apenas comandos antigos.

Mas existe uma elegância escondida.

Cada função foi projetada para trabalhar naturalmente com estruturas hierárquicas.

Enquanto bancos relacionais precisam descobrir relacionamentos durante a execução, o IMS simplesmente navega pela árvore.

Por isso um programador IMS experiente raramente pensa em registros isolados.

Ele pensa em:

Raiz
Pai
Filho
Gêmeos
Caminho de navegação
Posicionamento

E é exatamente essa mudança de mentalidade que transforma um desenvolvedor COBOL comum em um verdadeiro especialista em IMS DB.

Porque no final das contas, Padawan, programar IMS não é apenas acessar dados.

É aprender a navegar por uma civilização hierárquica construída para sobreviver às décadas. ☕💣🚀

O Que Todo Desenvolvedor COBOL Precisa Entender Sobre IMS

Se você chegou até aqui, provavelmente percebeu que programar IMS não significa apenas aprender alguns comandos como GU, GN ou ISRT.

Na verdade, o desafio é muito mais profundo.

O IMS exige uma mudança de mentalidade.

Durante décadas, milhares de programadores aprenderam a pensar em tabelas, linhas, colunas e relacionamentos criados dinamicamente durante a execução.

O IMS segue uma filosofia diferente.

Primeiro definimos a estrutura.

Depois definimos quem pode enxergá-la.

Depois definimos como navegar nela.

Somente então escrevemos o programa.

Essa ordem aparentemente simples explica boa parte da estabilidade histórica do ambiente.

O Fluxo Completo de Uma Aplicação IMS

Quando observamos o funcionamento de uma aplicação IMS, percebemos que existe uma sequência extremamente organizada.

Tudo começa com a modelagem.

Etapa 1 — DBD

Primeiro é criada a estrutura física.

A DBD define:

Segmentos
Campos-chave
Hierarquia
Método de acesso

Em outras palavras:

A DBD responde à pergunta:

Como os dados existem?

Etapa 2 — PSB

Depois vem a PSB.

A PSB responde:

O que o programa poderá enxergar?

Ela define:

Bancos acessados
Segmentos sensíveis
Permissões

Etapa 3 — PCB

Dentro da PSB encontramos as PCB's.

Cada PCB representa uma visão específica do banco.

Uma mesma aplicação pode possuir várias PCB's.

Inclusive para o mesmo banco.

Etapa 4 — ACBGEN

Após as definições serem geradas e validadas, o IMS produz os blocos de controle internos.

Isso reduz trabalho durante a execução.

Etapa 5 — Programa COBOL

Somente agora o desenvolvedor entra em cena.

O programa recebe:

PCB
+
DL/I
+
IO AREA
+
SSA

e passa a navegar pelos dados.

Observe como a aplicação nunca toca diretamente no banco.

Toda comunicação passa pelo DL/I.

O Erro Mais Comum de Quem Está Começando

Quase todo iniciante tenta tratar IMS como se fosse SQL.

Algo parecido com:

"Quero localizar esse registro."

Mas o IMS pensa diferente.

A pergunta correta seria:

"Por qual caminho vou chegar até esse registro?"

Esse detalhe muda tudo.

O sucesso em IMS depende muito mais da compreensão da hierarquia do que da sintaxe dos comandos.

Por Que Bancos Ainda Utilizam IMS em 2026?

Essa é uma pergunta recorrente.

A resposta é simples.

Porque ele continua funcionando extraordinariamente bem.

Imagine uma instituição financeira com:

Centenas de milhões de clientes
Bilhões de registros
Milhares de transações por segundo
Disponibilidade próxima de 100%

Substituir uma plataforma desse porte não é uma decisão tecnológica.

É uma decisão empresarial.

E quando a plataforma continua entregando:

Confiabilidade
Escalabilidade
Segurança
Performance

a motivação para substituí-la simplesmente desaparece.

O Que Mudou no IMS Moderno

Existe um mito muito difundido.

Muita gente imagina que IMS ficou parado no tempo.

Nada poderia estar mais distante da realidade.

O IMS atual possui integração com:

APIs REST
Java
JDBC
SQL
z/OS Connect
Web Services
Cloud híbrida
DevOps
Git
Pipelines CI/CD

A hierarquia continua existindo.

Mas o acesso tornou-se muito mais moderno.

Hoje um aplicativo mobile pode consumir informações armazenadas em um banco IMS sem que o usuário tenha qualquer ideia disso.

O Paradoxo do IMS

Talvez a característica mais fascinante do IMS seja seu paradoxo.

Ele é simultaneamente:

Antigo e moderno.
Conservador e inovador.
Simples e extremamente sofisticado.

Por fora, vemos comandos criados há décadas.

Por dentro, encontramos algumas das soluções mais eficientes já construídas para processamento transacional em larga escala.

Lições Que o IMS Ensina aos Arquitetos Modernos

Mesmo que você nunca programe uma linha de código IMS, existem ensinamentos valiosos.

1. Modelagem importa

Antes de discutir frameworks, defina a estrutura.

2. Performance nasce da arquitetura

Não existe milagre.

Quando a modelagem é correta, a performance surge naturalmente.

3. Segurança deve nascer no projeto

PSB, PCB e Sensibilidade demonstram isso há décadas.

4. Nem todo problema precisa de SQL

Alguns cenários se beneficiam enormemente de modelos hierárquicos.

5. Simplicidade operacional vale ouro

Quanto menos componentes, menos pontos de falha.

A Verdadeira Filosofia do IMS

Após estudar DBD, PSB, PCB, SSA, DL/I, Status Codes e navegação hierárquica, muitos profissionais chegam à mesma conclusão.

O IMS nunca foi apenas um banco de dados.

Ele é uma filosofia de engenharia.

Uma filosofia construída sobre quatro pilares:

Integridade
Desempenho
Previsibilidade
Confiabilidade

Enquanto grande parte do mercado busca reinventar a computação a cada cinco anos, o IMS segue fazendo algo muito mais difícil:

Continuar funcionando.

Considerações Finais

Padawan, quando alguém disser que IMS é apenas uma tecnologia antiga, lembre-se de uma coisa.

Tecnologias realmente antigas costumam desaparecer.

O IMS não desapareceu.

Ele sobreviveu ao surgimento do PC.

Sobreviveu à internet.

Sobreviveu ao client/server.

Sobreviveu à web.

Sobreviveu à virtualização.

Sobreviveu à nuvem.

E continua executando algumas das cargas de trabalho mais críticas do planeta.

Isso acontece porque o IMS foi construído para resolver problemas reais de negócio e não para seguir tendências.

Por trás de cada GU, GN, GNP, PCB, PSB e DBD existe quase seis décadas de experiência acumulada em ambientes onde falhar nunca foi uma opção.

E talvez essa seja a maior lição que um profissional de tecnologia pode aprender:

As melhores arquiteturas não são aquelas que chamam mais atenção. São aquelas que continuam funcionando quando todas as outras já viraram apenas uma lembrança em algum manual esquecido da computação. 🚀☕💣

Translate

segunda-feira, 1 de agosto de 2005