Translate

Mostrar mensagens com a etiqueta AOR. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta AOR. Mostrar todas as mensagens

segunda-feira, 27 de abril de 2026

🔥💣 CICS TOR + AOR NA VEIA — O LAB QUE TRANSFORMA SEU MAINFRAME EM UM CLUSTER DE GUERRA 💣🔥

 

Bellacosa Mainframe CICS TOR AOR na pratica

🔥💣 CICS TOR + AOR NA VEIA — O LAB QUE TRANSFORMA SEU MAINFRAME EM UM CLUSTER DE GUERRA 💣🔥

Se você já leu teoria e ainda não “atravessou o portal” do TOR/AOR… relaxa. Isso é clássico. CICS distribuído só faz sentido quando você monta, quebra e conserta. Então bora pro LAB estilo Bellacosa: mão na massa, sem firula, com dicas de quem já tomou S0C4 na madrugada 😄


🧠 VISÃO RÁPIDA (SEM ENROLAÇÃO)

  • TOR (Terminal Owning Region)
    👉 Onde os terminais conectam (3270 / usuários)
  • AOR (Application Owning Region)
    👉 Onde os programas COBOL rodam
  • Comunicação: MRO (Multi-Region Operation) via ISC (Inter-System Communication)

🧪 LAB — ARQUITETURA

[ USER / 3270 ]
|
(TOR)
|
MRO / ISC
|
(AOR)
|
DB2 / VSAM

⚙️ PRÉ-REQUISITOS

  • CICS TS instalado (qualquer versão moderna serve)
  • 2 regiões CICS (ou 2 STCs diferentes)
  • VTAM ativo
  • JES2 rodando
  • RACF (opcional, mas recomendado)

🏗️ PASSO 1 — CRIAR AS DUAS REGIÕES

Você precisa de:

  • CICSTOR
  • CICSAOR

👉 Copie uma região base:

//COPYTOR EXEC PGM=IEBCOPY

Crie duas cópias do DFHRPL / DFHCSD

💡 Dica Bellacosa:
Nunca compartilhe DFHCSD no começo. Separe. Depois você evolui.


⚙️ PASSO 2 — CONFIGURAR TOR

No TOR:

  • Sem lógica de negócio
  • Só roteamento

RDO (CEDA)

DEFINE TERMINAL(...)
DEFINE CONNECTION(AORCONN)
DEFINE SESSION(AORSESS)
DEFINE SYSID(AOR1)

⚙️ PASSO 3 — CONFIGURAR AOR

No AOR:

  • Programas ativos
  • Transações reais
DEFINE PROGRAM(MYPROG)
DEFINE TRANSACTION(MYTX)

💡 Aqui é onde mora o COBOL raiz.


🔗 PASSO 4 — CONFIGURAR MRO (O PULO DO GATO)

No TOR:

DEFINE CONNECTION(AOR1)
GROUP(MRO)
NETNAME(AOR1)

DEFINE SESSION(AOR1)
CONNECTION(AOR1)
PROTOCOL(LU62)

No AOR:

DEFINE CONNECTION(TOR1)
DEFINE SESSION(TOR1)

🔥 PASSO 5 — TRANSACTION ROUTING

No TOR:

DEFINE TRANSACTION(MYTX)
PROGRAM(MYPROG)
REMOTESYSTEM(AOR1)

💥 BOOM: agora o TOR encaminha pro AOR


🧪 PASSO 6 — TESTE

  1. Loga no TOR
  2. Digita MYTX
  3. Execução ocorre no AOR

👉 Se funcionar: você virou outro profissional
👉 Se não funcionar: bem-vindo ao mundo real 😄


🚨 TROUBLESHOOTING (OU “POR QUE NÃO FUNCIONA?”)

❌ SYSIDERR

  • SYSID não definido igual nos dois lados

❌ APPC / ISC DOWN

  • VTAM não levantou sessão

❌ TRANSID NOT FOUND

  • Definição não está no TOR

❌ AEI0 / AEY9

  • Problema de routing / security

💡 Dica de ouro:
Use:

CEMT I CONN
CEMT I SESS

💣 DICAS DE GUERRA (ESSAS NÃO TEM EM LIVRO)

  • TOR NÃO roda lógica → se rodar, você já errou arquitetura
  • AOR pode escalar horizontalmente
  • MRO local é mais simples que IPIC (comece por ele!)
  • Sempre versione DFHCSD
  • Nome de SYSID tem que bater EXATAMENTE

🧠 CURIOSIDADES (RAIZ MAINFRAME)

  • TOR/AOR surgiu para escala antes da nuvem existir
  • É basicamente um load balancer dos anos 80
  • Grandes bancos usam isso até hoje com dezenas de AORs

📦 EXEMPLO REAL (SIMPLIFICADO)

TOR → recebe 5000 usuários
AOR1 → contas
AOR2 → crédito
AOR3 → investimentos

👉 Cada AOR especializado
👉 TOR só roteia


📚 MATERIAL DE APOIO (OURO PURO)

Se você quer atravessar de vez:

  • IBM CICS Transaction Server Documentation (IBM Docs)
  • Redbook:
    👉 CICS Intercommunication Guide
  • Curso oficial IBM:
    👉 CICS TS System Administration

💡 Dica sincera:
O melhor material ainda é… quebrar ambiente e arrumar


🧪 DESAFIO FINAL (NÍVEL HARD)

  • Crie 2 AORs
  • Faça load balancing manual
  • Simule falha de um AOR
  • Veja o TOR redirecionando

👉 Se fizer isso: você não é mais iniciante


💥 FECHAMENTO ESTILO BELLOCAZA

CICS distribuído não é teoria.
É arquitetura viva.

Você não aprende lendo…
👉 aprende quando dá erro às 3 da manhã e você resolve.

Bellacosa Mainframe mão na massa CICS TOR AOR

🔥💣 LAB COMPLETO CICS TOR + AOR — DO ZERO AO “ROUTING FUNCIONANDO” 💣🔥

JCL + DFHCSD + RDO + TESTE REAL (estilo Bellacosa: direto ao ponto, mas com os macetes que evitam horas de dor)

Objetivo: levantar duas regiões CICS (TOR e AOR), configurar MRO/ISC, publicar uma transação roteada e testar ponta a ponta.


🧠 ARQUITETURA DO LAB

[ 3270 USER ]
|
TOR (CICSTOR)
|
MRO / ISC
|
AOR (CICSAOR)
|
PROG COBOL / VSAM

📦 CONVENÇÕES USADAS

  • TOR: CICSTOR (SYSID = TOR1)
  • AOR: CICSAOR (SYSID = AOR1)
  • Transação: MYTX
  • Programa: MYPROG
  • Grupo RDO: GRPTOR, GRPAOR, GRPMRO

💡 Regra de ouro: nomes idênticos (SYSID/CONNECTION/SESSION) nos dois lados — 80% dos erros somem aqui.


🏗️ 1) PROVISIONAR AS REGIÕES (JCL)

▶️ CICSTOR (TOR)

//CICSTOR PROC
//CICS EXEC PGM=DFHSIP,REGION=0M,
// PARM='CICSTOR,SYSID=TOR1'
//STEPLIB DD DSN=CICS.SDFHLOAD,DISP=SHR
//DFHCSD DD DSN=CICSTOR.DFHCSD,DISP=SHR
//DFHRPL DD DSN=CICSTOR.LOADLIB,DISP=SHR
//DFHPRINT DD SYSOUT=*
//DFHLOG DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD DUMMY

▶️ CICSAOR (AOR)

//CICSAOR PROC
//CICS EXEC PGM=DFHSIP,REGION=0M,
// PARM='CICSAOR,SYSID=AOR1'
//STEPLIB DD DSN=CICS.SDFHLOAD,DISP=SHR
//DFHCSD DD DSN=CICSAOR.DFHCSD,DISP=SHR
//DFHRPL DD DSN=CICSAOR.LOADLIB,DISP=SHR
//DFHPRINT DD SYSOUT=*
//DFHLOG DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD DUMMY

💡 Dica Bellacosa:
Separe DFHCSD por região no início. Compartilhar cedo = confusão garantida.


🧱 2) INICIALIZAR DFHCSD (SE AINDA NÃO EXISTIR)

//DEFCTLG EXEC PGM=DFHCSDUP
//STEPLIB DD DSN=CICS.SDFHLOAD,DISP=SHR
//DFHCSD DD DSN=CICSTOR.DFHCSD,DISP=SHR
//SYSIN DD *
DEFINE GROUP(GRPTOR) DESCRIPTION(TOR BASE)
DEFINE GROUP(GRPMRO) DESCRIPTION(MRO TOR)
/*

Repita para AOR mudando dataset e grupos (GRPAOR, GRPMRO).


🔗 3) RDO — MRO (CONNECTION + SESSION + SYSID)

▶️ NO TOR (CICSTOR)

CEDA DEF SYSID(AOR1) GROUP(GRPMRO)

CEDA DEF CONNECTION(AOR1) GROUP(GRPMRO)
NETNAME(AOR1)
ACCESSMETHOD(VTAM)

CEDA DEF SESSION(AOR1) GROUP(GRPMRO)
CONNECTION(AOR1)
PROTOCOL(LU62)
MAXIMUM(10)

▶️ NO AOR (CICSAOR)

CEDA DEF SYSID(TOR1) GROUP(GRPMRO)

CEDA DEF CONNECTION(TOR1) GROUP(GRPMRO)
NETNAME(TOR1)
ACCESSMETHOD(VTAM)

CEDA DEF SESSION(TOR1) GROUP(GRPMRO)
CONNECTION(TOR1)
PROTOCOL(LU62)
MAXIMUM(10)

💡 Macete crítico:
NETNAME deve bater com definição VTAM/APPLID.


🧠 4) AOR — PROGRAMA + TRANSAÇÃO

CEDA DEF PROGRAM(MYPROG) GROUP(GRPAOR)
LANGUAGE(COBOL)

CEDA DEF TRANSACTION(MYTX) GROUP(GRPAOR)
PROGRAM(MYPROG)

💻 COBOL EXEMPLO (MYPROG)

IDENTIFICATION DIVISION.
PROGRAM-ID. MYPROG.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-MSG PIC X(40) VALUE 'RODANDO NO AOR COM SUCESSO'.

PROCEDURE DIVISION.
EXEC CICS SEND TEXT FROM(WS-MSG)
ERASE FREEKB
END-EXEC.
EXEC CICS RETURN END-EXEC.

🚀 5) TOR — TRANSACTION ROUTING

👉 Aqui acontece a mágica

CEDA DEF TRANSACTION(MYTX) GROUP(GRPTOR)
PROGRAM(MYPROG)
REMOTESYSTEM(AOR1)

💥 Isso diz:
“Quando digitarem MYTX no TOR → manda pro AOR1”


▶️ 6) SUBIR AS REGIÕES

//S TOR
//S AOR

Ou via JES2:

/S CICSTOR
/S CICSAOR

🧪 7) TESTE REAL

  1. Loga no TOR
  2. Digita: MYTX
  3. Resultado esperado:
RODANDO NO AOR COM SUCESSO

👉 Se apareceu: você DOMINOU MRO básico


🚨 8) TROUBLESHOOTING RAIZ

🔍 Ver conexões

CEMT I CONN
CEMT I SESS

🔴 Problemas clássicos

  • SYSIDERR → SYSID não bate
  • ISC CLOSED → VTAM não subiu
  • AEY9 → routing errado
  • NOTAUTH → RACF bloqueando

💣 DICAS DE PRODUÇÃO (OURO)

  • Nunca misture lógica no TOR
  • Use múltiplos AORs para escala
  • Versione DFHCSD (backup sempre!)
  • Comece com MRO → depois evolua pra IPIC
  • Monitore com SMF 110

🧠 CURIOSIDADE DE ARQUITETURA

TOR/AOR é literalmente o ancestral do microserviço + load balancer.
Década de 80… já resolvendo problema de escala que muita stack moderna ainda sofre 😄


📚 MATERIAL DE APOIO (SE QUISER IR MAIS FUNDO)

  • IBM CICS Transaction Server Docs (IBM)
  • Redbook: CICS Intercommunication Guide
  • CEDA / CEMT Reference Guide

🧪 DESAFIO HARD (PRÓXIMO NÍVEL)

  • Criar 2 AORs (AOR1 + AOR2)
  • Duplicar MYPROG
  • Alternar REMOTESYSTEM manualmente
  • Simular queda de AOR1

👉 Se fizer isso… você já pensa como arquiteto CICS


💥 FECHAMENTO

Isso aqui não é só um lab.
É o momento que separa quem leu sobre CICS de quem opera CICS de verdade.





segunda-feira, 27 de maio de 2024

Resiliência IBM Z – O Coração das Aplicações Resilientes: Como CICS, Db2, MQ e IMS - Parte V

 

Bellacosa Mainframe e a resiliencia ibm z parte v

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

Parte V – O Coração das Aplicações Resilientes: Como CICS, Db2, MQ e IMS Mantêm Milhões de Transações Sempre Disponíveis

"Hardware poderoso impressiona. Mas são as aplicações que entregam valor ao negócio. O verdadeiro desafio é garantir que elas continuem funcionando mesmo quando tudo ao redor muda."

Até aqui nossa jornada mostrou que a Resiliência no IBM Z não depende apenas de computadores robustos.

Conhecemos conceitos como RAS, SLA e Disaster Recovery.

Descobrimos como o hardware foi projetado para detectar falhas antes mesmo que elas aconteçam.

Vimos como o Parallel Sysplex permite que vários mainframes trabalhem como um único sistema.

Também aprendemos que o armazenamento IBM Z é inteligente, automatizado e capaz de crescer sem interromper o negócio.

Mas falta responder uma pergunta.

Quem realmente atende o cliente?

Quem responde uma consulta bancária?

Quem realiza uma transferência PIX?

Quem grava um pagamento?

Quem consulta uma apólice de seguro?

Quem processa uma compra no cartão de crédito?

A resposta está no conjunto de tecnologias conhecido como middleware.

São elas que transformam toda aquela infraestrutura invisível em serviços utilizados diariamente por milhões de pessoas.

Os conceitos desta parte abrangem IBM MQ, IBM Db2 for z/OS, CICS, CICS Transaction Server (CICS TS), z/OS Workload Manager Health API, Automatic Restart Manager (ARM), CICSplex, TOR, AOR, DOR, FOR, IMS, IMS DB, Transaction Manager, HALDB, Fast Database Recovery (FDBR) e IMS Database Recovery Control (DBRC). Esses componentes aparecem na seção final do glossário IBM Z Resiliency.


O Que é Middleware?

Imagine uma cidade.

Existe energia elétrica.

Existe abastecimento de água.

Existe internet.

Existe transporte.

Tudo isso representa a infraestrutura.

Mas quem realmente atende o cidadão?

Os hospitais.

Os bancos.

Os supermercados.

As escolas.

No IBM Z acontece exatamente a mesma coisa.

Hardware, Storage e Sysplex representam a infraestrutura.

CICS, Db2, MQ e IMS representam os serviços utilizados pelo negócio.

É ali que mora a aplicação COBOL.


CICS – O Grande Atendente do Mainframe

Poucas tecnologias marcaram tanto a história da computação quanto o Customer Information Control System, mais conhecido como CICS.

Imagine uma agência bancária.

Cada cliente chega ao caixa.

Faz uma solicitação.

Recebe uma resposta.

Sai.

O próximo cliente é atendido.

O CICS faz exatamente isso.

Milhares de usuários enviam requisições simultaneamente.

O CICS organiza tudo.

Distribui recursos.

Executa programas COBOL.

Gerencia transações.

Controla segurança.

Coordena acesso aos dados.

Sem ele, grande parte das aplicações online simplesmente não existiria.


CICS Transaction Server

O CICS TS representa a evolução moderna do CICS.

Hoje ele suporta:

  • APIs REST;

  • JSON;

  • Web Services;

  • Java;

  • Eventos;

  • Integração com Cloud;

  • Containers e Channels;

  • Threadsafe;

  • OpenTelemetry;

  • Segurança moderna.

Muita gente imagina que o CICS ficou preso aos terminais verdes.

Na realidade ele conversa diariamente com aplicativos Android, iPhones, internet banking, caixas eletrônicos e sistemas distribuídos.

O COBOL continua executando.

A tecnologia ao redor evoluiu.


Db2 for z/OS – O Guardião dos Dados

Toda empresa possui seu patrimônio.

No banco...

São as contas.

Na seguradora...

São as apólices.

Na companhia aérea...

São as reservas.

Quem protege essas informações?

O Db2.

Ele garante:

  • consistência;

  • concorrência;

  • recuperação;

  • integridade;

  • desempenho.

Quando dois milhões de pessoas consultam saldo simultaneamente, o Db2 coordena milhares de operações concorrentes sem comprometer a integridade dos dados.


IBM MQ – O Carteiro que Nunca Dorme

Imagine uma empresa gigantesca.

Nem todos os departamentos trabalham no mesmo horário.

Mesmo assim as mensagens precisam chegar.

O IBM MQ resolve exatamente esse problema.

Ele entrega mensagens com segurança.

Mesmo que o destinatário esteja temporariamente indisponível.

Isso desacopla aplicações.

Aumenta a disponibilidade.

Facilita integrações.

É por isso que tantas arquiteturas modernas utilizam filas.


Quando Tudo Acontece ao Mesmo Tempo

Imagine um PIX.

Em poucos segundos acontecem dezenas de operações.

O aplicativo envia a solicitação.

O CICS recebe a transação.

O COBOL valida regras de negócio.

O Db2 consulta contas.

O MQ envia notificações.

Outro sistema recebe a mensagem.

Tudo precisa acontecer praticamente em tempo real.

Se qualquer componente falhar...

Toda a experiência do cliente será afetada.

É por isso que a Resiliência é tão importante.


CICSplex – Um CICS Nunca Vem Sozinho

Assim como existe o Parallel Sysplex...

Também existe o CICSplex.

Ele reúne diversos ambientes CICS trabalhando em conjunto.

Para o usuário...

Existe apenas um sistema.

Na realidade podem existir dezenas de regiões distribuindo carga automaticamente.


TOR – Terminal Owning Region

Imagine a recepção de um grande hospital.

Ela recebe os pacientes.

Mas não realiza cirurgias.

O TOR funciona assim.

Ele recebe as conexões dos usuários.

Depois encaminha cada solicitação para outra região responsável pelo processamento.


AOR – Application Owning Region

Agora chegamos ao verdadeiro coração da aplicação.

É na AOR que executam os programas COBOL.

Toda lógica de negócio vive aqui.

Quanto mais regiões AOR existirem...

Maior poderá ser a capacidade de processamento.


FOR – File Owning Region

Algumas aplicações acessam milhares de arquivos VSAM.

Em vez de cada região abrir esses arquivos individualmente...

Existe a FOR.

Ela centraliza esse acesso.

Reduz conflitos.

Melhora desempenho.

Simplifica administração.


DOR – Data Owning Region

A DOR segue filosofia semelhante.

Ela concentra determinados recursos de dados compartilhados entre diversas aplicações.

Essa separação facilita manutenção e escalabilidade.


WLM Health API

Lembra do Workload Manager?

Agora imagine que o próprio middleware possa informar ao WLM seu estado de saúde.

É exatamente essa a função da Health API.

O WLM deixa de observar apenas consumo de CPU.

Ele passa a considerar também a qualidade do serviço entregue pelas aplicações.


Automatic Restart Manager

Na Parte III conhecemos o ARM.

Agora podemos entender seu impacto real.

Se uma região CICS terminar inesperadamente...

O ARM pode reiniciá-la automaticamente.

Sem operadores.

Sem intervenção humana.

Sem perda significativa de disponibilidade.


IMS – O Veterano Que Continua Jovem

Muito antes da internet existir...

O IMS já processava milhões de transações.

Hoje continua fazendo exatamente isso.

O Information Management System permanece como um dos ambientes transacionais mais rápidos do mundo.

Muitas aplicações financeiras ainda dependem dele diariamente.


IMS DB

O banco de dados IMS possui características próprias.

Sua organização hierárquica oferece desempenho extremamente elevado para determinadas cargas de trabalho.

Quando corretamente modelado, consegue responder consultas com velocidade impressionante.


Transaction Manager

O IMS TM coordena o processamento online.

Recebe requisições.

Controla filas.

Executa programas.

Gerencia recuperação.

Mantém a integridade das transações.

É o equivalente, dentro do universo IMS, ao papel desempenhado pelo CICS em inúmeras aplicações.


HALDB – Crescendo Sem Limites

Com o passar dos anos, algumas bases IMS tornaram-se gigantescas.

O High Availability Large Database foi criado para resolver esse desafio.

Ele divide grandes bancos de dados em partições.

Assim é possível:

  • aumentar capacidade;

  • reduzir tempo de manutenção;

  • melhorar disponibilidade;

  • facilitar reorganizações.

Tudo isso mantendo o sistema online.


Fast Database Recovery

Imagine um acidente.

Quanto mais rápido a recuperação...

Menor o impacto.

O FDBR acelera a recuperação das bases IMS após falhas.

Isso reduz significativamente o RTO.


IMS Database Recovery Control

Toda recuperação precisa ser coordenada.

O DBRC registra informações fundamentais sobre backups, logs e processos de recuperação.

Ele garante que as bases sejam restauradas corretamente.

Sem perda de consistência.


O Que um Programador COBOL Deve Aprender?

Muitos iniciantes acreditam que basta dominar a linguagem COBOL.

Na prática...

O código representa apenas uma parte da aplicação.

Um profissional IBM Z moderno precisa compreender:

  • como o CICS gerencia transações;

  • como o Db2 protege dados;

  • como o MQ integra sistemas;

  • como o IMS processa grandes volumes;

  • como a infraestrutura garante disponibilidade.

Quanto maior essa visão...

Maior será sua capacidade de construir aplicações resilientes.


O Legado do IBM Z

Existe um motivo pelo qual bancos processam bilhões de transações utilizando tecnologias criadas há décadas.

Elas nunca pararam de evoluir.

O CICS conversa com APIs REST.

O Db2 trabalha com analytics e inteligência artificial.

O MQ conecta aplicações distribuídas.

O IMS continua ampliando desempenho e disponibilidade.

Nada permaneceu parado no tempo.

O legado do IBM Z não é tecnologia antiga.

É tecnologia que amadureceu continuamente sem abandonar aquilo que sempre fez melhor: processar transações críticas com confiabilidade, desempenho e resiliência.

No próximo capítulo do Holocron da Resiliência IBM Z, concluiremos nossa jornada explorando IBM Copy Services Manager (CSM), Metro Mirror, Global Mirror, XRC, Zero Data Loss (ZDL), Coupling Data Sets (CDS), Business Continuity Plan (BCP) e as estratégias que permitem proteger informações mesmo diante de desastres de grande escala, fechando o ciclo completo da Resiliência no IBM Z.


quarta-feira, 21 de novembro de 2018

CICS TOR sem Mistérios para Programadores COBOL

 

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:

  1. Conceitos básicos do CICS.

  2. Estrutura de uma Region.

  3. PCT, PPT, FCT e TCT.

  4. BMS e Mapsets.

  5. COMMAREA.

  6. Channels e Containers.

  7. Temporary Storage (TSQ) e Transient Data (TDQ).

  8. Syncpoint e recuperação.

  9. TOR, AOR, FOR e CICSPlex SM.

  10. 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.


terça-feira, 13 de novembro de 2018

O Mistério da Rota Invisível : Quando um Jovem Programador COBOL Descobriu que Seu Programa Nunca Escolhia Sozinho Onde Ser Executado

 

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:

  1. Aprenda primeiro o ciclo de vida de uma transação CICS.

  2. Entenda a diferença entre TOR, AOR e FOR.

  3. Estude o papel do CICSPlex SM como gerenciador do ambiente.

  4. Depois mergulhe em Dynamic Transaction Routing (DTR) e compare-o com o roteamento estático.

  5. 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.

  6. 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.


segunda-feira, 15 de outubro de 2018

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

 

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.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988