 |
| Bellacosa Mainframe apresenta cics tor |
☕ Um Café no Bellacosa Mainframe
CICS TOR sem Mistérios para Programadores COBOL
Quando um Programador Descobre que Nem Todo Programa COBOL Conversa Diretamente com o Usuário... Existe uma Recepção Inteligente que Organiza Todo o Data Center Antes Mesmo do Primeiro EXEC CICS
"Não entre em pânico." — O Guia do Mochileiro das Galáxias
Se Douglas Adams tivesse trabalhado na IBM durante os anos 80, provavelmente escreveria um capítulo chamado "A Vida, o Universo e as Regiões CICS". Afinal, poucas arquiteturas conseguem parecer tão misteriosas à primeira vista e, ao mesmo tempo, tão elegantemente organizadas quanto um CICSplex.
Para quem está iniciando em COBOL Mainframe, é muito comum imaginar que o usuário digita uma transação, o programa COBOL é executado, consulta o DB2 e devolve a resposta.
Na prática...
...isso raramente acontece dessa forma.
Existe uma verdadeira cidade funcionando por trás das cortinas.
E um dos personagens mais importantes dessa cidade chama-se TOR (Terminal-Owning Region).
Hoje vamos abrir a porta do Data Center, colocar uma toalha no ombro (você entendeu a referência...) e descobrir como funciona esse universo.
Antes de tudo: o que é uma Região CICS?
Imagine que o CICS seja um enorme shopping center.
Dentro dele existem dezenas de lojas.
Cada loja possui funcionários, estoque, computadores e clientes.
No Mainframe acontece algo parecido.
Cada CICS Region é um ambiente independente executando dentro do z/OS.
Ela possui memória própria.
Recursos próprios.
Filas.
Programas.
Transações.
Arquivos.
Conexões.
E tudo isso funciona de maneira totalmente isolada das demais regiões.
Uma região pode executar centenas de milhares de transações diariamente.
Grandes bancos chegam facilmente à casa dos milhões.
O primeiro erro de todo iniciante
Quase todo programador COBOL pensa assim:
Usuário
↓
Programa COBOL
↓
DB2
↓
Resposta
É simples.
Faz sentido.
Mas...
...não é assim que um ambiente corporativo funciona.
Na realidade existe uma arquitetura muito mais sofisticada.
Usuário
↓
TOR
↓
AOR
↓
FOR
↓
DB2
↓
FOR
↓
AOR
↓
TOR
↓
Usuário
De repente apareceu um monte de siglas.
Vamos decifrá-las.
Por que dividir tudo?
Imagine um restaurante.
Você chega.
A primeira pessoa que encontra é a recepcionista.
Ela pergunta:
— Quantas pessoas?
— Mesa para fumantes?
— Possui reserva?
Ela não cozinha.
Não prepara sobremesa.
Não faz pizza.
Ela apenas organiza o fluxo.
Agora imagine se o chef precisasse abandonar o fogão toda vez que alguém chegasse à porta.
O restaurante entraria em colapso.
O mesmo acontece no CICS.
Bem-vindo ao TOR
TOR significa
Terminal-Owning Region
O nome parece complicado.
Na prática significa:
a região dona dos terminais.
Ela controla toda a comunicação com o mundo externo.
É ela quem recebe:
terminais 3270
sessões TCP/IP
conexões IPIC
usuários
requisições
logons
transações
Ela é literalmente a recepção do Data Center.
A analogia do aeroporto
Imagine um aeroporto.
Você entra.
Vai ao check-in.
Despacha bagagem.
Recebe seu cartão de embarque.
Somente depois segue para o portão correto.
O check-in nunca pilota o avião.
Da mesma forma...
O TOR nunca executa a lógica do programa COBOL.
Ele apenas encaminha.
O verdadeiro trabalho do TOR
Quando um usuário digita:
BANK
Ou
CUST
Ou
MENU
O TOR faz várias coisas quase instantaneamente.
Ele verifica:
quem é o usuário
de qual terminal veio
qual transação foi digitada
qual AOR está disponível
qual AOR possui menos carga
qual política de roteamento deve ser utilizada
Somente depois encaminha a requisição.
Tudo isso acontece em poucos milissegundos.
O grande maestro invisível
Imagine uma orquestra.
O maestro não toca violino.
Não toca trompete.
Não toca piano.
Mesmo assim...
Sem ele...
...a música vira caos.
O TOR é exatamente isso.
Ele coordena.
Distribui.
Organiza.
Sincroniza.
Então quem executa o COBOL?
Entra em cena outro personagem.
O famoso:
AOR
Application-Owning Region.
Agora sim.
Aqui vivem:
programas COBOL
programas PL/I
programas C
Java
BMS
MAPSETs
lógica de negócio
O AOR é onde realmente acontece o processamento.
Quando você escreve:
EXEC SQL
ou
EXEC CICS LINK
provavelmente será um AOR quem executará esse código.
O FOR entra na história
Existe ainda outra região.
FOR.
File-Owning Region.
Ela concentra:
VSAM
BDAM
arquivos compartilhados
alguns recursos de acesso
Embora muitas arquiteturas modernas permitam que o AOR acesse diretamente o DB2, em ambientes clássicos era comum utilizar FOR para centralizar determinados recursos físicos.
É uma forma elegante de separar responsabilidades.
O caminho completo de uma transação
Vamos acompanhar uma consulta de saldo.
Imagine João acessando o Internet Banking.
Ele solicita:
SALDO
O que acontece?
Primeiro:
João
↓
TOR
O TOR identifica a transação.
Depois:
↓
AOR-03
O programa COBOL inicia.
EXEC SQL
SELECT SALDO
FROM CONTAS
O DB2 responde.
O COBOL monta a tela.
A resposta retorna.
DB2
↓
AOR
↓
TOR
↓
João
João acredita que falou diretamente com o banco.
Na verdade...
Conversou apenas com o TOR.
O TOR conhece todos os usuários
Ele administra:
sessões
conexões
terminais
usuários ativos
estado das conexões
Pense nele como um gigantesco porteiro.
Ele sabe exatamente quem entrou no prédio.
O TOR conhece os programas?
Não.
Quem conhece programas é o AOR.
O TOR conhece caminhos.
Não conhece regras de negócio.
A mágica do balanceamento
Agora imagine:
100 mil pessoas consultando saldo.
Sem TOR:
Usuários
↓
AOR
Resultado?
Sobrecarga.
Com TOR:
Usuários
↓
TOR
↓
AOR1
AOR2
AOR3
AOR4
AOR5
Agora a carga fica distribuída.
Esse conceito hoje é chamado de:
Load Balancing.
Mas o CICS fazia isso quando a internet ainda engatinhava.
O CICS inventou a Cloud antes da Cloud?
Curiosamente...
Em vários aspectos...
Sim.
Observe.
Cloud moderna:
Gateway
↓
Load Balancer
↓
Microservices
↓
Database
CICS:
TOR
↓
AOR
↓
FOR
↓
DB2
A semelhança impressiona.
Muitas ideias que hoje parecem revolucionárias já existiam nos grandes mainframes há décadas.
O papel do CICSPlex
Até agora vimos várias regiões.
Mas quem coordena tudo?
Entra em cena o:
CICSPlex SM.
Ele funciona como um cérebro.
Conhece todas as regiões.
Monitora carga.
Falhas.
Disponibilidade.
Prioridades.
Com essas informações o TOR consegue decidir:
"AOR-2 está sobrecarregado."
"Envie para AOR-4."
Tudo automaticamente.
Quando um AOR morre
Imagine que o AOR-3 sofreu um ABEND.
O que acontece?
Sem TOR:
Todos os usuários falham.
Com TOR:
As novas transações passam automaticamente para outro AOR disponível.
Na maioria das vezes o usuário nem percebe.
Esse é um dos grandes segredos da disponibilidade do IBM Z.
O problema chamado Affinity
Nem toda transação pode mudar livremente de AOR.
Imagine um programa antigo.
Ele grava informações temporárias na memória.
Na próxima tela...
Ele espera encontrar aquelas informações.
Se o usuário cair em outro AOR...
Elas desapareceram.
Isso chama-se:
Transaction Affinity.
É um dos grandes desafios na modernização de aplicações CICS.
O que os arquitetos modernos fazem?
Evitam afinidade.
Preferem guardar contexto em:
TSQ compartilhada
Temporary Storage compartilhada
Channels e Containers
DB2
MQ
recursos compartilhados
Assim qualquer AOR pode continuar o processamento.
Curiosidade histórica
Nos anos 70 e 80 era comum existir apenas uma região CICS.
Tudo ficava nela.
Com o crescimento dos bancos isso tornou-se inviável.
Foi então que a IBM começou a incentivar arquiteturas distribuídas dentro do próprio Mainframe.
Nascia a divisão entre:
TOR
AOR
FOR
Mais tarde veio o CICSPlex.
Hoje essa arquitetura é praticamente padrão em ambientes corporativos.
Onde entram os terminais 3270?
Eles normalmente se conectam ao TOR.
Nunca diretamente ao AOR.
Isso simplifica administração.
Caso um AOR precise ser reiniciado...
Os terminais continuam conectados ao TOR.
O que acontece durante uma manutenção?
Imagine que o AOR-2 será atualizado.
O administrador simplesmente retira aquele AOR do roteamento.
O TOR passa a enviar novas transações para:
AOR-1
AOR-3
AOR-4
Quando o AOR-2 retorna...
Ele volta automaticamente ao balanceamento.
Nenhum usuário percebe.
Isso é engenharia de disponibilidade.
O TOR é um Firewall?
Não.
Mas ele funciona como um ponto central de entrada.
Por isso muitas políticas de segurança começam justamente nele.
É muito mais fácil controlar milhares de conexões em poucos TORs do que em dezenas de AORs espalhados.
Como isso aparece para o programador COBOL?
Na maioria das vezes...
Não aparece.
Você escreve:
EXEC CICS RECEIVE MAP('TELA1')
END-EXEC.
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTE
END-EXEC.
EXEC CICS SEND MAP('TELA2')
END-EXEC.
Você nem imagina que por trás disso existe uma infraestrutura inteira tomando decisões sobre roteamento, disponibilidade e balanceamento.
Esse é justamente o objetivo da arquitetura: esconder a complexidade da infraestrutura para que o desenvolvedor possa focar na regra de negócio.
Dicas para quem quer trabalhar com CICS
Se você está começando agora, aprenda nesta ordem:
Conceitos básicos do CICS.
Estrutura de uma Region.
PCT, PPT, FCT e TCT.
BMS e Mapsets.
COMMAREA.
Channels e Containers.
Temporary Storage (TSQ) e Transient Data (TDQ).
Syncpoint e recuperação.
TOR, AOR, FOR e CICSPlex SM.
CICS Explorer e ferramentas modernas de administração.
Com essa base, você entenderá não apenas como escrever programas, mas como eles realmente funcionam dentro de um ambiente corporativo.
Easter Egg Bellacosa Mainframe ☕
Imagine que o Data Center seja a Estrela da Morte.
O usuário pilota uma pequena nave e solicita permissão para atracar.
O TOR é o controlador de tráfego do hangar. Ele verifica a identidade da nave, consulta quais docas estão livres e direciona o piloto para o setor correto.
Os AORs são os departamentos especializados: engenharia, armamentos, navegação, inteligência e manutenção dos TIE Fighters.
O FOR é o gigantesco arquivo imperial, onde ficam armazenados todos os planos secretos, documentos e registros.
O DB2 é o Holocron de dados do Império, contendo milhões de informações críticas.
Enquanto isso, o CICSPlex SM é o Grande Almirante Thrawn observando toda a frota em um enorme mapa holográfico, redistribuindo recursos e garantindo que nenhuma região fique sobrecarregada.
O piloto acredita que falou apenas com uma porta automática. Na realidade, dezenas de sistemas trabalharam em perfeita sincronia antes que o hangar sequer abrisse.
Conclusão: a genialidade invisível do CICS
O Terminal-Owning Region (TOR) é uma das peças mais elegantes da arquitetura CICS. Embora raramente execute uma única linha de código COBOL, ele é responsável por tornar possível o funcionamento de ambientes que atendem milhões de usuários diariamente.
Ao separar a recepção das conexões (TOR) do processamento da lógica (AOR) e, quando necessário, da administração dos recursos de dados (FOR), o CICS alcança um nível de escalabilidade, disponibilidade e organização que continua impressionando mesmo quando comparado às arquiteturas modernas de microsserviços.
Para o programador COBOL iniciante, entender essa divisão muda completamente a forma de enxergar o Mainframe. Você deixa de ver apenas um programa executando comandos EXEC CICS e passa a compreender que existe uma verdadeira metrópole digital funcionando nos bastidores, onde cada região tem uma missão específica e todas cooperam para entregar respostas em frações de segundo.
No fim das contas, o TOR é como a recepção de um hotel cinco estrelas: ninguém vai ao hotel para conversar com a recepcionista, mas sem ela a experiência inteira deixaria de funcionar. E essa é uma das maiores lições da arquitetura IBM Z: os sistemas mais robustos não dependem de um componente fazer tudo, mas de muitos componentes fazendo exatamente aquilo em que são especialistas.
Sem comentários:
Enviar um comentário