 |
| Bellacosa Mainframe e o misterio da rota invisivel |
☕ Um Café no Bellacosa Mainframe
O Mistério da Rota Invisível
Quando um Jovem Programador COBOL Descobriu que Seu Programa Nunca Escolhia Sozinho Onde Ser Executado
"Alguns acreditam que uma transação CICS entra em um computador e simplesmente é executada. Os veteranos sabem que, antes de qualquer linha de COBOL ganhar vida, existe um juiz invisível decidindo seu destino."
Naquela manhã chuvosa, o velho relógio marcava 6h17 quando Arthur Bellacosa empurrou a pesada porta metálica do CPD.
As luzes ainda estavam apagadas.
O ar tinha aquele cheiro inconfundível de equipamentos eletrônicos funcionando há décadas.
No fundo da sala, enormes gabinetes IBM piscavam silenciosamente.
Era como entrar em uma biblioteca onde os livros respiravam.
O operador noturno apenas levantou os olhos.
— Você veio cedo...
— Recebi um chamado estranho.
— Algum ABEND?
— Não...
— Muito pior.
— As transações começaram a aparecer em regiões diferentes... sem que ninguém mudasse uma única linha de configuração.
O operador sorriu.
— Então finalmente chegou a hora...
— Hora de conhecer o maior segredo do CICSPlex.
Na parede havia apenas um pequeno papel.
Escrito à máquina.
DTR
Nada mais.
E assim começava um dos maiores mistérios do universo CICS.
O Mistério da Região Fantasma
Todo programador COBOL iniciante imagina algo parecido com isto:
Usuário
↓
Programa COBOL
↓
Resposta
Parece lógico.
Parece simples.
Mas está completamente errado.
Na realidade existe uma verdadeira cidade funcionando atrás daquela tela verde.
Imagine um shopping gigantesco.
Existem dezenas de lojas.
Centenas de funcionários.
Elevadores.
Corredores.
Segurança.
Central de monitoramento.
Agora substitua tudo isso por regiões CICS.
Você começa a entender a dimensão do problema.
Quando um cliente consulta seu saldo bancário...
Quem decide qual computador executará aquele COBOL?
Não é o usuário.
Não é o terminal.
Nem o próprio programa.
Existe um personagem escondido.
Um mordomo.
Um maestro.
Um controlador de tráfego.
Seu nome:
Dynamic Transaction Routing.
A Primeira Grande Mentira
Durante décadas muitos iniciantes acreditaram:
"Minha transação sempre executa na mesma região."
Essa afirmação era verdadeira...
Em 1985.
Hoje?
Quase nunca.
Nos grandes bancos existem:
dezenas de TOR
dezenas de AOR
múltiplas FOR
regiões WUI
regiões CMAS
milhares de usuários simultâneos
Se todos fossem enviados para uma única AOR...
O resultado seria um desastre.
Imagine um Restaurante
Imagine um restaurante famoso.
Chegam 3.000 clientes.
Existe apenas um garçom.
Caos absoluto.
Agora imagine:
20 garçons.
O gerente observa continuamente:
Quem está livre?
Quem acabou de servir?
Quem possui menos mesas?
Quem está sobrecarregado?
É exatamente isso que o DTR faz.
Ele não envia clientes.
Ele distribui trabalho.
O Cérebro Invisível
Muitos imaginam que o DTR seja apenas um "Load Balancer".
Não.
Essa comparação é injusta.
Um balanceador tradicional enxerga servidores.
O DTR enxerga o universo CICS.
Ele conhece:
Tasks
Storage
CPU
AOR
TOR
Recursos
Saúde da região
Disponibilidade
Workload
Afinidade de transações
Estado operacional
É quase como se tivesse consciência do ambiente.
Quem fornece essa inteligência?
O famoso:
CICSPlex SM
Pense nele como o cérebro.
O DTR é uma das decisões tomadas por esse cérebro.
O Julgamento Invisível
Toda vez que uma transação nasce...
Existe um julgamento.
A cena lembra um tribunal noir.
O juiz pergunta:
— Região AOR-1...
Como anda sua CPU?
— 91%.
— Próxima.
— AOR-2?
— Apenas 44%.
— Memória?
— Excelente.
— Storage?
— Livre.
— Recursos?
— Todos disponíveis.
— Banco?
— Conectado.
O martelo bate.
"A próxima transação irá para AOR-2."
Tudo isso acontece em frações de segundo.
Sem intervenção humana.
A Cidade Secreta
Imagine uma cidade.
TOR
/ | \
AOR1 AOR2 AOR3
|
DB2
O usuário vê apenas a porta da cidade.
Mas dentro dela existe uma logística gigantesca.
TOR recebe visitantes.
AOR trabalha.
FOR protege arquivos.
Db2 guarda informações.
VSAM armazena registros.
MQ transporta mensagens.
E alguém coordena tudo.
O Segredo dos 35%
No infográfico vimos um exemplo interessante.
35%
35%
30%
Muitos acreditam que isso seja um algoritmo fixo.
Não é.
Foi apenas um exemplo didático.
Na prática talvez tenhamos:
42%
27%
31%
Ou
18%
51%
31%
Tudo depende da situação daquele instante.
O DTR não trabalha com igualdade.
Ele trabalha com eficiência.
O Maior Poder do DTR
Imagine:
AOR-2 sofreu um problema.
Sem DTR:
Usuários
↓
Erro
Com DTR:
AOR-2
OFFLINE
O CICSPlex praticamente diz:
— Ignorem essa região.
Novas transações?
↓
AOR-1
↓
AOR-3
Os usuários nem percebem.
É quase mágica.
Mas é engenharia.
A Diferença Entre Inteligência e Teimosia
Static Routing é teimoso.
Ele pensa:
Sempre foi AOR-1.
Sempre será AOR-1.
Mesmo que ela esteja sufocando.
Já o Dynamic Routing pergunta:
"Quem consegue responder mais rápido AGORA?"
É uma filosofia completamente diferente.
O Que o DTR Observa?
Aqui mora um dos maiores segredos.
Não basta verificar se a região está ligada.
Ela precisa estar saudável.
Imagine um hospital.
Está aberto.
Mas não possui médicos.
Vale a pena mandar pacientes?
Claro que não.
O mesmo ocorre no CICS.
Ele observa muito mais do que "ON" ou "OFF".
Entre diversos fatores estão:
disponibilidade
carga atual
quantidade de tasks
utilização de CPU
uso de armazenamento
estado dos recursos
tempo de resposta
saúde operacional
É um diagnóstico constante.
O Detetive Nunca Dorme
Uma curiosidade pouco comentada.
O DTR nunca "memoriza" para sempre.
Ele está constantemente reavaliando.
A próxima transação pode seguir um caminho completamente diferente da anterior.
Mesmo sendo exatamente a mesma transação.
Isso surpreende muitos iniciantes.
Um Banco de Verdade
Imagine um PIX.
Outro cliente faz TED.
Outro consulta saldo.
Outro paga boleto.
Outro desbloqueia cartão.
Mais outro faz um empréstimo.
Tudo praticamente ao mesmo tempo.
Cada operação pode seguir para regiões diferentes.
Mas o cliente acredita que tudo aconteceu em um único computador.
Essa ilusão é um dos grandes sucessos da arquitetura CICS.
O COBOL Não Faz Ideia
Outro detalhe fascinante.
O programa COBOL normalmente não sabe em qual região está.
Ele simplesmente executa.
Quem escolheu aquela região?
O DTR.
É como entrar em um táxi de olhos vendados.
Você apenas chega ao destino.
Existe Magia?
Não.
Existe arquitetura.
Décadas de arquitetura.
A IBM começou a desenvolver mecanismos sofisticados de balanceamento e alta disponibilidade muito antes da popularização da computação em nuvem.
Conceitos que hoje vemos em Kubernetes, service mesh e orquestração distribuída já eram tratados em ambientes corporativos IBM Z com foco em disponibilidade, isolamento de falhas e continuidade do serviço.
Um Easter Egg para os Veteranos
Existe uma brincadeira antiga entre operadores de CPD.
"Quando tudo funciona ninguém lembra que o CICSPlex existe.
Quando ele para...
Todo mundo aprende rapidamente o que ele fazia."
Poucas frases resumem tão bem a importância dessa camada invisível.
Outro Easter Egg
Nos romances policiais sempre existe um personagem que nunca chama atenção.
O mordomo.
No final...
Descobre-se que ele esteve presente em todas as cenas.
O DTR é exatamente esse mordomo.
Você raramente pensa nele.
Mas praticamente toda transação moderna passa por suas decisões.
Sherlock Holmes no CPD
Sherlock observava o painel.
Watson perguntou:
— Como sabe que a transação foi para AOR-3?
Holmes respondeu:
— Elementar.
— A CPU da AOR-1 estava elevada.
— A AOR-2 perdeu conectividade.
— Restava apenas uma escolha racional.
Watson sorriu.
— Então foi dedução?
Holmes respondeu:
— Não.
Foi exatamente o que o DTR faria.
Curiosidades que Pouca Gente Conhece
O DTR não nasceu para distribuir igualmente.
Ele nasceu para manter o ambiente funcionando.
São objetivos diferentes.
Alta disponibilidade não significa ausência de falhas.
Significa continuar operando apesar delas.
Essa é uma das maiores lições da engenharia de sistemas críticos.
Adicionar novas AORs pode aumentar a capacidade sem alterar o código COBOL.
Em muitos cenários, a lógica de negócio permanece a mesma; o ganho vem da infraestrutura, que passa a distribuir melhor as requisições.
O usuário nunca percebe.
Para ele:
Enter
↓
Resposta
Nos bastidores aconteceram dezenas de decisões.
Dicas para quem está começando
Se você pretende trabalhar com CICS profissionalmente, siga uma sequência de estudos que faz toda a diferença:
Aprenda primeiro o ciclo de vida de uma transação CICS.
Entenda a diferença entre TOR, AOR e FOR.
Estude o papel do CICSPlex SM como gerenciador do ambiente.
Depois mergulhe em Dynamic Transaction Routing (DTR) e compare-o com o roteamento estático.
Familiarize-se com ferramentas de monitoramento, como SMF, RMF e os recursos do próprio CICS, para compreender como desempenho e disponibilidade são acompanhados na prática.
Por fim, explore conceitos de afinidade de transações (transaction affinity), fundamentais para entender por que algumas cargas podem ou não ser distribuídas livremente entre diferentes AORs.
O Verdadeiro Mistério
No fim daquela manhã, Arthur Bellacosa desligou a lanterna.
Olhou novamente para os enormes gabinetes IBM.
Agora compreendia.
As transações nunca haviam escolhido sozinhas onde seriam executadas.
Sempre existira alguém tomando aquela decisão.
Silenciosamente.
Sem receber aplausos.
Sem aparecer nas telas dos usuários.
Sem sequer ser lembrado pelos programadores iniciantes.
Um maestro invisível.
Um juiz imparcial.
Um detetive que investigava milhares de cenas por segundo antes de decidir qual caminho cada transação deveria seguir.
Enquanto milhões de pessoas consultavam saldos, faziam PIX, compravam passagens aéreas, autorizavam pagamentos e movimentavam a economia mundial, aquele guardião permanecia nas sombras, avaliando carga, disponibilidade e saúde das regiões CICS para manter tudo funcionando como um único organismo.
Talvez esse seja o maior segredo do IBM Z.
Os usuários enxergam apenas uma aplicação.
Os programadores enxergam um programa COBOL.
Os operadores enxergam algumas regiões CICS.
Mas, nas profundezas do CPD, existe uma inteligência silenciosa conectando todas essas peças e garantindo que cada transação encontre o melhor destino possível.
E se um dia você entrar em uma sala de computadores antes do amanhecer, ouvir apenas o zumbido constante dos equipamentos e encontrar, preso ao painel de controle, um pequeno papel com três letras datilografadas...
DTR.
Não o ignore.
Porque, naquele instante, você terá encontrado um dos maiores detetives invisíveis da história da computação corporativa.
