| Bellacosa Mainframe e o misterio do coração invisivel |
☕ Um Café no Bellacosa Mainframe
O Mistério do Coração Invisível
Quando um Detetive Descobre que Milhões de Transações Bancárias Dependem de uma Sala que Quase Ninguém Conhece
"Naquela noite, o relógio marcava 02h17 quando o telefone tocou. Do outro lado da linha, apenas uma frase: 'A aplicação desapareceu... mas a transação continua viva.' Peguei meu chapéu, meu bloco de notas e caminhei até o CPD. Mais um caso aguardava o Detetive Bellacosa..."
Capítulo 1 — O Prédio que Nunca Dorme
Existem lugares onde o tempo parece diferente.
Enquanto a cidade dorme, cafés fecham as portas e as ruas ficam silenciosas, milhares de computadores continuam trabalhando.
Entre eles existe um grupo muito especial.
São os IBM Mainframes.
Eles movimentam bancos.
Controlam companhias aéreas.
Administram cartões de crédito.
Pagam aposentadorias.
Liberam PIX.
Autorizam compras.
Processam seguros.
Movimentam bolsas de valores.
E tudo isso acontece em questão de milissegundos.
Mas existe um segredo.
Quando alguém fala em CICS, quase todo iniciante imagina um único programa gigante respondendo às solicitações dos usuários.
A verdade é muito mais elegante.
É como investigar um enorme prédio cheio de departamentos secretos.
Cada andar possui uma missão.
Cada sala possui uma função.
E existe uma sala onde realmente acontece a mágica.
Essa sala atende por um nome curioso:
AOR — Application-Owning Region.
É ali que mora o verdadeiro coração do CICS.
Capítulo 2 — Conhecendo os Suspeitos
Nenhum bom detetive começa uma investigação sem montar um mural.
Peguei algumas fotos e prendi tudo na parede.
Usuário
│
▼
Terminal 3270
│
▼
TOR
│
▼
Routing Region
│
▼
CICSPlex SM
┌──────┼──────┐
▼ ▼ ▼
AOR1 AOR2 AOR3
│
▼
DB2 • VSAM • MQ
Cada personagem possui uma personalidade.
O TOR é o porteiro.
O Routing Region é o despachante.
O CICSPlex é o estrategista.
Mas...
Quem realmente resolve o problema?
O AOR.
Capítulo 3 — O Crime Perfeito
Imagine um banco.
Um milhão de clientes.
Todos acessando simultaneamente.
Agora imagine que exista apenas uma única região CICS.
Ela teria que:
receber conexões;
autenticar usuários;
executar COBOL;
acessar Db2;
acessar VSAM;
controlar MQ;
conversar com APIs;
responder ao usuário.
Seria um caos.
A IBM percebeu isso décadas atrás.
E fez algo brilhante.
Separou responsabilidades.
Foi como dividir uma delegacia.
Existe quem atende o telefone.
Existe quem dirige a viatura.
Existe quem faz perícia.
Existe quem investiga.
No CICS acontece exatamente isso.
Capítulo 4 — O Verdadeiro Papel da AOR
Muitos livros dizem:
"A AOR executa programas."
Correto.
Mas extremamente incompleto.
Ela executa muito mais.
Dentro dela vivem:
programas COBOL;
programas PL/I;
aplicações C;
Java;
APIs REST;
SOAP;
CICS Web Services;
lógica bancária;
cálculos financeiros;
regras tributárias;
validações;
autenticação.
Ou seja...
Tudo aquilo que gera dinheiro para a empresa.
Capítulo 5 — A Sala das Máquinas
Imagine abrir uma porta metálica.
Dentro dela existem centenas de programas.
BANK001
BANK002
PIX010
LOAN050
CARD901
INSU300
Todos esperando alguém chamá-los.
Quando uma transação chega...
o CICS procura o programa.
Se ele ainda não estiver carregado...
faz o LOAD.
Depois disso...
ele permanece disponível.
Esse detalhe parece pequeno.
Mas muda completamente o desempenho.
Curiosidade Noir nº 1
Os primeiros acessos a um programa costumam ser ligeiramente mais lentos porque o módulo ainda precisa ser localizado e carregado na memória. Nas execuções seguintes, ele normalmente já está residente, reduzindo o tempo de resposta. Em ambientes de alta demanda, esse comportamento faz diferença em milhões de execuções ao longo do dia.
Capítulo 6 — O Caminho de uma Consulta de Saldo
Vamos seguir uma transação.
O cliente digita:
SALD
No terminal.
A sequência parece simples.
Mas observe o que acontece.
Cliente
↓
TOR
↓
Routing Region
↓
CICSPlex SM
↓
AOR
↓
COBOL
↓
EXEC SQL
↓
DB2
↓
Resposta
↓
Usuário
A resposta aparece em menos de um segundo.
Mas dezenas de componentes cooperaram.
É como um relógio suíço.
Easter Egg nº 1
Os nomes TOR, AOR e FOR lembram personagens de um romance policial. Curiosamente, muitos profissionais iniciantes demoram meses para perceber que essas siglas representam regiões especializadas trabalhando em conjunto, e não apenas configurações do CICS.
Capítulo 7 — Quem Escolhe a AOR?
Aqui entra um personagem extremamente inteligente.
O CICSPlex SM.
Ele observa tudo.
CPU.
Memória.
Número de tarefas.
Tempo médio.
Regiões indisponíveis.
Carga de trabalho.
Depois toma uma decisão.
AOR1
CPU 92%
↓
Ignorar
AOR2
CPU 31%
↓
Escolher
AOR3
CPU 81%
↓
Ignorar
Tudo acontece automaticamente.
Nenhum operador precisa decidir.
Curiosidade nº 2
Essa lógica lembra um controlador de tráfego aéreo. Assim como aviões são distribuídos entre pistas disponíveis, o CICSPlex SM distribui transações entre AORs para evitar congestionamentos e aproveitar melhor os recursos do sistema.
Capítulo 8 — O Grande Equívoco dos Iniciantes
Quase todo programador COBOL iniciante imagina isto:
COBOL
↓
DB2
Na prática...
é muito mais complexo.
Um único programa pode conversar com:
DB2
VSAM
MQ
IMS
REST
SOAP
TCP/IP
Sockets
Temporary Storage
Transient Data
O AOR funciona como uma grande central de integração.
Capítulo 9 — O Mistério da Escalabilidade
Imagine uma promoção nacional.
Normalmente o banco processa:
100 mil transações por minuto.
Hoje...
700 mil.
Comprar outro computador?
Nem sempre.
Pode ser mais simples criar novas AORs.
Antes:
TOR
↓
AOR1
Depois:
TOR
├──►AOR1
├──►AOR2
├──►AOR3
├──►AOR4
└──►AOR5
Essa é a essência da escalabilidade horizontal.
Capítulo 10 — Quando uma AOR Cai
Imagine.
AOR2 sofre um ABEND.
O que acontece?
O cliente percebe?
Na maioria das arquiteturas modernas...
não.
O CICSPlex remove a região da lista.
As próximas transações seguem para:
AOR1
AOR3
AOR4
Enquanto isso...
a equipe resolve o problema.
É por isso que bancos conseguem operar 24 horas.
Curiosidade nº 3
Em muitas instituições financeiras existem diversas AORs executando exatamente os mesmos programas. Isso permite retirar uma região para manutenção enquanto as demais continuam atendendo os clientes, reduzindo janelas de indisponibilidade.
Capítulo 11 — O AOR e o COBOL
É aqui que você, programador COBOL, entra na história.
Seu programa normalmente será executado dentro de uma AOR.
Quando você escreve:
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTAS
END-EXEC.
Quem faz tudo funcionar?
AOR.
Quando escreve:
EXEC CICS READ
Quem executa?
AOR.
Quando chama:
EXEC CICS LINK
Quem processa?
AOR.
Ela é o palco onde o seu código ganha vida.
Dicas de Ouro para o Iniciante
✔ Aprenda primeiro o fluxo completo da transação antes de decorar comandos.
✔ Entenda a diferença entre TOR, AOR, FOR e Routing Region.
✔ Estude EXEC CICS LINK, XCTL e RETURN para compreender como programas cooperam entre si.
✔ Familiarize-se com COMMAREA, Channels e Containers, pois são fundamentais para a troca de dados entre programas.
✔ Pratique o uso de EXEC SQL e operações em VSAM, já que a lógica de negócio normalmente envolve esses recursos.
✔ Leia mapas de monitoramento (como SMF e CICS Monitoring) para entender onde está o tempo gasto por uma transação.
Easter Egg nº 2
Existe um velho ditado entre profissionais de CICS:
"Se o TOR espirra, todo mundo percebe. Se a AOR trabalha bem, ninguém lembra que ela existe."
É exatamente esse o objetivo: manter a engrenagem funcionando de forma silenciosa.
O Dossiê do Detetive
Depois de horas analisando logs, diagramas e relatórios, a conclusão era inevitável.
O mistério nunca foi descobrir onde a transação entrava.
Nem onde ela terminava.
O verdadeiro mistério sempre foi entender quem fazia o trabalho pesado.
A resposta estava escondida em uma pequena sigla de apenas três letras.
AOR.
Ela recebe programas.
Executa regras de negócio.
Consulta Db2.
Lê VSAM.
Publica mensagens em MQ.
Conversa com APIs.
Responde ao usuário.
E faz tudo isso milhares — ou até milhões — de vezes por dia.
É por isso que dizemos que a Application-Owning Region é o coração do CICS. Não porque ela seja a única peça importante, mas porque é nela que o "sangue" das transações circula: cada instrução COBOL, cada EXEC CICS, cada EXEC SQL e cada decisão de negócio passam por esse ambiente de execução.
Da próxima vez que alguém consultar um saldo, comprar com cartão, pagar um boleto ou realizar um PIX, lembre-se de que existe uma equipe invisível trabalhando em perfeita sincronia. O usuário verá apenas uma resposta na tela, mas, nos bastidores, TOR, Routing Region, CICSPlex SM, AOR, Db2, VSAM e MQ estarão desempenhando seus papéis como personagens de um clássico romance noir.
E, como todo bom detetive sabe, o segredo dos grandes casos raramente está na primeira pista. No universo do Mainframe, a pista decisiva é compreender a arquitetura. Quando você entende por que o processamento foi separado do roteamento, deixa de enxergar apenas programas COBOL isolados e passa a ver um ecossistema projetado para oferecer desempenho, disponibilidade e confiabilidade em escala mundial.
Na próxima investigação do Bellacosa Mainframe, outro mistério nos espera. Afinal, em algum lugar do CPD existe outra porta metálica fechada, outro componente pouco conhecido e outra história fascinante escondida atrás de três ou quatro letras que sustentam o mundo moderno. Afinal, nos grandes sistemas, os melhores segredos quase nunca aparecem na tela do terminal; eles vivem na arquitetura que faz tudo funcionar.