 |
| Bellacosa Mainframe e o banco de dados IMS no Mundo Mainframe |
☕ Um Café no Bellacosa Mainframe
📚 LUCA PACIOLI E O LIVRO-RAZÃO DO MAINFRAME
IMS DB, IMS TM, DL/I, COBOL, segmentos, DBD, PSB, PCB, SSA, GU, GN, GNP, commit, rollback, CICS e Db2 — e o dia em que o pai da contabilidade descobriu que um ABEND também precisa fechar as contas.
🎬 PRÓLOGO — O monge encontrou um lançamento que não fechava
Imagine que Luca Pacioli, matemático e frade franciscano associado à sistematização e divulgação da contabilidade por partidas dobradas no Renascimento, atravessasse alguns séculos e aparecesse diante de um IBM mainframe.
Nosso jovem programador COBOL estaria sentado diante de uma tela verde.
Na tela:
GU
GN
GNP
GHU
ISRT
REPL
DLET
Pacioli observaria aquilo por alguns segundos.
— Filho, onde estão seus livros?
O programador apontaria para o terminal.
— Aqui.
— Onde estão os lançamentos?
— No IMS.
— E onde está o razão?
— Bem... depende. Pode estar no IMS DB ou no Db2.
Pacioli provavelmente franziria a testa.
— Então explique desde o começo.
Excelente ideia.
Porque IMS é justamente uma daquelas tecnologias que assustam quando aprendemos pelas siglas e ficam muito mais interessantes quando entendemos o problema que cada peça resolve.
Pegue seu café.
Hoje nosso mestre será Luca Pacioli.
E nossa primeira lição será simples:
antes de lançar qualquer coisa, precisamos entender em qual livro estamos escrevendo.
📜 CAPÍTULO 1 — IMS NÃO É APENAS UM BANCO DE DADOS
Um dos primeiros erros do Padawan mainframe é ouvir IMS e imediatamente concluir:
IMS é um banco de dados.
Não exatamente.
IMS significa Information Management System e possui dois grandes mundos que precisamos separar mentalmente:
IMS
│
┌────────┴────────┐
│ │
IMS DB IMS TM
│ │
DADOS TRANSAÇÕES
O IMS DB é a parte relacionada ao gerenciamento de bancos de dados hierárquicos.
O IMS TM, Transaction Manager, é a parte relacionada ao processamento de transações e mensagens.
Essa distinção é importantíssima porque permite compreender uma arquitetura como:
Usuário
│
▼
IMS TM
│
▼
Programa COBOL
│
├────────► IMS DB
│
└────────► Db2
Observe algo interessante.
O programa executado pelo IMS TM não precisa necessariamente utilizar IMS DB.
Ele pode acessar Db2 e outros recursos.
Da mesma maneira, um database IMS pode ser utilizado por processamento batch.
Portanto:
IMS TM ≠ IMS DB
Eles pertencem à mesma família tecnológica, trabalham muito bem juntos, mas resolvem problemas diferentes.
Pacioli aprovaria a separação.
Na contabilidade, misturar caixa, razão, diário e balanço sem compreender a função de cada um seria receita para desastre.
No mainframe também.
🌳 CAPÍTULO 2 — PACIOLI DESCOBRE QUE O BANCO É UMA ÁRVORE
O programador moderno normalmente começa aprendendo banco relacional.
Ele imagina:
CLIENTE
CONTA
MOVIMENTO
como tabelas.
Por exemplo:
CLIENTE
+------+----------+
| ID | NOME |
+------+----------+
| 1001 | PACIOLI |
+------+----------+
Depois:
CONTA
+-------+------------+
| CONTA | CLIENTE_ID |
+-------+------------+
| 12345 | 1001 |
+-------+------------+
No IMS DB precisamos mudar a cabeça.
O modelo fundamental é hierárquico.
Imagine:
CLIENTE
│
┌─────────┴─────────┐
│ │
CONTA CONTA
│
┌─────┴─────┐
│ │
MOVIMENTO MOVIMENTO
Temos uma árvore.
Os registros dessa árvore são chamados de segmentos.
Ou, na terminologia IMS:
segments.
Assim:
CLIENTE ← segmento
CONTA ← segmento
MOVIMENTO ← segmento
Mas existe uma relação explícita entre eles.
CLIENTE pode ser o:
root segment.
CONTA pode ser:
child de CLIENTE.
CLIENTE será:
parent de CONTA.
MOVIMENTO poderá ser child de CONTA.
Começamos então a falar a língua do IMS:
ROOT
PARENT
CHILD
TWIN
PATH
HIERARCHY
Pacioli provavelmente desenharia imediatamente a árvore em seu caderno.
Porque antes de registrar uma operação precisamos saber onde ela pertence.
🧬 CAPÍTULO 3 — SEGMENT NÃO É SIMPLESMENTE UMA ROW
Para facilitar o aprendizado, podemos inicialmente fazer:
IMS Segment ≈ Db2 Row
Mas coloque um enorme asterisco nessa comparação.
É uma analogia didática.
No Db2, pensamos em tabelas e relações.
No IMS, pensamos muito em ocorrências de segmentos dentro de uma hierarquia.
No relacional poderíamos perguntar:
SELECT *
FROM CLIENTE
WHERE ID = 1001;
No IMS estamos frequentemente pensando:
encontre determinada ocorrência do segmento CLIENTE e depois navegue pela estrutura subordinada a ela.
Essa palavra — navegue — é importantíssima.
SQL normalmente incentiva uma visão orientada a conjuntos.
IMS tradicionalmente exige que o programador compreenda muito claramente o caminho através dos dados.
🗺️ CAPÍTULO 4 — DBD: O MAPA DO LIVRO
Pacioli pergunta:
— Quem define a estrutura dessa árvore?
Entra em cena o:
DBD — Database Description.
O DBD descreve um database IMS.
Conceitualmente:
DATABASE CLIENTDB
CLIENTE
│
└── CONTA
│
└── MOVIMENTO
Ele contém informações sobre a estrutura do database, segmentos, campos, chaves e características de acesso.
Uma ponte mental simplificada seria:
Db2 IMS
---------------------------------------------
TABLE SEGMENT
ROW SEGMENT OCCURRENCE
COLUMN FIELD
PRIMARY KEY SEQUENCE FIELD
definição estrutural DBD
Não memorize isso como equivalência perfeita.
Use apenas para atravessar a ponte entre o paradigma relacional e o hierárquico.
Depois destrua a ponte.
Você já estará do outro lado.
👓 CAPÍTULO 5 — PSB: NEM TODO ESCRITURÁRIO PODE VER TODO O LIVRO
Agora Pacioli faz uma pergunta muito boa:
— Todo programa pode enxergar tudo?
Não.
Aqui encontramos o:
PSB — Program Specification Block.
O PSB descreve a visão de recursos IMS disponível para determinado programa.
Imagine que o database possua:
CLIENTE
│
├── CONTA
│ │
│ └── MOVIMENTO
│
├── CARTÃO
│
└── ENDEREÇO
Um programa talvez precise apenas de:
CLIENTE
│
└── CONTA
Outro pode trabalhar com:
CLIENTE
│
└── CARTÃO
Isso começa a demonstrar algo profundamente mainframe:
um programa não precisa receber acesso indiscriminado a tudo simplesmente porque os dados existem.
Dentro desse universo aparecem os PCBs.
🔌 CAPÍTULO 6 — PCB: O CANAL DE COMUNICAÇÃO
PCB significa:
Program Communication Block.
Ele funciona como uma importante estrutura de comunicação entre o programa e recursos IMS.
Podemos imaginar:
PSB
│
┌────────┼────────┐
│ │ │
PCB PCB PCB
│ │ │
▼ ▼ ▼
CLIENTDB ACCOUNTDB MESSAGE
E aqui encontramos uma regra que todo programador COBOL deveria aprender cedo:
não basta chamar o IMS. É necessário verificar o que aconteceu.
O PCB fornece informações importantes sobre o resultado das operações, incluindo status.
Se você trabalha com Db2, pense imediatamente em sua disciplina de verificar SQLCODE ou SQLSTATE.
No IMS também existe vida depois da chamada.
E ignorá-la pode custar algumas horas de sono.
Voltaremos a isso às 03:17.
📞 CAPÍTULO 7 — DL/I: O IDIOMA DO CONTADOR
DL/I significa:
Data Language/I.
É uma interface fundamental através da qual programas solicitam serviços IMS.
No COBOL tradicional você pode encontrar chamadas envolvendo:
CALL 'CBLTDLI' USING ...
E então surgem aqueles hieróglifos que assustaram nosso Padawan:
GU
GN
GNP
GHU
GHN
GHNP
ISRT
REPL
DLET
Eles não são magia.
São operações.
Vamos abrir o livro de Pacioli.
🎯 CAPÍTULO 8 — GU: ENCONTRE O LANÇAMENTO
GU — Get Unique.
Imagine que queremos encontrar determinado cliente:
CLIENTE
ID = 1001
Conceitualmente:
GU CLIENTE 1001
No Db2 sua cabeça provavelmente produziria:
SELECT *
FROM CLIENTE
WHERE ID = 1001;
Novamente: não são comandos equivalentes.
Mas a intenção didática ajuda:
encontre uma ocorrência específica.
GU é uma das primeiras operações que um estudante IMS deve compreender.
➡️ CAPÍTULO 9 — GN: CONTINUE LENDO O LIVRO
GN — Get Next.
Agora aparece um dos conceitos mais importantes do IMS:
posicionamento.
Imagine:
CLIENTE
│
├── CONTA 001
├── CONTA 002
└── CONTA 003
Encontramos algo.
Agora queremos continuar navegando.
GN significa essencialmente:
obtenha o próximo segmento aplicável à navegação.
O detalhe importante não é simplesmente decorar "Get Next".
É perceber que existe um contexto de navegação.
Você estava em algum lugar.
Agora quer continuar.
IMS não é simplesmente:
procure coisas aleatoriamente.
Existe uma topologia.
Existe uma posição.
Existe um caminho.
👨👧 CAPÍTULO 10 — GNP: NÃO SAIA DA FAMÍLIA
GNP — Get Next within Parent.
Imagine:
CLIENTE PACIOLI
│
├── CONTA A
├── CONTA B
└── CONTA C
Queremos navegar pelos segmentos subordinados mantendo determinado contexto parental.
O conceito de parent torna-se fundamental.
Pacioli provavelmente resumiria:
"Continue o livro, mas não vá parar na conta do vizinho."
É uma excelente maneira de lembrar GNP.
✋ CAPÍTULO 11 — O H SIGNIFICA HOLD
Agora aparecem:
GHU
GHN
GHNP
O H significa:
Hold.
São operações relacionadas à recuperação mantendo o segmento para posterior atualização.
Por exemplo, conceitualmente:
GHU
│
▼
encontrar segmento
│
▼
alterar dados
│
▼
REPL
Isso é importante porque atualização em ambiente transacional não pode ser tratada como:
achei, mexi, boa sorte.
Há concorrência.
Outro programa pode estar interessado naquele dado.
Existe integridade.
Existe uma Unit of Work.
Existem regras de locking e recuperação.
➕ CAPÍTULO 12 — ISRT: NOVO LANÇAMENTO
ISRT — Insert.
É utilizado para inserir uma nova ocorrência.
Imagine:
CLIENTE
│
└── CONTA NOVA
O paralelo mental seria um:
INSERT
do mundo SQL.
Mas no IMS a hierarquia importa.
Uma CONTA subordinada a CLIENTE não é simplesmente um registro flutuando no espaço.
Ela ocupa uma posição estrutural.
Essa diferença parece pequena no treinamento.
Em produção, ela muda a maneira de pensar.
✏️ CAPÍTULO 13 — REPL: CORRIGINDO O LIVRO
REPL — Replace.
É utilizado para substituir/atualizar dados de um segmento recuperado adequadamente para alteração.
Mentalmente:
GHU
↓
SEGMENTO
↓
alteração
↓
REPL
No Db2 poderíamos associar a intenção a:
UPDATE
Mas não tente converter mecanicamente DL/I em SQL.
O importante é compreender o modelo operacional de cada tecnologia.
🗑️ CAPÍTULO 14 — DLET: NEM TODO REGISTRO É ETERNO
Finalmente:
DLET — Delete.
Remove determinada ocorrência.
Mas Pacioli levantaria imediatamente a mão:
— E os filhos?
Exatamente.
Em uma estrutura hierárquica, relacionamentos importam profundamente.
Excluir dados exige compreender sua posição e suas dependências.
Essa é uma excelente lição para o programador iniciante:
antes de alterar ou excluir qualquer segmento IMS, desenhe a hierarquia.
Papel e lápis ainda são ferramentas extraordinárias de debugging.
🔎 CAPÍTULO 15 — SSA: O DETETIVE DA ÁRVORE
Chegamos ao:
SSA — Segment Search Argument.
Ele ajuda a especificar segmentos e critérios utilizados nas operações DL/I.
Para um programador SQL, existe uma tentação irresistível:
SSA = WHERE
Segure essa tentação.
Podemos dizer:
SSA lembra parcialmente um critério de seleção
mas IMS e SQL trabalham com modelos diferentes.
Você encontrará:
unqualified SSA
qualified SSA
Um SSA pode simplesmente identificar um tipo de segmento ou adicionar condições de busca.
Agora podemos imaginar:
Programa COBOL
│
│ GU
│ + SSA
▼
DL/I
│
▼
IMS DB
│
▼
segmento desejado
A operação diz o que queremos fazer.
O SSA ajuda a dizer sobre qual segmento/ocorrência queremos fazer aquilo.
🧠 CAPÍTULO 16 — SQL PENSA EM CONJUNTOS; IMS CONHECE CAMINHOS
Essa talvez seja a grande mudança mental.
Considere:
SELECT M.*
FROM CLIENTE C
JOIN CONTA A
ON A.CLIENTE_ID = C.ID
JOIN MOVIMENTO M
ON M.CONTA_ID = A.ID
WHERE C.ID = 1001;
Nossa intenção é declarada através do SQL.
O optimizer do Db2 possui enorme responsabilidade na determinação do access path.
Agora observe a árvore:
CLIENTE 1001
│
▼
CONTA
│
▼
MOVIMENTO
No IMS, compreender a hierarquia e o padrão de navegação é fundamental.
Essa característica ajuda a explicar tanto uma das grandes forças quanto uma das limitações do modelo.
Quando o caminho natural da aplicação combina muito bem com a estrutura hierárquica, podemos ter processamento extremamente eficiente.
Quando desejamos explorar os dados através de relações completamente diferentes e consultas ad hoc, o modelo relacional frequentemente oferece uma flexibilidade muito mais natural.
Portanto jamais ensine:
IMS é melhor que Db2.
Ou:
Db2 substitui IMS porque é mais moderno.
Pergunte:
Qual é o workload?
Essa é pergunta de arquiteto.
⚡ CAPÍTULO 17 — IMS TM: AGORA PACIOLI ABRE O CAIXA
Mudamos de livro.
IMS TM significa:
IMS Transaction Manager.
Agora estamos falando principalmente de processamento transacional orientado a mensagens.
Imagine:
Terminal
│
│ solicitação
▼
IMS TM
│
▼
TRANSAÇÃO
│
▼
Programa COBOL
│
├────► IMS DB
└────► Db2
Depois:
Programa
│
▼
IMS TM
│
▼
Resposta
Esse modelo foi e continua sendo extremamente poderoso para workloads transacionais.
Uma mensagem chega.
O IMS identifica o processamento apropriado.
O programa é executado.
Dados são consultados ou modificados.
Uma resposta pode ser produzida.
Pacioli reconheceria imediatamente o princípio:
entrada → processamento → registro → resultado.
🏭 CAPÍTULO 18 — MPP: O ESCRITURÁRIO TRANSACIONAL
No IMS TM encontramos o conceito de:
MPP — Message Processing Program.
É um programa que processa mensagens sob o controle do IMS TM.
Podemos visualizar:
IMS TM
│
┌─────────┼─────────┐
│ │ │
MPP MPP MPP
│ │ │
COBOL COBOL COBOL
Essa arquitetura permite processamento de grande quantidade de transações.
E agora surge uma pergunta inevitável:
Mas isso não é aquilo que CICS faz?
Estamos chegando ao duelo.
⚔️ CAPÍTULO 19 — IMS TM × CICS
CICS e IMS TM ocupam territórios parcialmente comparáveis porque ambos participam do mundo de processamento transacional.
Mas não são clones.
Didaticamente:
TRANSACTION PROCESSING
│
┌─────────┴─────────┐
│ │
CICS IMS TM
CICS tornou-se um enorme transaction/application server no ecossistema IBM Z.
IMS TM possui uma arquitetura fortemente relacionada a processamento transacional orientado a mensagens e ao ecossistema IMS.
Ambos podem executar aplicações COBOL.
Ambos podem participar de sistemas críticos.
Ambos podem acessar Db2.
E IMS TM naturalmente possui profunda integração com IMS DB.
Portanto o erro seria perguntar:
Qual deles é o banco?
Nenhum deles nessa comparação.
Estamos comparando principalmente componentes de processamento transacional.
🗄️ CAPÍTULO 20 — IMS DB × Db2
Agora temos uma comparação conceitualmente mais direta.
IMS DB Db2
│ │
▼ ▼
Hierárquico Relacional
IMS:
CLIENTE
│
├── CONTA
│ │
│ ├── MOVIMENTO
│ └── MOVIMENTO
│
└── CONTA
Db2:
CLIENTE
ID
CONTA
ID
CLIENTE_ID
MOVIMENTO
ID
CONTA_ID
No Db2, relações são expressas através do modelo relacional, chaves e SQL.
No IMS DB, a hierarquia faz parte fundamental da organização dos dados.
Nenhum desenho sozinho diz qual tecnologia será mais rápida.
Performance depende de fatores como:
organização dos dados;
access path;
volume;
padrão de acesso;
concorrência;
buffering;
índices;
desenho da aplicação;
distribuição dos dados;
configuração;
infraestrutura.
Desconfie de qualquer comparação tecnológica resumida em:
X sempre é mais rápido que Y.
Em mainframe, quase sempre falta completar:
fazendo o quê?
🧩 CAPÍTULO 21 — O MAPA DEFINITIVO DO PADAWAN
Pacioli finalmente desenha tudo no quadro:
APLICAÇÃO MAINFRAME
│
COBOL
│
┌──────────────┼──────────────┐
│ │ │
CICS IMS TM BATCH
│ │ │
└──────────────┼──────────────┘
│
┌──────────┴──────────┐
│ │
SQL DL/I
│ │
▼ ▼
Db2 IMS DB
Agora ficou muito mais fácil.
CICS e IMS TM aparecem principalmente na camada de processamento transacional.
Db2 e IMS DB aparecem principalmente na camada de gerenciamento de dados.
SQL é uma interface fundamental para Db2.
DL/I é uma interface fundamental para IMS.
E COBOL pode estar no meio de praticamente tudo.
💰 CAPÍTULO 22 — PACIOLI DESCOBRE O COMMIT
Agora nosso mestre finalmente encontra algo familiar.
Imagine uma transferência:
CONTA A -500
CONTA B +500
Pacioli imediatamente entende o problema.
Não podemos terminar com:
CONTA A -500
CONTA B 0
porque o programa sofreu um ABEND entre as operações.
É aqui que conceitos transacionais deixam de parecer burocracia:
UNIT OF WORK
COMMIT
ROLLBACK
LOG
RECOVERY
CHECKPOINT
RESTART
Imagine:
BEGIN UOW
DEBITA A
│
▼
CREDITA B
│
▼
COMMIT
Se algo der errado antes da conclusão:
DEBITA A
│
▼
💥 ABEND
│
▼
ROLLBACK / RECOVERY
A arquitetura precisa preservar a consistência.
Pacioli sorriria.
Séculos se passaram.
Mudamos pena por COBOL.
Livro-caixa por database.
Escriturário por programa.
Mas a pergunta fundamental continua a mesma:
As contas fecham?
🚨 CAPÍTULO 23 — O INCIDENTE DAS 03:17
Chegamos ao easter egg.
03:17.
Telefone toca.
Produção está apresentando resultados estranhos.
War Room aberta.
SDSF.
Logs.
Dump.
JES.
Programa COBOL.
DBD.
PSB.
PCB.
SSA.
Todos procurando um monstro tecnológico.
Até que um velho programador pergunta:
— Depois daquele CALL, vocês verificam o status?
Silêncio.
O jovem abre o fonte.
CALL 'CBLTDLI' USING ...
E depois...
continua o processamento como se nada pudesse dar errado.
Pacioli fecha lentamente seu livro.
— Meu jovem... até um contador do século XV conferia se o lançamento havia sido realizado.
Moral:
Nunca trate uma chamada de banco ou serviço como ato de fé.
Verifique retorno.
Sempre.
No Db2:
SQLCODE
SQLSTATE
No IMS:
PCB STATUS
Em MQ:
Completion Code
Reason Code
Em APIs:
HTTP status
payload
O programador de produção aprende cedo:
sucesso precisa ser comprovado.
🌙 CAPÍTULO 24 — IMS TAMBÉM TRABALHA QUANDO VOCÊ ESTÁ DORMINDO
Outro erro comum:
IMS é coisa de terminal online.
Não.
IMS DB também participa de processamento batch.
Imagine:
IMS DB
▲
┌────────┴────────┐
│ │
ONLINE BATCH
│ │
IMS TM COBOL
│
JCL
E então aparecem questões muito mais interessantes:
concorrência
locking
checkpoint
restart
recovery
disponibilidade
janela batch
utilities
reorganização
performance
Agora você percebe por que profissionais IMS experientes possuem conhecimento tão valioso.
Eles não aprenderam simplesmente dez comandos DL/I.
Aprenderam a manter um ecossistema transacional funcionando.
🔬 CAPÍTULO 25 — A PORTA SECRETA DO IMS
Quando você dominar os conceitos básicos, abra outra porta.
Atrás dela encontrará:
HDAM
HIDAM
HALDB
DEDB
Fast Path
BMP
MPP
IFP
GSAM
secondary indexes
logical relationships
IMS Connect
OTMA
logging
recovery
checkpoint
restart
buffering
database utilities
reorganization
Aí começa o IMS de verdade.
Especialmente estudar:
HDAM × HIDAM × HALDB × DEDB
ajuda a compreender que dizer simplesmente "IMS é hierárquico" é apenas a primeira página de um livro enorme.
O modo como dados são organizados e acessados influencia profundamente performance e operação.
🌐 CAPÍTULO 26 — IMS NÃO PAROU EM 1970
Talvez esse seja o ponto mais importante para um profissional começando no mainframe atual.
Encontrar uma tecnologia criada décadas atrás não significa encontrar uma arquitetura congelada naquela década.
Hoje podemos encontrar ambientes conceitualmente parecidos com:
Mobile
│
Web
│
Cloud
│
API
│
Integration
│
├───────────────┐
▼ ▼
CICS IMS
│ │
▼ ▼
Db2 IMS DB
Podemos adicionar:
MQ
APIs
eventos
observabilidade
automação
Git
CI/CD
Java
containers
IA
ao ecossistema.
Modernizar não significa obrigatoriamente arrancar o coração de um sistema que funciona.
Às vezes significa construir artérias novas.
🏛️ CAPÍTULO 27 — NÃO DEMOLIRE A CATEDRAL PARA INSTALAR WI-FI
Essa é uma das grandes lições do mainframe.
Imagine uma catedral construída durante cinquenta anos.
Alguém chega e diz:
— Precisamos instalar Wi-Fi.
Ninguém sensato responde:
— Derrube a catedral.
Modernização inteligente pergunta:
Onde estão os pontos de integração?
Quais componentes realmente precisam mudar?
Onde está o acoplamento?
Qual é o risco?
Quais dados continuam críticos?
Como expomos funcionalidades existentes de forma segura?
IMS, CICS e Db2 podem continuar no coração enquanto novas camadas surgem ao redor.
O legado não precisa ser tratado como inimigo.
Dívida técnica precisa ser combatida. Idade, sozinha, não é dívida técnica.
🧭 CAPÍTULO 28 — O PASSO A PASSO PARA APRENDER IMS
Se Pacioli fosse montar nosso plano de estudos, eu imagino algo assim:
IMS OVERVIEW
│
▼
IMS DB × IMS TM
│
▼
MODELO HIERÁRQUICO
│
▼
SEGMENT / ROOT / PARENT / CHILD
│
▼
DBD
│
▼
PSB
│
▼
PCB
│
▼
DL/I
│
▼
SSA
│
▼
GU / GN / GNP
│
▼
GHU / GHN / GHNP
│
▼
ISRT / REPL / DLET
│
▼
STATUS CODES
│
▼
IMS TM
│
▼
MPP
│
▼
COMMIT / ROLLBACK
│
▼
CHECKPOINT / RESTART
│
▼
BATCH
│
▼
PERFORMANCE
│
▼
RECOVERY
│
▼
IMS CONNECT / INTEGRAÇÃO
Não tente decorar tudo no primeiro dia.
Desenhe.
Simule.
Leia programas.
Procure as chamadas DL/I.
Identifique o PSB.
Localize PCBs.
Observe SSAs.
Veja quais operações aparecem.
Depois desenhe a árvore correspondente.
Faça isso repetidamente.
Em algumas semanas, aquele COBOL cheio de siglas começará a parecer uma história.
🎓 CAPÍTULO 29 — EXERCÍCIO DO PADAWAN
Pegue este cenário:
CLIENTE
│
├── CONTA
│ │
│ ├── MOVIMENTO
│ └── MOVIMENTO
│
└── CONTA
│
└── MOVIMENTO
Agora responda sem programar:
Qual poderia ser o root?
CLIENTE.
Qual é parent de MOVIMENTO?
CONTA.
Qual é child de CLIENTE?
CONTA.
Quero localizar um CLIENTE específico.
Pense em GU.
Quero navegar.
Pense em GN.
Quero continuar dentro de determinado parent.
Pense em GNP.
Quero recuperar para alteração.
Comece a pensar nas versões GHx.
Quero inserir.
ISRT.
Quero atualizar.
REPL.
Quero remover.
DLET.
Quando você consegue explicar isso sem decorar frases de apostila, começou a entender IMS.
☕ EPÍLOGO — O BALANÇO FECHOU
No final da aula, Luca Pacioli olha novamente para o terminal.
Agora aquelas siglas não parecem tão misteriosas.
Ele escreve:
IMS
│
├── IMS DB
│ ├── hierarquia
│ ├── segmentos
│ ├── DBD
│ ├── PSB
│ ├── PCB
│ ├── SSA
│ └── DL/I
│
└── IMS TM
├── mensagens
├── transações
└── programas
Ao lado:
CICS ─────► processamento transacional
IMS TM ───► processamento transacional
Db2 ──────► dados relacionais
IMS DB ───► dados hierárquicos
SQL ──────► interface relacional
DL/I ─────► interface IMS
E finalmente escreve uma última frase:
Integridade não é uma funcionalidade. É um compromisso.
Talvez seja essa a ponte mais bonita entre Luca Pacioli e o mainframe.
A contabilidade por partidas dobradas não nasceu porque alguém achou divertido duplicar lançamentos.
Ela nasceu da necessidade de controle, rastreabilidade e consistência.
Mainframes também não possuem logs, commits, rollback, recovery, checkpoints e códigos de retorno porque engenheiros gostam de complicar sistemas.
Esses mecanismos existem porque, quando estamos movimentando dinheiro, reservas, apólices, pagamentos ou milhões de registros corporativos, precisamos conseguir responder:
O que aconteceu?
Quando aconteceu?
Foi concluído?
Se falhou, o que ficou gravado?
É possível recuperar?
Os dados continuam consistentes?
É por isso que estudar IMS ensina muito mais do que IMS.
Ensina a mentalidade de sistemas de missão crítica.
O programador iniciante olha para:
GU
GN
GNP
ISRT
REPL
DLET
e pergunta:
"Qual comando lê o registro?"
O profissional começa a perguntar:
"Qual é a hierarquia?"
"Qual é meu parent?"
"Onde estou posicionado?"
"Qual SSA foi utilizado?"
"Qual PCB?"
"Qual status voltou?"
"Qual é a Unit of Work?"
"Quando ocorre o commit?"
"Se houver um ABEND neste exato ponto, o que acontece?"
E o arquiteto acrescenta:
"Por que esse workload está no IMS?"
"Qual é seu padrão de acesso?"
"Onde CICS entra?"
"Onde Db2 entra?"
"Como isso conversa com sistemas modernos?"
Quando você chega a esse ponto, não está mais simplesmente decorando comandos DL/I.
Está começando a compreender por que o mainframe foi construído da maneira como foi construído.
Pacioli fecha o livro.
O Padawan fecha a sessão ISPF.
O relógio marca 03:17.
Nenhum telefone toca.
Desta vez o status code foi verificado.
O balanço fechou.
E finalmente podemos tomar aquele café enquanto ainda está quente.
Bem-vindo ao IMS.
Aqui até um ABEND precisa prestar contas. ☕
