Translate

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





terça-feira, 21 de agosto de 2018

☕🔥 TCP/IP NO IBM MAINFRAME — A INTERNET MODERNA AINDA DEPENDE DOS COMANDOS QUE O z/OS DOMINA HÁ DÉCADAS

 

Bellacosa Mainframe e os comandos tcp/ip no mainframe

☕🔥 TCP/IP NO IBM MAINFRAME — A INTERNET MODERNA AINDA DEPENDE DOS COMANDOS QUE O z/OS DOMINA HÁ DÉCADAS

Existe uma ilusão muito comum no mundo da tecnologia:

“Mainframe é isolado da internet.”

Só que a realidade é exatamente o contrário.

O IBM Mainframe é um dos ambientes mais conectados do planeta.

Todos os dias o z/OS conversa com:

  • APIs REST

  • aplicações mobile

  • cloud

  • PIX

  • cartões

  • bolsas financeiras

  • sistemas globais

  • Open Banking

  • Kafka

  • Kubernetes

E tudo isso depende de uma coisa:

🔥 TCP/IP.


☕ O QUE MUITA GENTE NÃO SABE

O Mainframe foi um dos primeiros ambientes corporativos a operar redes gigantescas com:

  • altíssima disponibilidade

  • throughput absurdo

  • tolerância a falhas

  • segurança pesada

  • roteamento complexo

Enquanto muita infraestrutura moderna reinicia containers…

o z/OS continua processando transações críticas há décadas.


☕🔥 PING — O “ARE YOU ALIVE?” DA INFRAESTRUTURA

O famoso:

ping google.com

parece simples.

Mas ele representa algo fundamental:

🔥 conectividade básica.


☕ O QUE O PING REALMENTE FAZ?

Usa:

ICMP Echo Request

para verificar:

  • alcance

  • latência

  • disponibilidade


☕ No Mainframe isso também é essencial

Ambientes z/OS usam:

  • TCP/IP stack

  • VTAM

  • OSA adapters

  • Sysplex networking


☕ Problema clássico

Aplicação CICS não responde.

O operador imediatamente pensa:

É rede?
É DNS?
É rota?
É firewall?

☕ Bellacosa Mainframe Analysis™

Ping é o:

🔥 “DISPLAY STATUS” da internet.


☕🔥 TRACERT / TRACEROUTE — O GPS DOS PACOTES

Agora entramos numa ferramenta fantástica.


☕ Exemplo:

tracert ibm.com

☕ O que isso mostra?

Cada salto da rede:

HOST
 ↓
ROUTER
 ↓
BACKBONE
 ↓
DESTINO

☕ No Mainframe isso lembra fortemente:

  • análise VTAM

  • troubleshooting SNA

  • rotas TCP/IP

  • OSA networking


☕ Grandes bancos vivem disso

Porque latência impacta:

  • PIX

  • cartão

  • bolsa financeira

  • APIs

Milissegundos importam.


☕🔥 NSLOOKUP — O “CATÁLOGO” DA INTERNET

DNS é uma das coisas mais subestimadas da computação.


☕ Exemplo:

nslookup openai.com

☕ O DNS traduz:

NOME → IP

☕ Sem DNS?

🔥 metade da internet parece “quebrada”.


☕ No Mainframe isso lembra:

  • HOST tables

  • VTAM naming

  • enterprise DNS

  • Sysplex resolution


☕ Problema clássico corporativo

Aplicação funciona por IP…

mas não por hostname.

O operador já sabe:

👉 DNS.


☕🔥 NETSTAT — O SDSF DAS CONEXÕES TCP/IP

Agora chegamos numa das ferramentas mais poderosas.


☕ Exemplo:

netstat -an

☕ Isso mostra:

  • conexões ativas

  • portas abertas

  • sockets

  • estados TCP


☕ No z/OS isso é extremamente importante

Existe literalmente:

NETSTAT CONN

☕ O operador Mainframe usa isso para:

  • troubleshooting

  • segurança

  • análise de portas

  • throughput

  • debugging de aplicações


☕ Estados TCP clássicos

ESTABLISHED
TIME_WAIT
LISTEN
CLOSE_WAIT

☕ CLOSE_WAIT excessivo?

🔥 possível vazamento de conexão.


☕ LISTEN em porta inesperada?

🔥 possível risco de segurança.


☕🔥 ARP -A — O “RACF DA REDE LOCAL”

Agora entramos numa área fascinante.


☕ Exemplo:

arp -a

☕ Isso mostra:

IP ↔ MAC ADDRESS

☕ Em redes corporativas isso é vital

Porque permite:

  • identificar dispositivos

  • rastrear hosts

  • detectar conflitos

  • investigar spoofing


☕ Cybersecurity ama ARP

Porque ataques clássicos incluem:

  • ARP poisoning

  • spoofing

  • MITM


☕ O Mainframe também depende disso

Principalmente em ambientes:

  • OSA Express

  • HiperSockets

  • Sysplex networking


☕🔥 IPCONFIG /FLUSHDNS — O “REFRESH” DA INTERNET

Agora uma ferramenta simples… mas extremamente útil.


☕ Exemplo:

ipconfig /flushdns

☕ O que isso faz?

Limpa cache DNS local.


☕ Parece pequeno…

Mas resolve MUITOS problemas.


☕ Situação clássica

Servidor mudou IP.

Cache ainda guarda endereço antigo.

Tudo parece quebrado.


☕ Flush DNS resolve.


☕ Bellacosa Mainframe Analysis™

Isso lembra muito:

VARY TCPIP,,OBEYFILE

ou refresh de cache em sistemas corporativos.


☕🔥 TELNET — O DINOSSAURO QUE AJUDOU A CONSTRUIR A INTERNET

Muita gente hoje vê Telnet como:

  • antigo

  • inseguro

  • ultrapassado

Mas historicamente ele foi revolucionário.


☕ Exemplo:

telnet servidor 80

☕ Isso testa:

  • conectividade

  • portas

  • serviços remotos


☕ No Mainframe?

Telnet foi GIGANTE.


☕ Terminais 3270 TCP/IP usaram isso por anos

Inclusive muitos ambientes z/OS ainda suportam:

  • TN3270

  • sessões remotas

  • emulação terminal


☕ Hoje SSH domina

Mas Telnet ainda aparece em:

  • troubleshooting

  • redes antigas

  • equipamentos legados


☕🔥 TCP/IP NO MAINFRAME NÃO É “ADAPTAÇÃO”

Isso é importante entender.

O z/OS não “aprendeu internet depois”.

Ele evoluiu junto com ela.


☕ Hoje o IBM Z suporta:

✅ IPv6
✅ TLS moderno
✅ APIs REST
✅ Open Banking
✅ MQ
✅ Kafka
✅ HTTP/2
✅ Web Services
✅ FTP/SFTP
✅ TN3270
✅ HiperSockets


☕🔥 HIPERSOCKETS — A “REDE QUÂNTICA” DO MAINFRAME

Pouca gente fora do z/OS conhece isso.

HiperSockets permitem comunicação interna:

🔥 sem passar fisicamente pela rede.


☕ Resultado?

  • latência absurdamente baixa

  • throughput gigante

  • segurança enorme


☕ Isso é perfeito para:

  • CICS

  • DB2

  • MQ

  • Sysplex


☕🔥 SYSPLEX — QUANDO VÁRIOS MAINFRAMES VIRAM UM “SUPER SISTEMA”

Aqui entramos em outro nível.

No Sysplex:

  • múltiplos z/OS cooperam

  • compartilham workload

  • compartilham dados

  • compartilham filas


☕ E tudo depende fortemente de networking

Porque no fundo:

🔥 o Mainframe moderno é um ecossistema distribuído gigantesco.


☕🔥 O QUE O MAINFRAME ENSINA SOBRE REDES

O mundo moderno descobriu:

  • observabilidade

  • latência

  • tracing

  • resiliência

  • failover

Mas o Mainframe já vivia isso há décadas.


☕ Porque quando você processa:

  • bilhões de dólares

  • bolsas financeiras

  • cartões globais

  • sistemas bancários

rede deixa de ser detalhe.

Rede vira:

🔥 missão crítica.


☕🔥 CONCLUSÃO — A INTERNET MODERNA AINDA PASSA PELO z/OS

Ping, Netstat, DNS e TCP/IP parecem ferramentas simples.

Mas por trás delas existe toda a engenharia que mantém:

  • bancos online

  • PIX funcionando

  • APIs financeiras

  • sistemas globais

  • transações em tempo real

E talvez essa seja a maior verdade sobre o Mainframe moderno:

Ele nunca ficou fora da internet.

🔥 A internet corporativa sempre passou silenciosamente por ele.

quinta-feira, 24 de outubro de 2013

☕🔥 NETWORKING NO IBM MAINFRAME — AS SIGLAS QUE MOVEM A INTERNET, OS BANCOS E O MUNDO SILENCIOSAMENTE

 

Bellacosa Mainframe numa visão ao networking no ibm

☕🔥 NETWORKING NO IBM MAINFRAME — AS SIGLAS QUE MOVEM A INTERNET, OS BANCOS E O MUNDO SILENCIOSAMENTE

Existe uma coisa fascinante no universo de redes:

🔥 praticamente toda a internet moderna funciona baseada em siglas.

IP.
DNS.
TCP.
TLS.
BGP.
VLAN.
MPLS.

Para muita gente isso parece apenas:

“letras técnicas aleatórias”.

Mas no universo corporativo REAL…

essas siglas sustentam:

  • bancos

  • bolsas financeiras

  • cloud

  • PIX

  • streaming

  • APIs

  • telecom

  • datacenters globais

E quando olhamos isso ao estilo Bellacosa Mainframe…

descobrimos algo impressionante:

o IBM Mainframe domina muitos desses conceitos há décadas.


☕🔥 IP — O “CPF” DA INTERNET

Tudo começa aqui.

IP = Internet Protocol


☕ O IP é o endereço do dispositivo.

Exemplo:

192.168.1.1

☕ Sem IP?

Nada conversa.


☕ Bellacosa Mainframe Analysis™

IP é como:

🔥 RACF ID da rede.

Cada sistema precisa de identidade única.


☕ No Mainframe isso é crítico

Porque o z/OS conversa com:

  • APIs

  • bancos

  • clouds

  • aplicações distribuídas

  • parceiros externos


☕ O TCP/IP stack do z/OS é absurdamente poderoso

E suporta:

✅ IPv4
✅ IPv6
✅ HiperSockets
✅ Sysplex Distributor
✅ TLS moderno


☕🔥 MAC ADDRESS — A “IDENTIDADE FÍSICA” DA PLACA

Agora descemos um nível.


☕ MAC Address é:

identidade da interface de rede

☕ Exemplo:

00:1A:2B:3C:4D:5E

☕ No Mainframe isso importa MUITO

Especialmente em:

  • OSA-Express

  • HiperSockets

  • redes corporativas críticas


☕ Cybersecurity usa MAC para:

  • rastrear dispositivos

  • detectar spoofing

  • auditoria de rede


☕🔥 LAN vs WAN — O MUNDO LOCAL vs O MUNDO GLOBAL


☕ LAN

Local Area Network

Rede interna.


☕ WAN

Wide Area Network

Rede geograficamente distribuída.


☕ O Mainframe vive nos dois mundos

LAN

Datacenter local.

WAN

Filiais, bancos, nuvem, parceiros.


☕ Grandes bancos possuem:

🔥 WANs monstruosas globais.


☕🔥 DNS — O “CATÁLOGO TELEFÔNICO” DA INTERNET

DNS traduz:

nome → IP

☕ Exemplo:

google.com
↓
142.x.x.x

☕ Sem DNS…

a internet parece quebrada.


☕ No Mainframe isso lembra:

  • HOST tables

  • VTAM naming

  • resolução corporativa


☕ Problema clássico

Aplicação responde via IP.

Mas hostname falha.

🔥 DNS.


☕🔥 DHCP — O “OPERADOR AUTOMÁTICO” DE ENDEREÇOS

DHCP entrega IP automaticamente.


☕ Sem DHCP…

seria necessário configurar tudo manualmente.


☕ Em ambientes Mainframe modernos isso aparece em:

  • ambientes híbridos

  • Linux on Z

  • virtualização

  • containers


☕🔥 HTTP vs HTTPS — O NASCIMENTO DA INTERNET SEGURA


☕ HTTP

Comunicação web básica.


☕ HTTPS

HTTP + criptografia TLS.


☕ Hoje HTTPS é obrigatório

Porque tráfego puro é perigoso.


☕ No z/OS isso é gigantesco

Especialmente com:

  • Open Banking

  • APIs REST

  • PIX

  • mobile banking


☕ Mainframe trabalha pesado com:

🔥 TLS acceleration.


☕ Porque criptografia em massa custa CPU.


☕🔥 FTP — O “DINOSSAURO” QUE AINDA MOVE ARQUIVOS CORPORATIVOS

Muita gente acha FTP morto.

Não está.


☕ Grandes empresas ainda trocam:

  • arquivos batch

  • remessas

  • integrações

  • cargas massivas

via FTP/SFTP.


☕ Mainframe sempre foi rei nisso

Especialmente em:

  • JES spool transfer

  • datasets

  • integração bancária


☕🔥 VPN — O “TÚNEL SECRETO” CORPORATIVO

VPN cria comunicação segura.


☕ Em bancos isso é crítico

Porque dados precisam atravessar:

  • internet pública

  • parceiros

  • filiais

com segurança.


☕ Bellacosa Mainframe Analysis™

VPN é como:

🔥 um túnel criptografado entre LPARs globais.


☕🔥 SSL/TLS — O “RACF” DA INTERNET

Agora entramos no coração da segurança moderna.


☕ TLS protege:

  • autenticação

  • integridade

  • confidencialidade


☕ Sem TLS:

🔥 qualquer interceptação vira desastre.


☕ O z/OS leva isso extremamente a sério

Com:

  • AT-TLS

  • RACF certificates

  • SAF integration


☕ Mainframe é obcecado por segurança

Porque precisa ser.


☕🔥 IDS & IPS — O “SEGURANÇA OPERACIONAL” DA REDE


☕ IDS

Detecta ataques.


☕ IPS

Bloqueia ataques.


☕ Isso lembra MUITO:

  • RACF alerts

  • SMF analysis

  • SIEM

  • automação NetView


☕ Hoje IA ajuda muito nisso

Especialmente em:

  • detecção comportamental

  • anomalias

  • tráfego suspeito


☕🔥 TCP vs UDP — CONFIABILIDADE vs VELOCIDADE

Agora chegamos numa das comparações mais clássicas da rede.


☕ TCP

Confiável.

Confirma entrega.


☕ UDP

Mais rápido.

Não garante entrega.


☕ TCP é perfeito para:

✅ bancos
✅ APIs
✅ DB2
✅ transações


☕ UDP é excelente para:

✅ streaming
✅ voz
✅ games
✅ realtime


☕ O Mainframe ama TCP

Porque:

🔥 integridade vem antes da velocidade.


☕🔥 ARP — O “WHO ARE YOU?” DA REDE

ARP traduz:

IP → MAC

☕ Parece pequeno…

Mas é fundamental.


☕ Sem ARP:

máquinas locais não se encontram.


☕🔥 VLAN — A “LPAR” DAS REDES

Agora vem uma analogia maravilhosa.


☕ VLAN segmenta redes logicamente.


☕ Isso lembra MUITO:

🔥 LPARs no Mainframe.


☕ Porque ambas fazem:

  • isolamento

  • segurança

  • separação lógica

  • organização


☕ Grandes bancos usam VLANs agressivamente.


☕🔥 NAT — O “TRADUTOR” DA INTERNET

NAT converte:

IP privado ↔ IP público

☕ Isso permite milhares de dispositivos compartilharem poucos IPs públicos.


☕ Sem NAT…

IPv4 já teria colapsado há muito tempo.


☕🔥 QoS — QUANDO A REDE APRENDE PRIORIDADE

QoS define:

🔥 quem tem prioridade.


☕ Exemplo:

PIX > YouTube corporativo.


☕ Em ambientes críticos isso é vital

Porque latência impacta:

  • trading

  • bancos

  • telecom

  • APIs realtime


☕🔥 BGP — O “JES2 DA INTERNET”

Agora entramos numa das peças mais importantes da internet mundial.


☕ BGP decide:

🔥 rotas globais entre provedores.


☕ Sem BGP…

a internet moderna entra em caos.


☕ Bellacosa Mainframe Analysis™

BGP lembra:

roteamento JES2/NJE gigantesco global

☕🔥 OSPF — O GPS CORPORATIVO

OSPF encontra melhor rota internamente.


☕ Muito usado em:

  • datacenters

  • backbone corporativo

  • grandes empresas


☕🔥 MPLS — A “REDE PREMIUM” CORPORATIVA

MPLS cria rotas eficientes e controladas.


☕ Bancos amam MPLS

Porque entrega:

✅ previsibilidade
✅ baixa latência
✅ controle
✅ QoS


☕🔥 O QUE O MAINFRAME ENSINA SOBRE REDES

O mercado moderno fala muito sobre:

  • observabilidade

  • resiliência

  • segurança

  • distribuição

Mas o Mainframe vive disso há décadas.


☕ Porque sistemas críticos exigem:

🔥 networking impecável.


☕ Quando bilhões dependem da rede…

“reiniciar e torcer” deixa de ser estratégia.


☕🔥 CONCLUSÃO — A INTERNET CORPORATIVA SILENCIOSAMENTE PASSA PELO MAINFRAME

IP, DNS, TLS, BGP e TCP parecem apenas siglas.

Mas por trás delas existe:

  • engenharia

  • segurança

  • confiabilidade

  • infraestrutura global

E talvez essa seja a maior verdade invisível da computação moderna:

enquanto o mundo fala sobre cloud…

🔥 o Mainframe continua sustentando silenciosamente as redes mais críticas do planeta.


segunda-feira, 9 de janeiro de 2012

🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito



 🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito




1️⃣ Introdução: quando o monólito saiu da jaula

Mainframer raiz conhece bem o monólito confiável: CICS firme, DB2 consistente, batch noturno pontual como relógio suíço. Durante décadas, aplicação distribuída era vista como “coisa de Unix instável” ou “modinha client-server”.

Mas o mundo girou. A web cresceu, o mobile explodiu, a nuvem virou padrão e, de repente, o monólito começou a ser fatiado em serviços. Nasciam as aplicações distribuídas — e com elas, novos problemas… e velhos conceitos que o mainframe já conhecia muito bem.

💡 Easter egg: se você já lidou com VTAM, MQSeries e sysplex, você já entendeu aplicações distribuídas… só não sabia o nome moderno disso.



2️⃣ O que são aplicações distribuídas (sem buzzword)

Uma aplicação distribuída é aquela em que:

  • O processamento ocorre em vários nós

  • Cada parte da aplicação pode rodar em máquinas, containers ou regiões diferentes

  • A comunicação acontece por rede, não por memória compartilhada

Exemplos modernos:

  • Microservices em Kubernetes

  • APIs REST + filas (Kafka, MQ, RabbitMQ)

  • Frontend web → backend → banco → cache → serviços externos

No fundo, é o velho conceito de desacoplamento, agora amplificado.


3️⃣ Paralelos diretos com o mundo mainframe 🧠

Mundo MainframeMundo Distribuído
CICS TransactionMicroservice
MQSeriesEvent Streaming
SysplexCluster
SMF / RMFTelemetria / Observabilidade
AbendException distribuída
Batch encadeadoPipelines assíncronos

👉 Conclusão Bellacosa: mainframers não estão atrasados — estão adiantados há 30 anos.


4️⃣ Principais desafios (spoiler: não são novos)

🔹 Latência

No mainframe, o gargalo era I/O.
No distribuído, é rede + serialização + hops excessivos.

🔹 Falhas parciais

No mundo distribuído:

“Se algo pode falhar, vai falhar, mas só um pedaço.”

Isso lembra:

  • Regiões CICS indisponíveis

  • LPAR isolada

  • Subsystem down às 03:12 😈

🔹 Consistência

Aqui entra o famoso CAP Theorem — mas mainframer chama isso de:

“Escolher entre disponibilidade e integridade quando o caldo entorna.”


5️⃣ Conceitos essenciais que todo mainframer deve dominar

✔️ Comunicação síncrona vs assíncrona

  • Síncrona: REST, RPC (espera resposta)

  • Assíncrona: filas, eventos, fire-and-forget
    👉 MQ old school total.

✔️ Escalabilidade horizontal

  • Escalar mais instâncias, não máquinas maiores
    (trauma de quem pedia upgrade de MIPS aprovado em comitê 😅)

✔️ Observabilidade

  • Logs

  • Métricas

  • Traces distribuídos

📌 Curiosidade: SMF foi o avô do tracing moderno.


6️⃣ Passo a passo mental para entender qualquer sistema distribuído

1️⃣ Identifique quais serviços existem
2️⃣ Veja como eles se comunicam
3️⃣ Descubra onde estão os pontos de falha
4️⃣ Analise latência e dependências
5️⃣ Verifique quem é o dono do dado
6️⃣ Observe como o sistema se comporta quando algo cai

🧨 Dica Bellacosa: desligue mentalmente um serviço e pergunte
“O que quebra primeiro?”


7️⃣ Guia de estudo para mainframers curiosos 📚

Conceitos

  • Microservices vs Monólito

  • Event-driven architecture

  • Observabilidade

  • Resiliência e retries

Ferramentas modernas (com alma antiga)

  • Instana / Dynatrace → RMF da nuvem

  • Prometheus → SMF open source

  • Kafka → MQSeries com esteroides

  • Kubernetes → Sysplex com YAML


8️⃣ Aplicações práticas no dia a dia

  • Integrar mainframe com APIs modernas

  • Expor transações CICS como serviços

  • Monitorar ambientes híbridos

  • Diagnosticar falhas ponta a ponta

  • Atuar como tradutor cultural entre legado e cloud

🎯 Mainframer que entende distribuído vira peça-chave.


9️⃣ Comentário final (meia-noite, café frio ☕)

Aplicações distribuídas não são o fim do mainframe.
São apenas o mesmo problema antigo, rodando em mais lugares, com nomes novos e menos disciplina.

Quem sobreviveu a:

  • Batch quebrado em fechamento

  • Deadlock às 02h

  • Região CICS instável em dia útil

…tem todas as credenciais para dominar o mundo distribuído.

🖤 El Jefe Midnight Lunch aprova:
legado não é atraso — é memória de guerra.