 |
| 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:
150
B altera para:
120
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:
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
ou
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:
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. 🚀☕💣
.png)
