Translate

Mostrar mensagens com a etiqueta Application Owning Region. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Application Owning Region. Mostrar todas as mensagens

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