☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

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





sábado, 6 de dezembro de 2025

💥 SEU COBOL NÃO RODA — ELE ORQUESTRA O MUNDO: CICS Structure & Intercommunication no IBM z17 para Quem Vive de Produção

 

Bellacosa Mainframe e o poder do CICS no Mundo Mainframe


💥 SEU COBOL NÃO RODA — ELE ORQUESTRA O MUNDO: CICS Structure & Intercommunication no IBM z17 para Quem Vive de Produção

Se você é dev COBOL sênior, já sabe: CICS não é “mais um runtime”.
Ele é o cérebro transacional que sustenta bancos, companhias aéreas, telecoms — e agora, APIs modernas no IBM z17.

Mas aqui vai a provocação:

👉 Se você não entende profundamente a estrutura e a intercomunicação do CICS, você está programando “cego” em produção.

Vamos desmontar isso com história, prática, arquitetura real, “easter eggs” e insights que só aparecem quando você vive CICS de verdade. 🚀


🧠 1. CICS NÃO É UM SISTEMA — É UM ECOSSISTEMA

📜 Origem (rapidinho, mas essencial)

O CICS nasceu nos anos 60/70 para resolver um problema brutal:

👉 processar milhares de transações simultâneas com consistência absoluta

Enquanto o mundo fazia batch…

👉 o CICS já fazia online transacional em escala global.


🧩 Estrutura interna (o que realmente roda seu COBOL)

Dentro de uma CICS Region:

  • Kernel (DFHKERN) → coordena tudo
  • Dispatcher → agenda tasks
  • Storage Manager → gerencia memória
  • Program Control → carrega e executa programas
  • File Control → acessa VSAM/DB2
  • Task Control → gerencia execução

💡 Easter egg:

O prefixo DFH (DFHxxxx) vem de Data Facility Hypervisor — legado histórico da IBM.


💼 2. CICS APPLICATION — SEU COBOL NÃO ESTÁ SOZINHO

Uma aplicação CICS:

👉 é um conjunto de programas cooperando.

🏦 Exemplo real (transferência bancária)

VALIDA-CONTA
→ CHECK-SALDO
→ CALC-TAXA
→ UPDATE-DB
→ LOG-AUDIT
→ RETORNO-USUARIO

Você escreve um programa…

👉 mas o CICS orquestra todo o fluxo transacional.


⚙️ O segredo que muita gente ignora

Você não controla:

  • Threads
  • Memória direta
  • I/O direto

👉 O CICS controla tudo.

E isso é o que garante:

✔ Integridade
✔ Escala
✔ Segurança
✔ Performance


🏢 3. CICS REGION — ONDE A MÁGICA ACONTECE

Uma CICS Region = um address space no z/OS.

Ela é iniciada como:

S CICSPROD

Ou via JCL com DFHSIP.


🧠 Recursos dentro da region

  • Programas
  • Transações
  • BMS maps
  • Arquivos VSAM
  • TSQ / TDQ
  • Journals
  • Usuários

👉 Tudo controlado como uma única entidade.


💡 Curiosidade (produção real)

Em bancos:

  • Uma única região pode processar milhares de TPS
  • Um ambiente pode ter dezenas de regiões

🌐 4. CICSPLEX — QUANDO UM CICS NÃO É SUFICIENTE

👉 CICSPlex = várias regiões funcionando como uma só

Gerenciado por:

👉 CICSPlex System Manager (SM)


⚖️ O que ele resolve

  • Balanceamento automático
  • Failover
  • Administração centralizada
  • Visão global

🧠 Insight de arquiteto

👉 Isso é o “Kubernetes” do mainframe… décadas antes do Kubernetes existir.


🔗 5. INTERCOMMUNICATION — O VERDADEIRO PODER

Agora vem o ponto onde muita gente “perde o jogo”:

👉 como as regiões conversam


🟢 MRO — O CAMINHO MAIS RÁPIDO DO UNIVERSO CICS

👉 Comunicação dentro da mesma LPAR ou Sysplex

🔧 Usa:

➡️ IRC — Interregion Communication


⚡ Por que isso importa

  • Sem TCP/IP
  • Sem SNA
  • Sem rede
  • Latência mínima

👉 É praticamente memória → memória


🏗️ Exemplo clássico

USER → TOR → AOR → FOR

Tudo via MRO + IRC.


🧪 Easter egg de produção

👉 Você pode rodar uma AOR de teste usando dados reais

Sem impactar produção.


🔵 ISC — QUANDO O MUNDO FICA MAIOR

👉 Comunicação entre hosts diferentes

Usa:

  • SNA
  • VTAM
  • APPC (LU 6.2)

🏦 Exemplo real

  • CICS (canal digital)
    → ISC
    → IMS (core bancário)

💡 Curiosidade

ISC ainda roda em ambientes críticos…

👉 mesmo em 2026.


🟣 IPIC — A EVOLUÇÃO

👉 ISC moderno via TCP/IP

Benefícios:

  • Configuração simples
  • TLS nativo
  • Integração com cloud
  • Performance alta

👉 Hoje é o padrão recomendado.


🌉 6. CICS TRANSACTION GATEWAY — O PORTAL PARA O MUNDO

👉 O TG conecta o CICS com:

  • Java / Java EE
  • .NET
  • APIs REST
  • Microservices

🌐 Fluxo moderno

App → API → Java → CICS TG → CICS → DB2

👉 Seu COBOL está rodando por trás de apps mobile.


🚀 7. IBM z17 — O TURBO NO CICS

O CICS continua o mesmo conceito…

Mas o z17 traz:

  • ⚡ Mais throughput
  • 🔐 Criptografia massiva
  • 🌐 Integração cloud-native
  • 🧠 Observabilidade avançada

👉 Resultado: o mesmo CICS… em outro nível


💎 8. RESUMO DE GUERRA (GUARDE ISSO)

👉 CICS Application = negócio
👉 CICS Region = runtime
👉 CICSPlex = escala
👉 MRO = comunicação interna (IRC)
👉 ISC = comunicação entre hosts (SNA)
👉 IPIC = comunicação moderna (TCP/IP)
👉 CTG = integração com o mundo externo


🧠 FRASE FINAL (NÍVEL SÊNIOR)

👉 CICS não executa programas — ele coordena um sistema distribuído transacional de altíssima performance que atravessa regiões, sistemas e até o mundo digital moderno.


sexta-feira, 5 de dezembro de 2025

💥 SEU CICS NÃO ESCALA — ELE DOMINA ECOSSISTEMAS: O GUIA DEFINITIVO DE CICS no z16/z17 PARA ARQUITETOS QUE PENSAM GRANDE

 

Bellacosa Mainframe e o poder do CICS dominando ecosistemas no Mundo Mainframe

💥 SEU CICS NÃO ESCALA — ELE DOMINA ECOSSISTEMAS: O GUIA DEFINITIVO DE CICS no z16/z17 PARA ARQUITETOS QUE PENSAM GRANDE

Se você ainda enxerga CICS como “onde roda COBOL”, você está vendo só a superfície.

👉 No IBM Z moderno (z16/z17), o CICS virou uma plataforma transacional distribuída, integrada e híbrida, capaz de orquestrar desde VSAM até APIs REST consumidas por milhões de usuários.

Este guia é direto para quem já vive produção — e quer pensar como arquiteto. 🚀


🧠 1. CICS: DE MONITOR TRANSACIONAL A PLATAFORMA DIGITAL

📜 Origem (o DNA que ainda manda)

CICS nasceu para resolver:

👉 processamento massivo de transações com consistência absoluta

Isso continua igual.

O que mudou:

👉 o alcance.

Hoje o CICS:

  • Atende mobile
  • Expõe APIs REST
  • Integra microservices
  • Participa de arquiteturas híbridas

💡 Easter egg histórico

O prefixo DFH (mensagens DFHxxxx) vem de:

👉 Data Facility Hypervisor

Décadas depois… ainda está lá. 😄


🏗️ 2. ESTRUTURA — COMO UM ARQUITETO ENXERGA O CICS

🧩 O modelo mental correto

Um arquiteto não vê “programas COBOL”.

Ele vê:

🔹 Application Layer

  • Programas (COBOL, PL/I, Java)
  • Fluxos de negócio

🔹 Transaction Layer

  • Tasks
  • Syncpoints
  • Controle ACID

🔹 Resource Layer

  • DB2
  • VSAM
  • TSQ/TDQ
  • MQ

🔹 Infrastructure Layer

  • Regions
  • CICSPlex
  • Sysplex

🧠 Insight importante

👉 CICS é um application server transacional altamente otimizado.


🏢 3. REGIONS — O DESIGN DISTRIBUÍDO DENTRO DO Z

🔥 Arquitetura clássica (e ainda dominante)

TOR → AOR → FOR

🖥️ TOR

  • Entrada (3270, web, APIs)
  • Roteamento

⚙️ AOR

  • Processamento de negócio
  • Escala horizontal

💾 FOR

  • Dados
  • Locks e integridade

💡 Curiosidade real

Em bancos grandes:

👉 dezenas de AORs
👉 múltiplos TORs
👉 FORs centralizados


🧠 Insight de arquiteto

👉 Isso é microservices antes do microservices existir.


🌐 4. CICSPLEX — O “CLUSTER” DO MAINFRAME

🧩 Componentes

  • CMAS → cérebro
  • MAS → regiões
  • WLM → balanceamento

⚖️ O que isso resolve

  • Escala massiva
  • Alta disponibilidade
  • Failover automático
  • Administração centralizada

💡 Easter egg moderno

👉 CICSPlex SM = “Kubernetes do mainframe” (sem hype, com SLA real)


🔗 5. INTERCOMMUNICATION — ONDE A ARQUITETURA GANHA VIDA

Aqui está o ponto mais crítico para arquitetos.


🟢 MRO + IRC — O FAST PATH

👉 Comunicação interna (mesma LPAR/Sysplex)

🔧 Usa:

➡️ IRC (Interregion Communication)

⚡ Resultado:

  • Sem rede
  • Latência mínima
  • Throughput absurdo

🧠 Insight

👉 Esse é o motivo do CICS escalar tanto.


🔵 ISC — O LEGADO QUE AINDA RESPIRA

👉 Comunicação entre hosts via SNA.

Ainda usado em:

  • Core banking
  • Integrações antigas
  • Sistemas críticos

🟣 IPIC — O PRESENTE

👉 Comunicação via TCP/IP

  • Simples
  • Segura (TLS)
  • Cloud-ready

👉 Padrão atual


🌉 6. CICS TG — O PORTAL PARA O DIGITAL

🌐 O que ele faz

Conecta:

  • Java / Jakarta EE
  • .NET
  • APIs REST
  • Microservices

🚀 Fluxo moderno real

Mobile → API → Java → CICS TG → CICS → DB2

👉 Seu COBOL vira backend de apps globais.


⚡ 7. z16 vs z17 — O QUE MUDA PARA ARQUITETOS

🚀 Performance

  • Mais throughput
  • Melhor paralelismo

🔐 Segurança

  • Criptografia pervasive
  • TLS acelerado

🌐 Integração

  • Melhor suporte a APIs
  • Hybrid cloud real

🧠 Observabilidade

  • SMF avançado
  • Integração com AIOps

💡 Insight crítico

👉 O CICS não mudou — o contexto dele mudou completamente.


🛠️ 8. PASSO A PASSO — COMO PENSAR UMA ARQUITETURA CICS MODERNA

1️⃣ Defina entrada

  • 3270?
  • API?
  • Mobile?

2️⃣ Separe regiões

  • TOR (entrada)
  • AOR (processamento)
  • FOR (dados)

3️⃣ Defina comunicação

  • MRO (interno)
  • IPIC (externo)

4️⃣ Planeje escala

  • CICSPlex + WLM

5️⃣ Integre com digital

  • CICS TG
  • APIs REST

6️⃣ Planeje HA

  • Sysplex
  • Failover

💎 9. RESUMO DE ARQUITETO

👉 CICS não é legado
👉 Não é monolito
👉 Não é “COBOL runtime”

👉 É uma plataforma transacional distribuída, resiliente e integrada ao mundo moderno


🧠 FRASE FINAL (GUARDE ISSO)

👉 No z16/z17, o CICS não executa aplicações — ele sustenta ecossistemas digitais inteiros com consistência, escala e zero margem para erro.


terça-feira, 7 de outubro de 2025

🔥☕ O MAINFRAME JÁ ERA CLOUD ANTES DA CLOUD EXISTIR 💾🏛️🌐

 

Bellacosa Mainframe apresenta o CICS Structure Intercomunication

🔥☕ O MAINFRAME JÁ ERA CLOUD ANTES DA CLOUD EXISTIR — A VERDADE QUE TODO SYSprog JUNIOR DESCOBRE QUANDO ENTENDE CICS STRUCTURE & INTERCOMMUNICATION 💾🏛️🌐



Durante anos, muita gente ouviu frases como:

  • “Mainframe é centralizado”

  • “CICS é legado”

  • “IBM Z é tecnologia antiga”

  • “Cloud substituiu o mainframe”

E então o padawan começa a estudar:

🔥 CICS Structure and Intercommunication.

Nesse momento acontece algo curioso.

Ele percebe:

💣 o IBM CICS já fazia computação distribuída enterprise MUITO antes da internet moderna, dos microsserviços, do Kubernetes e da cloud híbrida virarem moda.

E isso muda completamente sua visão sobre o mundo IBM Z.


☕ O ERRO CLÁSSICO DE QUEM ESTÁ COMEÇANDO

O iniciante normalmente imagina o CICS assim:

Usuário → COBOL → VSAM

Algo simples.
Linear.
Monolítico.

Mas o ambiente enterprise real é mais próximo disso:

Usuário
   ↓
TOR
   ↓
MRO / IRC
   ↓
AORs distribuídos
   ↓
Db2 / MQ / VSAM
   ↓
CICSPlex
   ↓
Sysplex
   ↓
Recovery / Routing / Balancing

E nesse instante o sysprog junior percebe:

🔥 o CICS é um ecossistema distribuído monstruosamente sofisticado.


🏛️ O CICS NÃO É “UM PROGRAMA”

Esse é o primeiro choque.

O CICS moderno:

💣 não é uma única região.

Ele pode possuir:

  • dezenas de regiões

  • múltiplos hosts

  • múltiplas LPARs

  • workloads distribuídos

  • failover automático

  • roteamento dinâmico

Tudo funcionando:

⚡ simultaneamente.


☕ O QUE É UMA REGIÃO CICS?

Uma região CICS:

🔥 é um address space do z/OS.

Ou seja:

  • possui memória própria

  • tasks próprias

  • recursos próprios

  • controle próprio

E roda:

💾 como Started Task ou Batch Job.


☕ O SYSprog JUNIOR DESCOBRE UMA VERDADE IMPORTANTE

O CICS:

❌ não é o sistema operacional.

Ele roda:

🏛️ SOBRE o z/OS.

Assim como:

  • Db2

  • MQ

  • JES2

  • VTAM

  • TCP/IP


💾 O CICS É “APENAS” MAIS UM WORKLOAD DO z/OS

Só que esse “workload”:

💣 movimenta o planeta financeiro.


🔥 TOR, AOR E FOR — A SEPARAÇÃO QUE MUDOU TUDO

Aqui começa a engenharia enterprise de verdade.


☕ TOR — TERMINAL OWNING REGION

Responsável por:

  • receber conexões

  • controlar sessões

  • entrada de usuários

  • roteamento

O TOR funciona como:

🚦 controlador de tráfego.


☕ AOR — APPLICATION OWNING REGION

Aqui mora:

  • COBOL

  • regras de negócio

  • Db2

  • MQ

  • VSAM

O AOR:

⚡ executa o trabalho pesado.


☕ FOR — FILE OWNING REGION

Especializada em:

  • VSAM

  • locking

  • controle de arquivos

  • integridade


💣 ISSO É GENIAL

Porque:

  • workload pode ser distribuído

  • funções podem ser separadas

  • gargalos podem ser evitados

  • escalabilidade aumenta absurdamente


🌐 MRO — O “SERVICE MESH INVISÍVEL” DO CICS

Quando o padawan aprende MRO:

🔥 sua mente explode.


☕ O QUE É MRO?

🌐 Multiregion Operation

Permite:

  • comunicação entre regiões CICS

  • dentro do mesmo z/OS

  • ou dentro do mesmo Sysplex


💾 O MAIS IMPRESSIONANTE

O MRO usa:

⚡ IRC — Interregion Communication.


☕ O IRC É A JOIA ESCONDIDA DO CICS

Porque:

  • comunicação é interna

  • não precisa TCP/IP

  • não precisa SNA

  • não precisa VTAM


💣 RESULTADO?

✅ baixa latência

✅ throughput monstruoso

✅ comunicação ultra rápida

✅ escalabilidade massiva


☕ O MRO É BASICAMENTE:

🔥 um “service bus interno” criado décadas antes da cloud moderna.


🌎 ISC — QUANDO O CICS APRENDEU A FALAR COM O MUNDO

Depois vem:

🌐 ISC — Intersystem Communication.


☕ O ISC CONECTA:

  • hosts diferentes

  • sistemas remotos

  • datacenters

  • ambientes distribuídos

Usando:

🔥 SNA / APPC / LU6.2


💾 ISSO ERA A “INTERNET IBM”

Muito antes:

  • APIs REST

  • HTTP moderno

  • cloud hybrid


☕ O ISC PERMITIU:

✅ ATMs nacionais

✅ agências distribuídas

✅ bancos globais

✅ processamento remoto

✅ integração CICS ↔ IMS


💣 COMPUTAÇÃO DISTRIBUÍDA REAL

Nos anos 80 e 90.
Quando muita gente ainda nem entendia redes corporativas direito.


🌐 IPIC — O CICS ENTRA NA ERA TCP/IP

O mundo mudou.
O TCP/IP venceu.
E o CICS evoluiu.

Nasce:

🔥 IPIC — IP Interconnectivity.


☕ AGORA O CICS CONVERSA VIA:

✅ TCP/IP

✅ APIs

✅ Linux

✅ OpenShift

✅ cloud

✅ microsserviços


💾 O CICS NÃO MORREU

Ele:

⚡ se modernizou.


🌉 CICS TRANSACTION GATEWAY — A PONTE ENTRE O PASSADO E O FUTURO

Agora entra:

🔥 CTG — CICS Transaction Gateway.


☕ O CTG É O “TRADUTOR”

Entre:

  • Java

  • .NET

  • aplicações web

  • APIs REST

e:

💾 o mundo CICS/COBOL.


☕ FLUXO MODERNO REAL

App Mobile
   ↓
API REST
   ↓
Java Spring
   ↓
CTG
   ↓
CICS
   ↓
COBOL
   ↓
Db2

💣 O USUÁRIO NÃO FAZ IDEIA

Que:

  • um COBOL de décadas atrás

  • respondeu sua operação bancária em milissegundos.


🏛️ CICSPLEX — O “KUBERNETES” QUE EXISTIA ANTES DO KUBERNETES

Quando o ambiente cresce absurdamente:

  • dezenas de regiões

  • múltiplos hosts

  • milhões de transações

entra:

🌐 CICSPlex.


☕ O CICSPLEX TRANSFORMA:

Múltiplos CICS:

⚡ em um único ambiente lógico.


💾 O CPSM FAZ:

✅ workload balancing

✅ failover

✅ gerenciamento centralizado

✅ roteamento dinâmico

✅ monitoramento


💣 ISSO É ORQUESTRAÇÃO ENTERPRISE

Muito antes:

  • Kubernetes

  • OpenShift

  • cloud orchestration


☕ O SYSprog JUNIOR COMEÇA A ENTENDER

Que o IBM Z:

❌ nunca foi “parado no tempo”.

Na verdade:

🔥 ele estava anos à frente.


🌐 O CICS JÁ FAZIA:

✅ clusterização

✅ workload balancing

✅ comunicação distribuída

✅ middleware enterprise

✅ failover automático

✅ integração híbrida

✅ service orchestration

✅ APIs corporativas

Décadas antes:

  • da cloud moderna

  • dos microsserviços

  • do service mesh

  • do Kubernetes


💾 O GRANDE SEGREDO DO MAINFRAME

O mundo moderno reinventou conceitos que:

🏛️ o IBM Z já dominava há décadas.


☕ ENQUANTO MUITOS SISTEMAS MODERNOS:

  • quebram facilmente

  • perdem consistência

  • sofrem downtime

  • escalam mal

O CICS continua:

⚡ processando bilhões de transações silenciosamente.


💣 O PADAWAN FINALMENTE ENTENDE

O CICS:

❌ não é apenas EXEC CICS SEND MAP.

Ele é:

🌐 uma plataforma transacional distribuída de missão crítica.


🏛️ CONCLUSÃO BELLACOSA MAINFRAME™

Quando um sysprog junior realmente entende:

  • MRO

  • IRC

  • ISC

  • IPIC

  • CTG

  • CICSPlex

  • regiões CICS

ele percebe algo impressionante:

🔥 o mainframe nunca ficou para trás.

Na verdade:

💾 o restante da indústria passou décadas tentando reinventar conceitos que o IBM Z já utilizava silenciosamente desde muito antes da explosão da computação cloud moderna.

sexta-feira, 18 de maio de 2018

O Caso da Ponte Invisível : Quando Sherlock Holmes Descobriu que Existiam Estradas Secretas Entre Mainframes

 

Bellacosa Mainframe e o caso da ponte invisivel entre mainframes

☕ Um Café no Bellacosa Mainframe

O Caso da Ponte Invisível

Quando Sherlock Holmes Descobriu que Existiam Estradas Secretas Entre Mainframes

"Nem todas as conexões aparecem nos diagramas. Algumas apenas deixam rastros... e apenas um bom programador COBOL consegue percebê-los."


Era uma madrugada fria.

As luzes do CPD permaneciam acesas como estrelas artificiais iluminando um universo que poucas pessoas conheciam.

Os discos DASD giravam silenciosamente.

As impressoras de linha descansavam.

Os operadores observavam dezenas de consoles enquanto milhares de transações bancárias cruzavam o país.

Foi então que Sherlock Holmes colocou uma xícara de café sobre um terminal IBM 3270 e comentou:

Watson... existe algo estranho.

— "O quê?"

Um cliente acabou de consultar o saldo da conta. O programa está neste CICS... mas o saldo veio de outro mainframe localizado a centenas de quilômetros.

Watson arregalou os olhos.

— "Magia?"

Holmes sorriu.

Não... chama-se ISC.

E assim começava mais um dos casos do Bellacosa Mainframe.


O Mistério da Comunicação Invisível

Todo iniciante imagina que um programa COBOL conversa apenas com os arquivos existentes dentro do próprio computador.

Seria lógico pensar assim.

Mas o mundo corporativo nunca foi simples.

Imagine um grande banco.

Existe apenas um computador?

Claro que não.

Pode haver:

  • dezenas de IBM Z

  • centenas de regiões CICS

  • milhares de programas COBOL

  • milhões de clientes simultâneos

Então surge uma pergunta.

Como um programa que está rodando em São Paulo consegue consultar um cadastro existente em Brasília?

Ou um sistema instalado no Rio de Janeiro acessar uma conta localizada em Curitiba?

É aí que entra o protagonista desta investigação.

ISC — InterSystem Communication.


Primeiro precisamos entender o território

Antes de compreender o ISC precisamos conhecer seu "primo".

O famoso MRO.

Muitos iniciantes confundem os dois.

Isso acontece porque ambos fazem praticamente a mesma coisa.

Mas existe uma diferença gigantesca.

Imagine um condomínio.

Você mora na Torre A.

Seu amigo mora na Torre B.

Para visitá-lo basta atravessar o jardim.

Essa caminhada representa o MRO.

Agora imagine visitar um amigo que mora em outro estado.

Você precisará viajar de avião.

Essa viagem representa o ISC.

A lógica continua sendo comunicação.

O caminho é completamente diferente.


MRO: o corredor interno

No artigo anterior vimos que uma arquitetura típica pode ser:

Usuário

↓

TOR

↓

AOR

↓

FOR

↓

VSAM

Todas essas regiões pertencem ao mesmo ambiente z/OS.

A comunicação ocorre por MRO.

É praticamente um corredor interno.

Tudo acontece "dentro da mesma casa".


ISC: a rodovia interestadual

Agora imagine isto.

Datacenter São Paulo

↓

CICS A

=====================

Rede

=====================

↓

CICS B

↓

Datacenter Brasília

Agora já não existe um simples corredor.

Existe uma estrada.

Essa estrada chama-se ISC.

Ela permite que sistemas completamente independentes conversem como se fossem vizinhos.


O verdadeiro significado de InterSystem Communication

Muita gente acredita que ISC apenas troca mensagens.

Na verdade ele faz muito mais.

Ele permite que um CICS utilize recursos existentes em outro CICS.

Esses recursos podem ser:

• programas COBOL

• transações

• arquivos VSAM

• tabelas DB2

• filas

• serviços

• APIs

Na prática...

Um sistema pode "emprestar" recursos para outro.

É como uma enorme biblioteca.

Você não precisa comprar todos os livros.

Basta pedir emprestado.


Um banco de verdade

Vamos imaginar o Banco Bellacosa.

Ele possui três grandes centros.

São Paulo.

Rio de Janeiro.

Brasília.

Cada um executa uma função.

São Paulo:

  • Internet Banking

  • PIX

  • Aplicativo

Rio:

  • Cartões

Brasília:

  • Cadastro

  • Contas

  • Crédito

Quando um cliente consulta seu saldo:

Aplicativo

↓

São Paulo

↓

ISC

↓

Brasília

↓

DB2

↓

Resposta

↓

Cliente

Perceba algo curioso.

O usuário acredita que tudo aconteceu no mesmo computador.

Mas não.

A transação atravessou uma rede inteira.


O programador nunca percebe

Este talvez seja o aspecto mais fascinante.

Você programa normalmente.

Escreve COBOL.

Utiliza EXEC CICS.

Recebe os dados.

Para você parece local.

Mas o CICS trabalha nos bastidores.

Ele localiza o sistema remoto.

Abre comunicação.

Transfere informações.

Recebe a resposta.

Entrega os dados ao programa.

Tudo isso em poucos milissegundos.

É quase mágica.


A diferença que cai em entrevistas

Esta pergunta aparece há décadas.

"Qual a diferença entre MRO e ISC?"

A resposta curta:

MRO comunica regiões do mesmo z/OS.

ISC comunica sistemas diferentes.

Mas existe uma resposta muito melhor.

MRO resolve o problema da distribuição interna.

ISC resolve o problema da distribuição geográfica.

Essa pequena frase costuma impressionar entrevistadores.


Um exemplo ainda maior

Imagine uma companhia aérea.

O sistema de venda de passagens está em um datacenter.

O programa de milhagem está em outro.

O controle de bagagens em outro.

O sistema meteorológico em outro.

Mesmo assim o passageiro compra uma passagem em menos de cinco segundos.

Como?

Graças a tecnologias como ISC.

Cada sistema executa apenas sua especialidade.


A evolução da tecnologia

Nos anos 1970 era comum existir apenas um grande CICS.

Depois vieram dezenas.

Depois centenas.

Hoje encontramos arquiteturas gigantescas.

Cliente

↓

API

↓

z/OS Connect

↓

CICS

↓

ISC

↓

Outro CICS

↓

DB2

Observe algo interessante.

Mesmo quando você utiliza REST.

Mesmo quando utiliza APIs.

Mesmo quando utiliza aplicações Java.

Em muitos casos...

Lá no fundo...

Existe um ISC funcionando silenciosamente.


O que realmente viaja pela rede?

Essa é uma dúvida comum.

O programa COBOL inteiro atravessa a rede?

Não.

Normalmente trafegam:

  • parâmetros

  • comandos

  • dados

  • respostas

É semelhante a fazer uma ligação telefônica.

Você não envia sua casa inteira.

Apenas sua voz.


Como era antigamente?

Nos primeiros anos do CICS predominava o SNA.

Depois vieram APPC e LU6.2.

Hoje o mais comum é encontrar IPIC utilizando TCP/IP.

Isso mostra como o mainframe evolui.

Ele preserva compatibilidade.

Mas também acompanha novas tecnologias.

É uma das razões pelas quais sistemas escritos há quarenta anos continuam funcionando.


Um segredo que pouca gente conhece

Você sabia que existem bancos onde uma única operação pode atravessar cinco ou seis CICS diferentes?

É verdade.

Imagine:

Cliente

TOR

AOR

ISC

Outro AOR

MQ

Outro sistema

DB2

Resposta

Tudo isso ocorre antes de o cliente terminar de piscar.


O preço da distância

Existe uma regra simples.

Quanto maior a distância.

Maior a latência.

Isso significa que um ISC entre dois CICS no mesmo prédio costuma ser mais rápido do que entre cidades diferentes.

Mesmo assim estamos falando de tempos extremamente baixos.

Por isso grandes bancos conseguem atender milhões de clientes simultaneamente.


Segurança: ninguém entra sem identificação

Imagine que qualquer sistema pudesse conversar livremente com outro.

Seria um desastre.

Por isso entram em cena diversos mecanismos de proteção.

Entre eles:

  • RACF

  • autenticação

  • autorização

  • criptografia

  • auditoria

  • SMF

Nada acontece sem registro.

No universo IBM Z praticamente tudo deixa rastros.

É por isso que investigadores de performance conseguem reconstruir uma transação inteira.


Onde o ISC aparece sem você perceber?

Você provavelmente já utilizou ISC.

Ao:

  • sacar dinheiro

  • pagar boleto

  • fazer PIX

  • comprar passagem aérea

  • consultar plano de saúde

  • emitir nota fiscal

  • realizar declaração de imposto

Em todos esses ambientes existe uma enorme chance de existir comunicação entre diferentes sistemas CICS.


Curiosidades do Mundo Mainframe 🕵️

Curiosidade 1

O nome InterSystem Communication surgiu porque, originalmente, o objetivo era conectar sistemas completamente independentes, não apenas regiões CICS.


Curiosidade 2

Muitos ambientes antigos ainda possuem conexões SNA funcionando perfeitamente após décadas de operação.


Curiosidade 3

Existem empresas que mantêm ambientes de produção e contingência em estados diferentes utilizando ISC como parte da estratégia operacional.


Curiosidade 4

É perfeitamente possível que uma transação utilize MRO e ISC na mesma execução.

Exemplo:

Cliente

↓

TOR

↓

MRO

↓

AOR

↓

ISC

↓

Outro Mainframe

↓

DB2

Dicas para quem está aprendendo COBOL

Não tente decorar siglas.

Entenda responsabilidades.

Pergunte sempre:

Quem recebe?

Quem executa?

Quem possui os arquivos?

Quem conversa com outro sistema?

Quando responder essas perguntas automaticamente, TOR, AOR, FOR, MRO e ISC passam a fazer sentido.


Passo a passo mental para entender uma arquitetura CICS

Sempre siga esta sequência:

Passo 1

Quem iniciou a transação?

Passo 2

Quem recebeu?

(TOR)

Passo 3

Quem executou?

(AOR)

Passo 4

Quem possui os dados?

(FOR ou DB2)

Passo 5

Os dados estão neste sistema?

Se sim:

MRO.

Se não:

ISC.

Essa pequena metodologia ajuda muito em entrevistas técnicas e na leitura de diagramas corporativos.


O Easter Egg ☕

Desde o primeiro artigo desta série existe um personagem escondido.

Sherlock Holmes.

Mas existe outro.

Pouca gente percebeu.

Sempre que aparece uma xícara de café sobre um terminal 3270, ela simboliza algo muito maior.

O café representa o programador.

O terminal representa a tecnologia.

Enquanto existir alguém curioso o suficiente para sentar diante daquele terminal, fazer perguntas e investigar como as coisas realmente funcionam, o mainframe continuará evoluindo.

O verdadeiro combustível do IBM Z nunca foram apenas MIPS, processadores ou discos. Foram pessoas curiosas.


O Grande Detetive Chega à Conclusão

Sherlock terminou o café.

Olhou novamente para o console.

Sorriu discretamente.

— "Watson... agora sabemos por que o cliente recebeu o saldo tão rapidamente."

— "Porque o banco possui computadores muito rápidos?"

Holmes respondeu:

— "Não apenas isso."

"Porque milhares de engenheiros passaram décadas construindo pontes invisíveis entre sistemas. O cliente jamais verá essas pontes. Mas sem elas o banco inteiro pararia."

Watson permaneceu em silêncio.

Na tela verde do 3270 apareceu apenas uma única mensagem:

TRANSACTION COMPLETED

Holmes levantou-se.

Vestiu o sobretudo.

Apagou o cachimbo imaginário.

E desapareceu pelos corredores do CPD.

Naquela noite, ninguém percebeu que o maior mistério nunca foi descobrir o que era o ISC.

O verdadeiro mistério era entender como bilhões de transações conseguem atravessar fronteiras, datacenters e continentes em silêncio absoluto, mantendo a confiança de bancos, governos e empresas há mais de meio século.

Talvez seja justamente esse o maior segredo do universo IBM Mainframe: as tecnologias mais importantes raramente aparecem para o usuário final. Elas trabalham nas sombras, como bons detetives das antigas revistas noir dos anos 1950, resolvendo casos antes mesmo que alguém perceba que existia um problema.

E, quando você finalmente dominar TOR, AOR, FOR, MRO e ISC, descobrirá que não aprendeu apenas um conjunto de siglas. Aprendeu a enxergar a malha invisível que sustenta uma parte significativa da economia mundial, transação após transação, café após café.

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
GitHub LinkedIn
Inicializando conteúdo...