Bellacosa Mainframe apresenta Suporte a Produção

☕🔥 Suporte à Produção Mainframe — engenharia operacional em estado bruto

Se você já deu CANCEL com o coração na mão, já leu dump em hexadecimal, já decorou mensagem $HASP melhor que CPF, então este texto não é para iniciantes.
Aqui falamos de Produção de verdade. Sem romantização. Sem power-point bonito.

---

🧠 Suporte à Produção Mainframe ≠ Operação

É engenharia operacional sob carga real.

Produção não é:

• Rodar job

• Reiniciar STC

• Abrir chamado

Produção é:

• Análise de impacto

• Decisão em ambiente crítico

• Entendimento sistêmico do z/OS

• Correlação entre eventos aparentemente desconexos

Produção é onde o design encontra a realidade — e geralmente perde.

---

🕰️ Raiz Histórica (para quem veio do MVS, não do YouTube)

O Suporte à Produção nasce quando:

• O batch deixou de ser “linear”

• O online passou a ser 24x7

• O negócio começou a depender de janela de processamento

• O erro deixou de ser aceitável

A evolução foi clara:

• Operador de console →

• Analista de Produção →

• Especialista em estabilidade operacional

Hoje, Produção é a última linha de defesa entre o z/OS e o prejuízo financeiro.

---

🎯 Objetivo Real do Suporte à Produção (versão sem marketing)

• Garantir throughput, não apenas execução

• Controlar contenção, não apenas erro

• Preservar integridade transacional

• Manter SLA, RTO e RPO

• Atuar antes do incidente virar crise

☕ Veterano sabe:

Produção não corrige código — corrige efeito colateral.

---

🧩 Arquitetura de Conhecimento (o que separa júnior de veterano)

🖥️ z/OS — domínio do núcleo

• JES2/JES3, initiators, classes, priorities

• Spool contention

• ENQ/DEQ, RESERVE, latch

• WTOR, automation hooks

• Dumps SVC vs SYSMDUMP

🔥 Apimentado:
Quem não entende JES não entende produção.

---

🧠 CICS — transação é sagrada

• Task Control

• Storage violation

• Transaction isolation

• Deadlock silencioso

• Dumps DSNAP / CEEDUMP

☕ El Jefe truth:

CICS não cai — ele sangra em silêncio.

---

📬 MQ — quando o assíncrono vira gargalo

• Depth x High/Low Threshold

• Channels retrying

• Poison message

• Commit vs rollback

• Impacto no batch e no online

🔥 Easter egg:
Fila cheia é sintoma, não causa.

---

🔌 Integration Bus (Broker)

• Flow degradation

• Message backlog

• XML/JSON parsing cost

• CPU vs I/O trade-off

• Propagação de erro invisível

☕ Fofoquice técnica:
Quando o Broker falha, todo mundo aponta para o mainframe.

---

🧪 REXX — automação tática

• Monitoramento ativo

• Ações condicionais

• Coleta de evidência

• Resposta automática a eventos

• Integração com SDSF, consoles e logs

🔥 Produção sem REXX é operação cega.

---

🗄️ DB2 Utilities — o campo minado

• REORG mal planejado

• RUNSTATS atrasado

• Lock escalation

• Deadlock intermitente

• Log pressure

☕ Frase clássica:

“Não mexe agora… deixa rodar.”

---

🌐 WebSphere / Acesso Remoto

• JVM pressure

• Thread starvation

• Timeout mascarado

• Latência invisível

• Cascata de falhas

🔥 Curiosidade:
O Web cai rápido. O mainframe aguenta a culpa.

---

🔍 Funcionamento Real em Produção (sem filtro)

1. Sintoma aparece longe da causa

2. Métrica parece normal

3. SLA corre

4. Dump gerado

5. Análise cruzada (JES + CICS + DB2 + MQ)

6. Decisão com risco calculado

7. Execução mínima, impacto máximo

8. Ambiente estabiliza

9. Post-mortem técnico

10. Documentação (que ninguém lê… até precisar)

---

🧠 Mentalidade do Veterano

✔️ Não confia em “achismo”
✔️ Não executa comando sem rollback mental
✔️ Pensa em efeito dominó
✔️ Prefere degradar a parar
✔️ Sabe quando não agir

☕🔥 Regra de ouro:

Em Produção, o comando mais perigoso é o que “sempre funcionou”.

---

🥚 Easter Eggs de Produção

• Todo ambiente tem um job que “ninguém encosta”

• Sempre existe um dataset com DISP=SHR que não deveria

• Todo incidente grave começa com:

  “Isso nunca aconteceu antes…”

• O melhor analista é o que não aparece no incidente report

---

🧨 Conclusão — El Jefe Midnight Lunch Manifesto

Suporte à Produção Mainframe é:

• Arquitetura viva

• Engenharia sob estresse

• Decisão sem margem de erro

• Responsabilidade sem aplauso

Não é glamour.
Não é palco.
É confiança operacional.

☕🔥 Se você já sobreviveu a uma madrugada de produção,
você sabe:

Produção não ensina — ela seleciona.

 

 

🟦 Exemplo de Programa COBOL – Tratamento de Mensagem IBM MQ

🎯 O que este programa faz

1. Conecta ao Queue Manager

2. Abre uma fila de entrada

3. Lê uma mensagem (MQGET)

4. Trata o conteúdo

5. Atualiza dados (simulado)

6. Faz COMMIT

7. Fecha fila e desconecta

---

🧱 Premissas do exemplo

• Execução:

  • Batch ou CICS (a lógica é a mesma)

• Fila:

  • QUEUE.IN

• Queue Manager:

  • QMGR01

• Mensagem:

  • Texto simples

• Modelo:

  • MQI síncrono

  • Commit explícito

---

📦 COPYBOOKS NECESSÁRIOS

       COPY CMQC.
       COPY CMQX.

📌 Esses copybooks vêm do IBM MQ for z/OS
Normalmente ficam em SCSQCOBC.

---

🧠 Estrutura do Programa

---

🔹 IDENTIFICATION DIVISION

       IDENTIFICATION DIVISION.
       PROGRAM-ID. MQCONSUM.

---

🔹 DATA DIVISION

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01  WS-QMGR-NAME        PIC X(48) VALUE 'QMGR01'.
       01  WS-QUEUE-NAME       PIC X(48) VALUE 'QUEUE.IN'.

       01  WS-HCONN            PIC S9(9) COMP.
       01  WS-HOBJ             PIC S9(9) COMP.

       01  WS-COMPCODE         PIC S9(9) COMP.
       01  WS-REASON           PIC S9(9) COMP.

       01  WS-MSG-LEN          PIC S9(9) COMP.
       01  WS-BUFFER.
           05 WS-MSG           PIC X(1024).

       01  WS-MD               LIKE MQMD.
       01  WS-GMO              LIKE MQGMO.
       01  WS-OD               LIKE MQOD.

---

🔹 PROCEDURE DIVISION

---

1️⃣ Conectar ao Queue Manager

       CALL 'MQCONN'
            USING WS-QMGR-NAME
                  WS-HCONN
                  WS-COMPCODE
                  WS-REASON.

       IF WS-COMPCODE NOT = MQCC-OK
          DISPLAY 'ERRO MQCONN - REASON: ' WS-REASON
          GO TO FIM-PROGRAMA
       END-IF.

📌 Easter egg:
Se falhar aqui, o problema não é a fila, é ambiente.

---

2️⃣ Abrir a fila

       MOVE MQOD-DEFAULT TO WS-OD.
       MOVE WS-QUEUE-NAME TO WS-OD-OBJECTNAME.
       MOVE MQOO-INPUT-AS-Q-DEF TO WS-OD-OPTIONS.

       CALL 'MQOPEN'
            USING WS-HCONN
                  WS-OD
                  WS-HOBJ
                  WS-COMPCODE
                  WS-REASON.

       IF WS-COMPCODE NOT = MQCC-OK
          DISPLAY 'ERRO MQOPEN - REASON: ' WS-REASON
          GO TO DESCONECTA
       END-IF.

---

3️⃣ Ler a mensagem (MQGET)

       MOVE MQMD-DEFAULT TO WS-MD.
       MOVE MQGMO-DEFAULT TO WS-GMO.
       MOVE MQGMO-WAIT TO WS-GMO-OPTIONS.
       MOVE 5000 TO WS-GMO-WAITINTERVAL.

       CALL 'MQGET'
            USING WS-HCONN
                  WS-HOBJ
                  WS-MD
                  WS-GMO
                  LENGTH OF WS-BUFFER
                  WS-BUFFER
                  WS-MSG-LEN
                  WS-COMPCODE
                  WS-REASON.

       IF WS-COMPCODE = MQCC-FAILED
          IF WS-REASON = MQRC-NO-MSG-AVAILABLE
             DISPLAY 'SEM MENSAGEM NA FILA'
             GO TO FECHA-FILA
          ELSE
             DISPLAY 'ERRO MQGET - REASON: ' WS-REASON
             GO TO ROLLBACK
          END-IF
       END-IF.

📌 Regra de ouro:

MQRC 2033 não é erro. É silêncio.

---

4️⃣ Tratar a mensagem

       DISPLAY 'MENSAGEM RECEBIDA: ' WS-MSG(1:WS-MSG-LEN).

       *> Aqui você trataria o conteúdo:
       *> Parse, valida, chama DB2, CICS, etc.

---

5️⃣ Commit da transação

       CALL 'MQCMIT'
            USING WS-HCONN
                  WS-COMPCODE
                  WS-REASON.

       IF WS-COMPCODE NOT = MQCC-OK
          DISPLAY 'ERRO MQCMIT - REASON: ' WS-REASON
          GO TO ROLLBACK
       END-IF.

📌 Easter egg clássico:

90% dos “problemas de MQ” são COMMIT esquecido.

---

6️⃣ Fechar fila e desconectar

   FECHA-FILA.
       CALL 'MQCLOSE'
            USING WS-HCONN
                  WS-HOBJ
                  MQCO-NONE
                  WS-COMPCODE
                  WS-REASON.

   DESCONECTA.
       CALL 'MQDISC'
            USING WS-HCONN
                  WS-COMPCODE
                  WS-REASON.

---

7️⃣ Rollback (se algo der errado)

   ROLLBACK.
       CALL 'MQBACK'
            USING WS-HCONN
                  WS-COMPCODE
                  WS-REASON.

       DISPLAY 'ROLLBACK EXECUTADO'.
       GO TO FECHA-FILA.

---

🔚 Fim do programa

   FIM-PROGRAMA.
       STOP RUN.

---

🧠 O que este exemplo ensina (de verdade)

✔ Fluxo correto do MQ
✔ Tratamento de erros
✔ Uso de COMMIT / ROLLBACK
✔ Código legível para mainframer
✔ Pronto para:

• Batch

• CICS

• IMS

• DB2

---

📌 Dicas Bellacosa Mainframe

• Sempre trate:

  • 2033 (no message)

  • 2009 (connection broken)

• Nunca:

  • Esqueça COMMIT

  • Assuma que mensagem foi consumida

• Pense em MQ como:

  DB2 sem SQL

   

 

😈🔥 Lendo SMF do MQ como se fosse trace distribuído

Conhecimento básico sobre aplicações distribuídas para quem já confiou mais no SMF do que em qualquer dashboard

---

☕ 02:48 — Quando a fila cresce e ninguém sabe “quem começou”

No mundo cloud, alguém pergunta:

“Qual serviço está causando o problema?”

No mundo mainframe, a pergunta sempre foi melhor:

“Qual transação chegou primeiro?”

Este artigo é sobre ler SMF do IBM MQ for z/OS com a mesma lógica usada para distributed tracing moderno — só que com décadas a mais de maturidade.

---

1️⃣ Contexto histórico: antes do trace existir, o SMF já contava a história 🧬

Distributed tracing surgiu porque:

• sistemas ficaram espalhados

• ninguém sabia por onde o request passava

No z/OS:

• tudo sempre passou por um lugar auditável

• o SMF virou a linha do tempo oficial

📌 Comentário Bellacosa:
Trace é novidade.
Linha do tempo sempre foi obrigação.

---

2️⃣ O que é um trace distribuído, afinal? 🧩

Trace distribuído:

• segue um request

• de serviço em serviço

• até o resultado (ou falha)

SMF do MQ faz o mesmo:

• PUT

• fila

• GET

• consumo

• impacto em recursos

🔥 Tradução direta:
Cada mensagem no MQ é um request distribuído encapsulado.

---

3️⃣ Mapa mental: SMF do MQ ↔ Trace moderno 🗺️

SMF MQ (z/OS)	Trace distribuído	Significado
PUT MESSAGE	Span inicial	Entrada do request
Queue Name	Service name	Destino lógico
GET MESSAGE	Span consumidor	Processamento
Queue Depth	Lag	Acúmulo de trabalho
Elapsed Time	Latência	Tempo fim a fim
CPU / I/O	Resource usage	Custo do request
Aplicação	Service ID	Responsável

😈 Easter egg:
Fila crescendo é trace parado no meio do caminho.

---

4️⃣ Lendo SMF como linha do tempo (não como relatório) ⏱️

Erro comum:

• olhar SMF como estatística fria

Leitura correta:

• montar sequência temporal

• entender causa → efeito

📌 Comentário Bellacosa:
Trace não é gráfico bonito.
É história cronológica.

---

5️⃣ Passo a passo: leitura estilo “trace distribuído” 🔍

5.1 — Identifique o PUT inicial

• Quem publicou?

• Em que horário?

• Com qual volume?

👉 Equivalente ao primeiro span do trace.

---

5.2 — Observe a evolução da fila

• Crescimento constante?

• Explosão pontual?

😈 Easter egg:
Fila crescendo devagar é mais perigosa que pico.

---

5.3 — Analise o GET

• Está acontecendo?

• Está atrasado?

• Está mais lento?

📌 Tradução:
Consumidor virou gargalo.

---

5.4 — Correlacione com recursos (RMF mode) 📊

• CPU alta?

• I/O saturado?

• Espera?

🔥 Comentário Bellacosa:
Mensagem não some. Ela espera.

---

5.5 — Ache o primeiro desvio

• Antes do alerta

• Antes da reclamação

• Antes do incidente

👉 Esse é o root cause real.

---

6️⃣ Curiosidades que só mainframer percebe 😈

• MQ nunca mente

• Ele só acumula evidência

• SMF sempre esteve certo

• O erro humano vem depois

📌 Comentário ácido:
Alertas gritam. SMF sussurra — e acerta.

---

7️⃣ Erros clássicos ao analisar MQ ⚠️

❌ Aumentar depth máximo
❌ Ajustar buffers sem análise
❌ Culpar o MQ
❌ Ignorar correlação temporal

🔥 Regra imortal:
Fila cheia é consequência, não diagnóstico.

---

8️⃣ Guia de estudo prático 📚

Conceitos

• Mensageria confiável

• Backpressure

• Throughput vs Latência

• Observabilidade

• Root cause analysis

Exercício Bellacosa

👉 Pegue um relatório SMF do MQ
👉 Monte uma timeline manual
👉 Marque onde o fluxo parou

---

🎯 Aplicações práticas desse entendimento

• Integração mainframe-cloud

• Sistemas event-driven críticos

• Análise de gargalos

• Prevenção de incidentes

• Auditoria e compliance

🔥 Comentário final:
Quem entende SMF do MQ já entende tracing distribuído — só não chamava assim.

---

🖤 Epílogo — 03:19, filas sob controle

Enquanto o mundo descobre tracing,
o mainframe segue entregando história completa, com provas.

El Jefe Midnight Lunch assina:
“Mensagem não mente. E SMF nunca esquece.”

 

 💡 Mid-Week Tech Insight | IBM MQ for z/OS & SMF Data

Mensageria crítica explicada para quem já confia mais no SMF do que em dashboard bonito

---

☕ 02:22 — Quando a fila começa a crescer em silêncio

Todo mainframer já viveu esse momento:
o sistema “está no ar”, ninguém reclamou…
mas o depth da fila começa a subir.

No mundo distribuído isso vira pânico tardio.
No z/OS, isso vira SMF bem lido.

Este artigo é sobre IBM MQ for z/OS + SMF como fundação real de aplicações distribuídas críticas — sem hype, sem romantização.

---

1️⃣ Um pouco de história: quando mensageria virou espinha dorsal 🧬

Antes de “event-driven” virar buzzword:

• MQ já desacoplava sistemas

• Garantia entrega

• Preservava ordem

• Sobrevivia a falhas

📌 Comentário Bellacosa:
MQ não nasceu para “escala web”.
Nasceu para não perder mensagem.

---

2️⃣ Por que SMF é a alma do MQ no z/OS 🧠

No z/OS:

• Nada sério existe sem SMF

• Performance sem SMF é palpite

No MQ:

• SMF mostra o que realmente aconteceu

• Não o que alguém acha que aconteceu

🔥 Tradução direta:
SMF é o trace definitivo do MQ.

---

3️⃣ O que o SMF revela sobre o MQ (e ninguém vê) 🔍

Com SMF você enxerga:

• Volume de mensagens

• Taxa de PUT / GET

• Uso de CPU e I/O

• Esperas

• Gargalos por fila ou aplicação

😈 Easter egg:
Quem analisa SMF sabe que fila cheia não é causa — é sintoma.

---

4️⃣ MQ no mundo distribuído: o elo invisível 🌍

Aplicações modernas:

• Microservices

• Eventos

• APIs

Mas no core:

• MQ continua segurando o mundo

📌 Comentário ácido:
Kafka fala alto.
MQ entrega calado.

---

5️⃣ Passo a passo mental: analisando MQ via SMF 🧭

1️⃣ Observe o crescimento da fila
2️⃣ Correlacione com horário e carga
3️⃣ Analise PUT vs GET
4️⃣ Verifique latência e espera
5️⃣ Avalie consumo de CPU
6️⃣ Identifique aplicação causadora
7️⃣ Só então ajuste parâmetros

🔥 Regra de ouro:
Nunca aumente buffer antes de entender o gargalo.

---

6️⃣ SMF vs Observabilidade moderna (o encontro dos mundos) 📊

Mainframe	Mundo distribuído
SMF MQ	Traces de mensageria
RMF	Métricas de throughput
Queue Depth	Lag de consumidor
PUT/GET	Producer / Consumer
Abend	Incident

😈 Curiosidade:
O que hoje chamam de “lag” você sempre chamou de fila crescendo.

---

7️⃣ Erros comuns (e caros) ⚠️

❌ Ignorar SMF e confiar só em alertas
❌ Tratar MQ como “infra”
❌ Ajustar parâmetros sem evidência
❌ Não correlacionar com carga real

📌 Comentário Bellacosa:
Mensageria sem visibilidade vira buraco negro.

---

8️⃣ Guia de estudo prático 📚

Conceitos

• Mensageria confiável

• Desacoplamento real

• Backpressure

• Observabilidade

• Capacidade

Exercício

👉 Pegue dados SMF do MQ
👉 Monte uma linha do tempo
👉 Relacione com batch, online e APIs

---

🎯 Aplicações reais no mundo enterprise

• Core bancário

• Integração mainframe-cloud

• Sistemas regulados

• Alta disponibilidade

• Processamento assíncrono crítico

🔥 Comentário final:
Sem MQ, o distribuído cai.
Sem SMF, ninguém sabe por quê.

---

🖤 Epílogo — 03:05, filas sob controle

Enquanto alguns discutem se mensageria é “moderna”,
o MQ segue processando bilhões de mensagens… com SMF contando a verdade.

El Jefe Midnight Lunch assina:
“Mensagens podem esperar. Diagnóstico não.”

 

 

😈🔥 Manual não oficial de sobrevivência do mainframer em times cloud

Conhecimento básico sobre aplicações distribuídas para quem já viu produção cair em silêncio

---

☕ 08:59 — Daily começa, o risco também

Você entra no call.
Alguém diz:

“Hoje vamos subir direto em produção, é só um ajuste pequeno.”

Você, mainframer, já sente o cheiro de abend conceitual.

Este manual não é sobre tecnologia.
É sobre sobrevivência cultural e técnica em times cloud, sem perder sanidade — nem reputação.

---

1️⃣ Contexto histórico: por que você é estranho ali 🧬

O time cloud veio de:

• Startups

• Ambientes stateless

• Deploy diário

• “Se cair, a gente resolve”

Você veio de:

• SLA

• Batch noturno

• Controle transacional

• Auditoria

• Multas

📌 Tradução Bellacosa:
Eles foram treinados para velocidade.
Você foi treinado para não errar.

---

2️⃣ Regra de ouro #1: nunca diga “no mainframe…” 🛑

Diga:

• ❌ “No mainframe isso é melhor”

• ✅ “Em ambientes críticos, isso costuma falhar por causa de…”

🔥 Comentário ácido:
Argumento técnico convence. Nostalgia não.

---

3️⃣ Falha parcial: o novo inimigo invisível 👻

No mainframe:

• Caiu → caiu tudo → alguém resolve

No cloud:

• Um serviço cai

• Outro fica lento

• Um terceiro responde errado

• O sistema parece funcionar

😈 Easter egg traumático:
O erro mais caro é o que não quebra imediatamente.

---

4️⃣ Observabilidade: sem SMF, sem paz 📊

Se o time não sabe:

• Qual serviço respondeu

• Em quanto tempo

• Com qual dependência

👉 Então não existe produção, só esperança.

📌 Frase para reuniões:
“Sem observabilidade, não é sistema — é aposta.”

---

5️⃣ Event-driven: MQ não perdoa 📨

Quando alguém diz:

“É só publicar o evento”

Pergunte:

• É idempotente?

• Tem reprocessamento?

• E se duplicar?

• E se perder?

🔥 Comentário Bellacosa:
Evento não é desculpa para perder controle.

---

6️⃣ Retry mal feito mata silenciosamente 🔁

Retry:

• Sem backoff

• Sem limite

• Sem idempotência

= batch distribuído rodando para sempre

😈 Easter egg:
Retry é GO TO disfarçado.

---

7️⃣ Deploy contínuo ≠ deploy irresponsável 🚀

Explique:

• Feature flag

• Canary

• Rollback real

• Monitoramento pós-deploy

📌 Regra prática:
Quem não sabe voltar, não deveria ir.

---

8️⃣ Passo a passo de sobrevivência diária 🧭

1️⃣ Escute antes de julgar
2️⃣ Traduza buzzword para risco
3️⃣ Faça perguntas incômodas
4️⃣ Documente decisões
5️⃣ Peça métricas
6️⃣ Exija plano de rollback
7️⃣ Proteja produção como território sagrado

---

9️⃣ Curiosidades que só o mainframer percebe 👀

• “Alta disponibilidade” virou feature

• Logs são decorativos

• Produção é confundida com staging

• Ninguém pensa em auditoria

😈 Comentário realista:
Cloud ensinou muitos a programar.
Mainframe ensinou poucos a operar.

---

🔟 Guia de estudo para não virar o chato do time 📚

Conceitos

• CAP Theorem

• Resiliência

• SRE

• Observabilidade

• Arquitetura híbrida

Ferramentas

• APM (Instana, Dynatrace)

• Message brokers

• Feature flags

• Chaos Engineering (com juízo)

📌 Dica final:
Estude o suficiente para liderar sem impor.

---

🎯 Aplicações práticas desse manual

• Modernização de core

• Integração mainframe-cloud

• Arquitetura corporativa

• Times de plataforma

• Ambientes regulados

---

🖤 Epílogo — 23:58, produção ainda de pé

Você não está ali para atrasar o time.
Está ali para evitar que ele se autodestrua.

El Jefe Midnight Lunch assina:
“Quando o cloud falha, chamam o mainframer. Quando funciona, ninguém percebe.”

 

☁️🔥 Mainframe não morreu: ele só aprendeu a falar cloud

---

00:59 — Introdução: o boato da morte que nunca se confirmou

Toda década alguém decreta:

“Agora o mainframe acabou.”

E toda década o mainframe responde do mesmo jeito:

processando mais transações, com menos falha, mais segurança e menos barulho.

O que mudou não foi o mainframe.
Foi o jeito de conversar com o mundo.

Aplicações distribuídas não mataram o mainframe.
Elas forçaram o mainframe a virar poliglota.

---

1️⃣ Um pouco de história: do green screen à nuvem ☁️

• Anos 60–80: centralização total, terminais burros

• Anos 90: client-server, CICS como backbone

• Anos 2000: web, SOA, serviços expostos

• Anos 2010: cloud, APIs, eventos

• Hoje: mainframe como core cloud-ready

😈 Easter egg histórico:
CICS sempre foi serverless. Só não tinha marketing.

---

2️⃣ O mito: cloud substitui mainframe 🧠

Cloud é ótima para:

• Elasticidade

• UX

• Experimento rápido

• Carga variável

Mainframe é imbatível em:

• Consistência

• Segurança

• Throughput

• Custo por transação estável

📌 Tradução Bellacosa:

“Cloud corre. Mainframe sustenta.”

---

3️⃣ O que significa “falar cloud” no mainframe

Não é migrar tudo.
É integrar de forma inteligente.

Significa:

• Expor transações como APIs

• Publicar eventos

• Integrar via mensageria

• Ser observado como qualquer serviço moderno

• Participar de pipelines distribuídos

😈 Easter egg:
Quem já integrou CICS com MQ já estava no caminho.

---

4️⃣ Aplicações distribuídas: onde o mainframe entra 🧩

Em arquiteturas modernas:

• Frontend → cloud

• Backend → microservices

• Core → mainframe

O mainframe vira:

• System of Record

• Fonte de verdade

• Pilar de consistência

📎 Mainframer entende:
O dado crítico mora onde sempre morou.

---

5️⃣ Passo a passo para tornar o mainframe cloud-friendly

1️⃣ Identifique o core estável
2️⃣ Exponha capacidades (não tabelas)
3️⃣ Use APIs ou eventos
4️⃣ Evite acoplamento síncrono excessivo
5️⃣ Adicione observabilidade
6️⃣ Trate segurança como prioridade
7️⃣ Evolua sem big bang

💣 Dica Bellacosa:
Modernizar não é reescrever. É orquestrar.

---

6️⃣ Ferramentas que fazem o mainframe falar cloud 🛠️

• CICS Web Services / APIs

• IBM MQ

• z/OS Connect

• Kafka integration

• Instana / observabilidade

• CI/CD para z/OS

😈 Easter egg:
JCL em pipeline CI/CD assusta mais dev cloud do que dump hex 😈

---

7️⃣ Guia de estudo para mainframers do futuro 📚

Conceitos

• Aplicações distribuídas

• APIs

• Event-driven

• Observabilidade

• Resiliência

• Segurança zero trust

Habilidades

• Pensar em fluxo

• Aceitar falha parcial

• Trabalhar com times cloud

• Defender o core com argumentos técnicos

---

8️⃣ Aplicações práticas no mundo real

• Bancos digitais

• Fintechs

• Seguros

• Governo

• Telecom

🎯 Mainframer que fala cloud vira arquiteto indispensável.

---

9️⃣ Curiosidades que só veterano percebe 👀

• Mainframe já era multi-tenant

• Isolamento sempre foi nativo

• Segurança nunca foi opcional

• Disponibilidade sempre foi requisito

📌 Verdade inconveniente:
A cloud ainda está aprendendo o que o mainframe já domina.

---

🔟 Comentário final (01:43, sistema estável)

Mainframe não morreu.
Ele só parou de pedir licença.

Hoje ele:

• fala API,

• publica eventos,

• participa de cloud,

• sustenta o impossível.

Se você já:

• Defendeu o core contra modinha

• Integrau legado com futuro

• Entendeu que estabilidade é poder

Então você sabe:

🖤 El Jefe Midnight Lunch encerra com respeito:
O futuro é distribuído. O coração continua central.

💣 Event-Driven Architecture explicada para quem já confiou em MQ às cegas

---

00:00 — Introdução: quando o sistema falava por bilhetes

Antes de Kafka, antes de cloud, antes de “arquitetura hexagonal”, já existia mensageria.
Mainframer raiz lembra bem: MQSeries, filas persistentes, mensagens garantidas, commit, rollback e aquele silêncio confortável de quem confiava que “se entrou na fila, chega do outro lado”.

A Event-Driven Architecture (EDA) nada mais é do que isso:
👉 sistemas conversando por eventos, não por chamadas diretas.

💥 Easter egg: quem já depurou mensagem envenenada em fila sabe mais EDA do que muito arquiteto de LinkedIn.

---

1️⃣ O que é Event-Driven Architecture (sem buzzword)

EDA é um modelo onde:

• Um produtor emite um evento

• O evento é colocado em um broker

• Um ou mais consumidores reagem a esse evento

• Nenhum produtor sabe quem vai consumir

Tradução mainframe:

“Eu jogo na fila e durmo tranquilo.”

---

2️⃣ Por que EDA virou moda (de novo)

Nos sistemas distribuídos modernos:

• Tudo é instável

• A rede falha

• Serviços sobem e descem

• Escalar síncrono vira gargalo

EDA resolve isso com:

• Desacoplamento

• Assincronia

• Resiliência

• Escalabilidade horizontal

📌 Curiosidade: o que a cloud vende hoje como inovação, o mainframe entregava há décadas com disciplina.

---

3️⃣ O paralelismo direto: MQSeries vs Kafka 🧠

MQSeries	Kafka
Fila	Tópico
Mensagem	Evento
Persistência	Log distribuído
Commit	Offset
DLQ	Dead Letter Topic
Retry manual	Reprocessamento

😈 Easter egg: Kafka não garante “exatamente uma vez” tão fácil quanto prometem. Mainframer já desconfiava.

---

4️⃣ Evento não é chamada de serviço (grave isso)

Erro clássico de quem vem do síncrono:

• Usar evento esperando resposta

• Criar dependência invisível

• Transformar EDA em RPC disfarçado

👉 Evento é:

• Algo que já aconteceu

• Imutável

• Registrado para sempre (ou até expirar)

💬 “PedidoCriado” ≠ “CriaPedido()”

---

5️⃣ Passo a passo mental para desenhar EDA

1️⃣ O que aconteceu? (evento)
2️⃣ Quem precisa saber disso? (consumidores)
3️⃣ O produtor precisa esperar? (não!)
4️⃣ O evento pode ser repetido? (sempre!)
5️⃣ Existe reprocessamento? (obrigatório)
6️⃣ O sistema aguenta mensagens duplicadas?

📎 Dica Bellacosa:
Se duplicar quebra, não está pronto para EDA.

---

6️⃣ Idempotência: o velho truque com nome novo

Mainframer conhece:

• Controle por chave

• Flags de processamento

• Tabelas de controle batch

No EDA moderno:

• Idempotência é obrigatória

• Consumidor deve aguentar evento repetido

• “Exatamente uma vez” é lenda urbana

😈 Easter egg:
Quem já escreveu batch reentrante já venceu essa fase.

---

7️⃣ Falhas fazem parte do design 🔥

Em EDA:

• Mensagem pode atrasar

• Consumidor pode cair

• Ordem pode se perder

• Evento pode ficar órfão

📌 Curiosidade:
No mainframe isso chamava reprocessamento controlado.
Na cloud chamam de resiliência.

---

8️⃣ Guia de estudo para mainframers migrantes 📚

Conceitos-chave

• Event-Driven Architecture

• At-least-once delivery

• Idempotência

• Eventual Consistency

• Dead Letter Queue

Ferramentas modernas (espírito antigo)

• Kafka

• RabbitMQ

• IBM MQ

• EventBridge

• Pub/Sub

---

9️⃣ Aplicações práticas no mundo real

• Integração entre sistemas legados e cloud

• Processamento assíncrono de pedidos

• Auditoria e rastreabilidade

• Desacoplamento de core systems

• Alta escalabilidade sem travar tudo

🎯 Mainframer com EDA vira arquiteto natural.

---

🔟 Comentário final (03:04, plantão eterno)

Event-Driven Architecture não é moda.
É mensageria com orgulho.

Se você já:

• Confiou em MQ sem ver o consumidor

• Lidou com DLQ às 06h da manhã

• Reprocessou lote sem duplicar dado

Então você já viveu EDA.

🖤 El Jefe Midnight Lunch decreta:
Quem entende filas, entende o futuro.