Translate

Mostrar mensagens com a etiqueta TOR. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta TOR. 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.


domingo, 2 de janeiro de 2022

🌐 Pequena História da Internet: Da Fronteira Livre à Era da Regulação

 

Bellacosa Mainframe e uma breve historia regulatoria da internet


🌐 Pequena História da Internet: Da Fronteira Livre à Era da Regulação

1960–1980: O Nascimento da Rede

A internet nasceu de projetos militares e acadêmicos.

A ARPANET, financiada pelo Departamento de Defesa dos EUA, tinha como objetivo criar uma rede resistente e descentralizada.

O conceito revolucionário era:

Não haver um centro único de controle.

Tecnicamente, a rede foi projetada para sobreviver à destruição de partes dela.

Curiosamente, essa arquitetura descentralizada acabaria criando décadas depois enormes desafios para governos e reguladores.


1980–1995: A Era dos Pioneiros

Nessa fase a internet era usada principalmente por:

  • Universidades

  • Pesquisadores

  • Engenheiros

  • Entusiastas

Predominava uma cultura quase utópica.

Havia a sensação de que a internet seria:

  • Livre

  • Global

  • Sem fronteiras

  • Difícil de censurar

Surgiram valores que permanecem fortes até hoje:

  • Compartilhamento aberto

  • Software livre

  • Conhecimento livre

  • Privacidade

Muitos pioneiros acreditavam que os governos teriam pouca influência sobre o novo espaço digital.


1990–2005: A Explosão da Web

Com a Web de Tim Berners-Lee tudo mudou.

Milhões de pessoas passaram a acessar:

  • Sites

  • Fóruns

  • Chats

  • Blogs

  • E-mail

Nasceu a ideia do "ciberespaço".

Em 1996, John Perry Barlow publicou a famosa:

"Declaração de Independência do Ciberespaço"

O texto basicamente dizia:

"Governos do mundo, vocês não têm soberania aqui."

Hoje o documento é visto quase como o manifesto fundador do ideal libertário da internet.

Muitos realmente acreditavam que a internet escaparia para sempre do controle estatal.


2000–2010: O Primeiro Choque com a Realidade

Governos começaram a perceber que a internet não era apenas um brinquedo acadêmico.

Apareceram:

  • Fraudes online

  • Pirataria

  • Golpes

  • Terrorismo digital

  • Pornografia ilegal

  • Crimes financeiros

Os Estados responderam com:

  • Leis específicas

  • Investigações digitais

  • Cooperação internacional

Foi o início da percepção de que:

A internet não estava fora da sociedade.

Ela fazia parte dela.


2010–2020: A Era das Plataformas

Google, Facebook, YouTube, Twitter, Instagram e outras plataformas tornaram-se gigantescas.

Um fenômeno inesperado ocorreu:

Muitos governos perceberam que não precisavam controlar diretamente a internet.

Bastava regular as plataformas.

Ao mesmo tempo surgiram debates sobre:

  • Fake news

  • Moderação de conteúdo

  • Discurso de ódio

  • Privacidade

  • Vigilância

O caso Snowden em 2013 revelou programas massivos de monitoramento governamental.

Muitas pessoas ficaram chocadas ao descobrir o tamanho da vigilância digital.


2020–2030: A Era da IA

Entramos agora na fase atual.

A IA mudou novamente o jogo.

Antes a internet distribuía informação.

Agora ela também produz informação.

Temos:

  • Chatbots

  • Agentes autônomos

  • Imagens geradas por IA

  • Vídeos sintéticos

  • Vozes artificiais

  • Companheiros virtuais

As antigas categorias jurídicas começam a falhar.

Perguntas inéditas surgem:

  • Quem é responsável por uma IA?

  • Uma IA pode ter direitos?

  • Um relacionamento com IA é apenas software?

  • Um NPC consciente merece proteção?


O Grande Ciclo

Olhando a história inteira, podemos resumir em quatro fases:

Fase 1 — Utopia (1980-2000)

"A internet será livre para sempre."

Fase 2 — Confronto (2000-2015)

"Precisamos combater crimes online."

Fase 3 — Regulação (2015-2025)

"As plataformas precisam ser responsabilizadas."

Fase 4 — Consciência Artificial (2025-2040?)

"Como regular entidades digitais que se comportam como pessoas?"


O Próximo Debate

Se os últimos 30 anos foram marcados pela pergunta:

"Quem controla a informação?"

Os próximos 30 anos podem ser marcados por uma pergunta ainda mais profunda:

"O que significa ser uma pessoa em um mundo onde máquinas podem conversar, aprender, lembrar, criar vínculos emocionais e talvez um dia reivindicar algum tipo de autonomia?"

É por isso que temas aparentemente desconexos — VPNs, Tor, Westworld, bonecas robóticas, NPCs inteligentes, redes sociais e IA — acabam convergindo para uma única discussão: onde termina a liberdade individual e onde começa o interesse da sociedade em regular novas formas de comportamento digital e tecnológico?


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.


terça-feira, 10 de abril de 2018

O Mistério das Regiões Invisíveis : Como o MRO Transformou o CICS em uma Cidade Secreta Onde Cada Região Guarda um Segredo

 

Bellacosa Mainframe e o misterio das regioes invisiveis

☕ Um Café no Bellacosa Mainframe

O Mistério das Regiões Invisíveis

Como o MRO Transformou o CICS em uma Cidade Secreta Onde Cada Região Guarda um Segredo

"Naquela manhã, o operador jurava que a transação havia desaparecido. O terminal permaneceu em silêncio por menos de um segundo. Quando a resposta voltou, parecia mágica. Mas não era magia. Era engenharia. E como todo bom mistério, existiam corredores invisíveis, mensageiros silenciosos e guardiões que ninguém via..."


Prólogo — O Caso do Banco que Nunca Dormia

Imagine entrar em uma agência bancária às oito horas da manhã.

Ao mesmo tempo em que você consulta seu saldo:

  • milhares de pessoas pagam boletos;

  • empresas enviam folhas de pagamento;

  • cartões são autorizados;

  • caixas eletrônicos distribuem dinheiro;

  • aplicativos móveis fazem PIX;

  • APIs atendem fintechs;

  • internet banking consulta investimentos.

Tudo isso acontece em menos de um segundo.

Quem faz esse milagre?

Muitos responderiam:

"O CICS."

Mas essa resposta está incompleta.

A verdadeira resposta é muito mais interessante.

O CICS não trabalha sozinho.

Ele coordena uma pequena cidade.

Uma cidade composta por especialistas.

Cada edifício possui uma função.

Cada habitante conhece exatamente seu trabalho.

E todos se comunicam através de túneis invisíveis.

Esse sistema secreto atende por um nome:

MRO — Multi-Region Operation.

Hoje vamos abrir a porta desse mundo escondido.

Pegue seu café.

A investigação começou.


Capítulo 1 — Quando Um Único CICS Não Era Mais Suficiente

No início da computação corporativa era comum existir apenas uma única região CICS.

Ela fazia tudo.

Recebia usuários.

Executava COBOL.

Acessava VSAM.

Conversava com DB2.

Controlava impressoras.

Respondia terminais.

Era uma verdadeira central de operações.

Visualmente:

Usuários
     │
     ▼
+----------------+
|    CICS        |
| Tudo acontece  |
| aqui           |
+----------------+
     │
     ▼
Arquivos / DB2

Parecia perfeito.

Até que chegaram milhões de usuários.

Foi como transformar uma pequena delegacia em uma capital inteira.

A fila aumentou.

A CPU começou a sofrer.

Os tempos de resposta cresceram.

E surgiu uma pergunta:

"E se dividíssemos as responsabilidades?"

Essa simples ideia mudaria a história do CICS.


Capítulo 2 — O Nascimento da Cidade Secreta

A IBM percebeu algo extremamente elegante.

Nem todo mundo precisava fazer tudo.

Assim como uma cidade possui:

  • prefeitura;

  • hospital;

  • biblioteca;

  • fórum;

  • correios;

o CICS também poderia criar especialistas.

Nascia o conceito de Multi-Region Operation.

Agora existiam regiões especializadas.

Cada uma extremamente eficiente.

Não era mais um prédio gigantesco.

Era uma metrópole inteira.


Capítulo 3 — Conheça os Três Grandes Personagens

Se o MRO fosse um filme noir dos anos 1950, existiriam três protagonistas.

TOR

O Porteiro.

O Concierge.

O Recepcionista.

Nunca resolve o problema.

Mas sabe exatamente para quem enviar.

Ele recebe o visitante e pergunta:

"Em que posso ajudar?"

Depois encaminha a pessoa ao especialista correto.

Jamais executa o trabalho pesado.

Sua missão é apenas direcionar.


AOR

O Detetive.

Aqui mora o cérebro.

É onde vivem os programas COBOL.

Onde estão:

  • EXEC CICS

  • EXEC SQL

  • CALL

  • LINK

  • XCTL

É nessa região que a lógica de negócio acontece.

Quando alguém consulta saldo...

Quem calcula?

O AOR.

Quem faz validações?

O AOR.

Quem chama programas?

O AOR.

Ele é o verdadeiro investigador do caso.


FOR

O Arquivista.

Imagine um enorme cofre.

Centenas de estantes.

Milhões de documentos.

O FOR é responsável por guardar tudo.

VSAM.

KSDS.

RRDS.

ESDS.

Nada entra.

Nada sai.

Sem passar por ele.


Capítulo 4 — Os Túneis Invisíveis

Agora surge a pergunta.

Como essas regiões conversam?

Resposta:

IRC — Interregion Communication.

O IRC é o correio secreto da cidade.

Imagine túneis subterrâneos ligando todos os prédios.

As pessoas caminham por eles sem serem vistas.

No CICS acontece exatamente isso.

TOR
 │
 │ IRC
 ▼
AOR
 │
 │ IRC
 ▼
FOR

O usuário nunca percebe.

Para ele existe apenas uma resposta.

Mas internamente houve uma verdadeira viagem.


Capítulo 5 — A Jornada de uma Consulta de Saldo

Vamos acompanhar uma única transação.

Você abre o aplicativo do banco.

Digita sua senha.

Pressiona:

Consultar Saldo

O que acontece?

Passo 1

O pedido chega ao TOR.

O TOR olha a fila.

Existem oito AOR disponíveis.

Qual está mais livre?

Escolhe uma.


Passo 2

Via MRO.

O pedido atravessa o IRC.

Chega ao AOR.


Passo 3

O programa COBOL inicia.

Ele verifica:

  • agência;

  • conta;

  • autenticação;

  • permissões.


Passo 4

Agora precisa acessar o cadastro.

Quem possui os arquivos?

O FOR.

Nova viagem.


Passo 5

O FOR abre o VSAM.

Localiza o cliente.

Retorna:

Saldo:

R$ 8.435,91


Passo 6

O COBOL monta a tela.


Passo 7

O TOR devolve a resposta.

Tudo isso pode ocorrer em poucos milissegundos.

Parece magia.

Mas é apenas uma arquitetura brilhantemente organizada.


Capítulo 6 — O Grande Segredo da Escalabilidade

Imagine uma loja.

Existem apenas dois caixas.

Forma-se fila.

O gerente faz o quê?

Contrata mais caixas.

O mesmo ocorre com o CICS.

Hoje:

TOR

↓

AOR1
AOR2

Amanhã:

TOR

↓

AOR1
AOR2
AOR3
AOR4
AOR5

Nenhuma linha do COBOL precisou mudar.

Esse é um dos maiores poderes do MRO.

Escalar sem reescrever aplicações.

Décadas antes da computação em nuvem.


Capítulo 7 — Alta Disponibilidade

Imagine um AOR travando.

Antigamente...

Tudo parava.

Hoje:

TOR

↓

AOR1

AOR2

AOR3 (OFF)

AOR4

AOR5

As novas transações seguem para as demais regiões.

O cliente sequer percebe.

Essa capacidade é um dos motivos pelos quais bancos conseguem funcionar praticamente vinte e quatro horas por dia.


Capítulo 8 — MRO Não é ISC

Essa confusão aparece em praticamente toda entrevista técnica.

Vamos resolver isso de uma vez.

MRO

Mesmo z/OS.

Mesmo computador.

Mesma LPAR.

Regiões diferentes.


ISC

Outro computador.

Outra LPAR.

Outro ambiente.

Outra máquina.

Em outras palavras:

MRO trabalha "dentro da cidade".

ISC comunica cidades diferentes.

Uma excelente forma de memorizar.


Capítulo 9 — O CICS Antecipou os Microsserviços?

Curiosamente...

Muito antes da palavra "microsserviços" existir...

O CICS já fazia algo parecido.

Observe.

Cada região possui uma responsabilidade.

TOR:

Entrada.

AOR:

Processamento.

FOR:

Persistência.

Separação.

Especialização.

Baixo acoplamento.

Balanceamento.

Escalabilidade.

Isso soa familiar?

Sim.

Muitas ideias atribuídas às arquiteturas modernas já estavam presentes no mundo mainframe há décadas, embora implementadas de maneira diferente e com objetivos próprios.


Capítulo 10 — Como um Programador COBOL Deve Pensar

Um erro comum do iniciante é imaginar:

"Meu programa roda no CICS."

Na verdade...

Seu programa normalmente roda:

No AOR.

Quem recebeu o usuário foi outro.

Quem abriu o VSAM foi outro.

Quem fez o roteamento foi outro.

Seu COBOL é apenas uma peça da investigação.

Quanto antes compreender isso...

Mais fácil será entender:

  • performance;

  • dumps;

  • rastreamento;

  • problemas de produção;

  • roteamento.


Capítulo 11 — Onde Entram os Comandos EXEC CICS?

Quando o COBOL executa:

EXEC CICS READ FILE('CLIENTE')
END-EXEC.

Você imagina:

"CICS abriu o arquivo."

Na realidade, dependendo da arquitetura, a solicitação pode viajar:

Programa COBOL

AOR

MRO

FOR

VSAM

FOR

AOR

Programa COBOL

Essa viagem inteira acontece antes da próxima instrução COBOL ser executada.

É por isso que compreender arquitetura é tão importante quanto aprender sintaxe.


Capítulo 12 — Dicas de Ouro para Quem Está Começando

✔ Não memorize apenas siglas. Entenda a responsabilidade de cada região.

✔ Sempre desenhe o fluxo de uma transação antes de estudar comandos.

✔ Aprenda primeiro TOR, depois AOR, depois FOR e só então MRO.

✔ Quando estudar desempenho, pergunte sempre: "Em qual região estou?"

✔ Ao analisar um problema de produção, descubra primeiro onde a transação foi roteada.

✔ Entender MRO ajuda a interpretar logs, SMF, rastreamentos e ferramentas de monitoramento com muito mais clareza.


Curiosidades do CPD

☕ Alguns ambientes bancários possuem dezenas de AORs trabalhando simultaneamente.

☕ O usuário nunca sabe por qual região passou.

☕ Uma mesma transação pode ser atendida por AORs diferentes ao longo do dia.

☕ Em ambientes grandes, o número de regiões CICS pode ultrapassar uma centena, cada uma com funções específicas.

☕ Muitas arquiteturas modernas de alta disponibilidade adotam princípios semelhantes aos usados pelo CICS desde os anos 1980.


Easter Eggs do Bellacosa Mainframe 🕵️

🔎 Easter Egg #1 — O Porteiro Invisível

Assim como Alfred organizava discretamente a Mansão Wayne enquanto Batman enfrentava os vilões, o TOR raramente recebe os holofotes. Ele apenas garante que cada visitante encontre o caminho certo.


🔎 Easter Egg #2 — A Cidade Subterrânea

Os túneis do IRC lembram passagens secretas de romances policiais clássicos. O cidadão comum nunca os vê, mas toda a cidade depende deles.


🔎 Easter Egg #3 — O Arquivista

O FOR faz lembrar os grandes arquivos de bibliotecas históricas: silencioso, organizado e indispensável. Sem ele, encontrar um único registro entre milhões seria um pesadelo.


🔎 Easter Egg #4 — A Ponte para o Futuro

Quando ouvir alguém dizer que microsserviços inventaram a separação de responsabilidades, sorria. O CICS já demonstrava esse princípio décadas antes, em um contexto completamente diferente, provando que boas ideias atravessam gerações.


Perguntas de Entrevista

O que significa MRO?

Multi-Region Operation.


Qual seu objetivo?

Permitir comunicação entre regiões CICS executando no mesmo z/OS.


Quem recebe usuários?

TOR.


Quem executa COBOL?

AOR.


Quem controla VSAM?

FOR.


Quem liga tudo?

IRC através do MRO.


MRO funciona entre máquinas diferentes?

Não.

Para isso normalmente utiliza-se ISC.


Conclusão — O Mistério Resolvido

Durante décadas, milhares de profissionais observaram apenas a superfície do CICS. Viam uma tela 3270 responder em menos de um segundo e imaginavam existir apenas um grande programa fazendo todo o trabalho. A realidade é muito mais fascinante.

Por trás de cada transação existe uma verdadeira cidade invisível: porteiros que recebem visitantes, investigadores que resolvem problemas, arquivistas que protegem informações e mensageiros que percorrem túneis secretos levando pedidos e respostas em velocidade impressionante. Essa organização permitiu que o CICS acompanhasse a evolução da computação por gerações, mantendo confiabilidade, desempenho e disponibilidade em ambientes que processam milhões de transações diariamente.

Para quem está iniciando em COBOL, compreender o MRO é um divisor de águas. A partir desse momento, o CICS deixa de ser uma "caixa-preta" e passa a ser um organismo vivo, formado por regiões especializadas que cooperam de maneira elegante. Você não verá apenas comandos EXEC CICS; enxergará o caminho percorrido por cada solicitação, entenderá por que a arquitetura foi desenhada dessa forma e perceberá que muitos conceitos considerados modernos já eram praticados no universo IBM Z muito antes de se tornarem tendências.

E da próxima vez que uma consulta de saldo aparecer instantaneamente na tela, talvez você se lembre desta investigação. Em algum lugar, um TOR abriu a porta, um AOR resolveu o caso, um FOR encontrou a prova escondida em um arquivo VSAM, e o MRO garantiu que todos trabalhassem em perfeita harmonia.

Porque, no fim das contas, o maior mistério do mainframe nunca foi a velocidade.

Foi fazer parecer simples aquilo que, nos bastidores, é uma das mais elegantes obras de engenharia da história da computação.

terça-feira, 13 de março de 2018

O Arquivo Proibido do CICS : O Mistério do Guardião Invisível que Protegia Milhões de Registros

 

Bellacosa Mainframe apresenta o arquivo proibido do cics

☕ Um Café no Bellacosa Mainframe

O Arquivo Proibido do CICS

O Mistério do Guardião Invisível que Protegia Milhões de Registros

Quando um Programador COBOL Descobre que Existe uma Região Inteira Dedicada Apenas a Cuidar dos Arquivos

"Alguns homens guardam cofres. Outros guardam segredos. Mas existe uma entidade silenciosa que guarda algo muito mais valioso: os dados de uma nação inteira."

Era uma noite fria no CPD.

As luzes fluorescentes piscavam sobre quilômetros de cabos, painéis e racks metálicos. O z/OS continuava trabalhando como fazia havia décadas, sem reclamar, sem pedir férias, sem dormir.

No monitor verde de um terminal 3270 surgiu uma mensagem aparentemente comum.

READ CUSTOMER...

Poucos milissegundos depois...

RECORD RETURNED

O programador sorriu.

"Que simples."

Foi então que o velho Analista sorriu discretamente.

— Simples? Meu jovem... você acabou de assistir a uma das maiores ilusões do CICS.

O iniciante não fazia ideia.

Entre aquele READ e a resposta havia acontecido uma verdadeira operação de inteligência digna das revistas policiais noir dos anos 1950.

E no centro dessa conspiração silenciosa existia um personagem que quase ninguém conhece.

Seu nome?

FOR — File-Owning Region.


O erro que todo iniciante comete

Quando aprendemos COBOL, imaginamos algo parecido com isto.

Programa COBOL

↓

EXEC CICS READ

↓

VSAM

↓

Resposta

Parece lógico.

Parece simples.

Parece direto.

Mas em grandes bancos isso raramente acontece.

Na verdade...

o programa quase nunca conversa diretamente com o arquivo.

Quem faz isso é outra região.

Uma espécie de bibliotecário extremamente disciplinado.


Imagine a maior biblioteca do planeta

Imagine uma biblioteca com cem milhões de livros.

Milhares de pessoas entram todos os minutos.

Cada uma quer pegar um livro.

Algumas querem devolvê-lo.

Outras querem alterá-lo.

Outras querem emprestá-lo.

Agora imagine se cada visitante pudesse entrar no depósito principal.

Em poucos minutos haveria caos.

Livros desaparecidos.

Livros duplicados.

Livros rasgados.

Livros no lugar errado.

Agora troque livros por registros bancários.

Você acaba de entender por que o FOR existe.


Afinal, o que é um FOR?

FOR significa

File-Owning Region

É uma região CICS especializada exclusivamente em possuir arquivos.

Ela não executa regras de negócio.

Não calcula juros.

Não processa PIX.

Não atualiza limites.

Ela apenas responde:

"Quer acessar este arquivo? Fale comigo."


Ownership não significa posse...

Significa responsabilidade.

O FOR é responsável por:

✔ abrir arquivos

✔ fechar arquivos

✔ controlar disponibilidade

✔ administrar concorrência

✔ garantir integridade

✔ responder requisições

✔ proteger registros

Pense nele como o zelador-chefe da biblioteca.


O CICSPlex parece uma cidade

Imagine uma cidade.

Na entrada existe um enorme prédio.

Ali trabalham os recepcionistas.

Esse prédio é o TOR.

TOR

↓

Recebe usuários

Depois existe o prédio administrativo.

Ali ficam os departamentos.

São os AORs.

AOR

↓

Executam aplicações

Mas existe outro prédio.

Quase escondido.

Sem visitantes.

Sem filas.

Sem atendimento ao público.

Um enorme arquivo central.

Ali trabalham apenas especialistas.

Esse prédio é o FOR.

FOR

↓

Arquivos

O fluxo verdadeiro

Usuário

↓

TOR

↓

AOR

↓

FOR

↓

VSAM

↓

FOR

↓

AOR

↓

TOR

↓

Usuário

Observe.

O arquivo nunca fala diretamente com o programa.

Sempre existe um intermediário.


O grande segredo: Function Shipping

Aqui aparece um termo muito cobrado em entrevistas.

Function Shipping.

Muitos iniciantes imaginam que o programa COBOL viaja para outra região.

Não.

Quem viaja é apenas o pedido.

Imagine um restaurante.

Você não leva a cozinha até sua mesa.

Você leva apenas o pedido.

O garçom entrega.

A cozinha prepara.

O prato volta.

No CICS acontece exatamente isso.

READ CUSTOMER

↓

FOR

↓

VSAM

↓

Registro

Nada mais.

Nada menos.


Um READ nunca foi apenas um READ

Veja um simples comando.

EXEC CICS
READ FILE('CLIENTE')
RIDFLD(CHAVE)
INTO(REGISTRO)
END-EXEC

Para o programador...

acabou.

Para o CICS...

a aventura apenas começou.

Primeiro ele verifica onde mora aquele arquivo.

Depois identifica seu proprietário.

Depois cria uma requisição.

Depois envia para outra região.

Depois espera resposta.

Depois recebe.

Depois devolve ao programa.

Tudo isso em milissegundos.


Easter Egg nº 1

Existe um velho ditado entre administradores CICS.

"Se um READ demora, culpe primeiro o caminho... não o COBOL."

Muitas vezes o programa está perfeito.

O problema pode estar:

  • no FOR

  • no VSAM

  • na rede entre regiões

  • no lock

  • no disco

  • na contenção

O COBOL frequentemente é inocente.


O banco das três agências

Imagine um banco.

Existem três grandes departamentos.

Agência Digital

Consulta saldo

PIX

Transferências

Cadastro

Atualização de clientes

Todos precisam acessar:

CUSTOMER

Sem FOR...

Cada AOR teria seu próprio acesso.

Resultado?

Mais administração.

Mais risco.

Mais configurações.

Mais problemas.


Com FOR

Tudo muda.

AOR 1

      \

AOR 2 -----> FOR -----> CUSTOMER

      /

AOR 3

Existe apenas um proprietário.

E isso simplifica toda a infraestrutura.


O guardião dos cofres

Imagine o cofre de um banco.

Você não entrega uma chave para cada funcionário.

Existe um responsável.

No CICS é igual.

O FOR guarda as chaves dos arquivos.


O mistério dos Locks

Agora imagine.

Saldo:

R$ 2.000,00

No mesmo segundo...

Um ATM faz saque.

Outro ATM faz depósito.

Outro aplicativo faz PIX.

Quem ganha?

Quem perde?

Sem controle...

o saldo poderia terminar errado.

Com FOR...

READ UPDATE

↓

LOCK

↓

Atualiza

↓

UNLOCK

A ordem é preservada.


Curiosidade

Em ambientes gigantes, dois usuários podem tentar alterar exatamente o mesmo registro no mesmo milissegundo.

É por isso que mecanismos de bloqueio existem.

Sem eles...

o caos seria inevitável.


Easter Egg nº 2

Procure em livros antigos de CICS.

Você encontrará a expressão:

File Ownership

Muito antes da computação distribuída virar moda, o CICS já separava responsabilidades.

Hoje chamamos isso de arquitetura distribuída.

Na década de 1980 isso já existia no Mainframe.


FOR não significa lentidão

Alguns iniciantes pensam:

"Mais uma região? Então fica mais lento."

Nem sempre.

Pense numa rodovia.

Você pode ter uma estrada direta cheia de congestionamentos.

Ou uma estrada um pouco maior, porém organizada.

O tempo final costuma ser menor.

O FOR organiza o trânsito dos dados.


VSAM: o tesouro escondido

A maioria dos FOR administra arquivos VSAM.

Especialmente:

  • KSDS

  • ESDS

  • RRDS

Cada um resolve um tipo diferente de problema.

Um excelente programador COBOL conhece todos eles.


Easter Egg nº 3

Muitos bancos ainda armazenam alguns dos dados mais importantes do país em VSAM.

Quando alguém diz que "o legado morreu", provavelmente acabou de comprar um café usando um cartão cuja autorização passou por um VSAM.


O papel do TOR

O TOR não conhece negócios.

Ele conhece terminais.

Recebe conexões.

Distribui trabalho.

Pense nele como o porteiro de um grande edifício.


O papel do AOR

O AOR pensa.

Calcula.

Executa.

Decide.

Ali vivem os programas COBOL.


O papel do FOR

O FOR protege.

Administra.

Entrega.

Organiza.

Ele é o arquivista.


Analogia completa

Imagine um hospital.

Paciente

↓

Recepção

↓

Médico

↓

Arquivo Médico

↓

Prontuário

Recepção

TOR

Médico

AOR

Arquivo

FOR

Prontuário

VSAM


O iniciante costuma perguntar...

"Por que não colocar tudo dentro do AOR?"

Boa pergunta.

Resposta:

Porque sistemas gigantes precisam crescer.

Imagine cinquenta AORs.

Todos precisando do mesmo cadastro.

Duplicar arquivos?

Duplicar administração?

Duplicar manutenção?

Não faz sentido.


Escalabilidade

Um banco cresce.

Novas aplicações aparecem.

Novos AORs são criados.

Nada muda no FOR.

Todos continuam usando os mesmos arquivos.

Essa separação torna o crescimento muito mais simples.


Alta disponibilidade

Aqui surge outra pergunta interessante.

"E se o FOR parar?"

Excelente pergunta.

Em ambientes corporativos existem estratégias de redundância, recuperação e failover para minimizar indisponibilidades. Dependendo da arquitetura, podem existir múltiplas regiões e mecanismos que permitem restaurar rapidamente o acesso aos arquivos.

Porque perder o FOR significa perder acesso aos arquivos que ele administra.


Como um programador COBOL deve pensar?

Não pense apenas:

EXEC CICS READ

Pense:

"Minha requisição viajará."

Pergunte:

Onde está o arquivo?

Quem é o owner?

Existe FOR?

Existe lock?

Existe contenção?

Esse raciocínio diferencia um programador júnior de um profissional experiente.


Dicas para entrevistas

Se perguntarem:

O que é um FOR?

Responda:

"É uma região CICS responsável por possuir e administrar arquivos compartilhados, permitindo que múltiplos AORs acessem os mesmos recursos por meio de Function Shipping, preservando integridade, escalabilidade e centralização administrativa."

Se perguntarem:

Quem executa o COBOL?

Resposta:

AOR.

Quem recebe o usuário?

TOR.

Quem administra arquivos?

FOR.

Essa tríade aparece com frequência em entrevistas para IBM Z.


Curiosidades que poucos conhecem

  • O FOR reduz a necessidade de múltiplas definições de arquivos em diferentes regiões.

  • Em muitos ambientes, ele trabalha em conjunto com recursos como VSAM RLS para ampliar o compartilhamento seguro dos dados.

  • Grandes instituições financeiras utilizam arquiteturas desse tipo há décadas para suportar milhões de transações diárias.

  • Um simples comando EXEC CICS READ pode envolver diversas camadas de comunicação invisíveis ao programador.


O verdadeiro mistério

O usuário acredita que conversou diretamente com um arquivo.

O programador acredita que o COBOL fez todo o trabalho.

O gerente acredita que tudo aconteceu em uma única máquina.

Mas, nos bastidores, uma coreografia perfeita acontece entre TOR, AOR, FOR, VSAM e o CICS.

É como uma investigação policial em que o detetive resolve o caso, mas nunca percebe que um discreto arquivista encontrou a prova decisiva escondida em uma gaveta esquecida.


Bellacosa Files – Caso Encerrado

Imagine Sherlock Holmes entrando em um CPD.

Watson observa um terminal 3270 e comenta:

— Holmes, o programa encontrou o registro em menos de um segundo. Impressionante.

Holmes sorri, acende seu cachimbo e responde:

— Elementar, meu caro Watson. O programa não encontrou absolutamente nada.

— Como assim?

— Quem encontrou foi o verdadeiro guardião dos arquivos. O programa apenas fez a pergunta certa.

Watson olha para o enorme datacenter, onde dezenas de luzes piscam em silêncio.

Naquele instante, ele percebe que existe um herói invisível trabalhando muito além das telas verdes.

Um herói que nunca aparece nas apresentações comerciais.

Nunca recebe aplausos.

Nunca é visto pelos usuários.

Mas que mantém bancos, companhias aéreas, seguradoras e governos funcionando todos os dias.

Seu nome é FOR — File-Owning Region.

E enquanto houver um VSAM guardando informações valiosas, esse silencioso arquivista continuará protegendo o patrimônio digital do mundo, provando que, no universo IBM Z, os maiores mistérios não estão nos programas COBOL… estão na extraordinária arquitetura que faz tudo funcionar com precisão há décadas.

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