⚔️ MITSUHA YAMANO E A DUNGEON DOS SETE PROTOCOLOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE REST NÃO ERA O ÚNICO PORTAL

 

Bellacosa Mainframe e os 7 protocolos nas APIs

☕ Um Café no Bellacosa Mainframe

⚔️ MITSUHA YAMANO E A DUNGEON DOS SETE PROTOCOLOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE REST NÃO ERA O ÚNICO PORTAL

REST, GraphQL, gRPC, WebSockets, Webhooks, SSE, MQTT, mensageria, eventos, idempotência, sistemas distribuídos — e o dia em que Mitsuha descobriu que uma API mal escolhida pode custar muito mais que 80.000 moedas de ouro.

---

🎬 PRÓLOGO — MITSUHA ENCONTROU SETE PORTAIS

Mitsuha Yamano olhou para o quadro.

Havia sete portais desenhados diante dela:

REST
GraphQL
gRPC
WebSocket
Webhook
SSE
MQTT

Ao lado estava um jovem programador COBOL.

Ele conhecia algumas coisas.

Sabia que:

MOVE 100 TO WS-QUANTIDADE.

IF WS-SALDO >= WS-VALOR
    PERFORM PROCESSA-PAGAMENTO
END-IF.

Sabia alguma coisa sobre arquivos, JCL e talvez estivesse começando a descobrir CICS, Db2 e VSAM.

Mas aquela sopa de siglas modernas parecia magia.

Mitsuha olhou para ele.

— Qual você escolheria?

— REST.

— Por quê?

— Porque todo mundo usa REST.

Mitsuha suspirou.

Era exatamente assim que se perdia uma fortuna em outro mundo.

Porque a primeira lição desta aventura é:

Tecnologia não deve ser escolhida porque está na moda. Ela deve ser escolhida porque resolve adequadamente um problema.

E REST, GraphQL, gRPC, WebSocket, Webhooks, SSE e MQTT não são simplesmente sete concorrentes tentando conquistar o mesmo reino.

Eles resolvem tipos diferentes de conversa entre sistemas.

Prepare o café.

Nossa dungeon começa aqui.

---

🏰 CAPÍTULO 1 — ANTES DA API EXISTIA A CONVERSA

Antes de falarmos sobre REST, precisamos entender algo muito mais básico.

Computadores precisam conversar.

Imagine dois programas:

PROGRAMA A

     precisa de uma informação

          ↓

PROGRAMA B

Se os dois estão dentro do mesmo processo, a comunicação pode ser relativamente simples.

No COBOL podemos ter:

CALL 'CALCJURO'
    USING WS-VALOR
          WS-TAXA
          WS-RESULTADO.

O programa chama outro programa.

Mas imagine que CALCJURO não está na mesma máquina.

Ele está em outro servidor.

Talvez em outro datacenter.

Talvez em outro país.

Agora temos:

Programa A
    |
    | REDE
    |
    v
Programa B

Acabamos de entrar no mundo dos sistemas distribuídos.

E a rede acrescentou vários monstros à dungeon:

latência
timeout
queda de conexão
mensagem duplicada
mensagem perdida
servidor indisponível
autenticação
autorização
criptografia
ordenação
retry

Quando tudo acontece dentro de um programa COBOL, podemos pensar:

PERFORM A
PERFORM B
PERFORM C

Quando distribuímos isso pela rede, precisamos começar a pensar:

Enviei A.

Será que chegou?

Se chegou, será que processou?

Se processou, por que não respondeu?

Posso enviar novamente?

Se enviar novamente, será executado duas vezes?

Bem-vindo à arquitetura distribuída.

---

🌐 CAPÍTULO 2 — O PRIMEIRO PORTAL CHAMA-SE REST

REST significa:

Representational State Transfer.

O termo ficou conhecido a partir do trabalho acadêmico de Roy Fielding no início dos anos 2000.

Mas cuidado com uma simplificação muito comum:

REST não significa simplesmente “JSON trafegando por HTTP”.

REST é um estilo arquitetural.

Uma das ideias mais importantes é trabalhar com recursos.

Imagine um banco.

Existem:

CLIENTE
CONTA
CARTÃO
PAGAMENTO
EMPRÉSTIMO

Podemos representar esses recursos por endereços:

/customers/12345

/accounts/98765

/cards/45678

E utilizar métodos HTTP.

Por exemplo:

GET /customers/12345

significa aproximadamente:

Quero consultar o cliente 12345.

Enquanto:

POST /payments

poderia significar:

Quero criar um novo pagamento.

Temos métodos conhecidos como:

GET
POST
PUT
PATCH
DELETE

Uma associação didática comum seria:

GET       consultar
POST      criar/processar
PUT       substituir/atualizar
PATCH     alterar parcialmente
DELETE    remover

Mas não transforme isso numa religião. A semântica real da API precisa ser bem projetada.

---

🧙 CAPÍTULO 3 — MITSUHA COLOCA CICS ATRÁS DO PORTAL

Agora nosso COBOLzeiro pergunta:

— Preciso jogar meu COBOL fora para criar APIs?

Mitsuha quase derrubou o café.

Não.

Esse é justamente um dos pontos mais interessantes da modernização de mainframe.

Imagine um programa COBOL executado por CICS contendo uma regra de negócio importantíssima:

Aplicativo Mobile
       |
       | HTTPS / REST
       v
    API Layer
       |
       v
 z/OS Connect
       |
       v
     CICS
       |
       v
     COBOL
       |
   +---+---+
   |       |
  Db2     VSAM

O aplicativo moderno não precisa necessariamente conhecer detalhes internos do COBOL.

Ele pode pedir:

GET /accounts/12345/balance

Uma camada de integração transforma essa requisição em algo compreensível pelo ambiente existente.

O COBOL executa sua lógica.

O resultado volta.

Talvez como:

{
  "account": "12345",
  "balance": 8750.42,
  "currency": "BRL"
}

Observe o detalhe.

O COBOL pode continuar fazendo aquilo que faz bem:

regra de negócio
transação
processamento
acesso aos dados

A API torna essa capacidade acessível ao restante do ecossistema.

Modernização não significa obrigatoriamente:

destruir o sistema antigo.

Às vezes significa:

construir uma porta moderna para um sistema extremamente valioso.

---

🧬 CAPÍTULO 4 — GRAPHQL ENTRA NA LOJA DE MITSUHA

Agora imagine que Mitsuha abriu sua loja.

Na tela inicial ela precisa mostrar:

Nome
Saldo
Últimas compras
Cartões
Limite
Notificações

Com determinadas APIs REST, poderíamos acabar fazendo:

GET /customer/123
GET /customer/123/accounts
GET /customer/123/cards
GET /customer/123/orders
GET /customer/123/notifications

Cinco requisições.

Outra API poderia responder tudo em uma chamada, mas devolver 80 campos quando a tela utiliza apenas 7.

Temos dois problemas clássicos.

Over-fetching

Você pede pouca coisa e recebe uma carroça inteira.

PRECISO:

nome
saldo


RECEBO:

nome
saldo
endereço
telefone
data nascimento
histórico
cartões
preferências
...

Under-fetching

Você recebe tão pouco que precisa continuar perguntando:

cliente?

agora cartões?

agora pedidos?

agora itens?

agora endereço?

GraphQL oferece outra abordagem.

O cliente pode declarar os campos desejados:

query {
  customer(id: 123) {
    name
    accounts {
      balance
    }
  }
}

Isso é poderoso especialmente em interfaces com necessidades de dados complexas.

Mas Mitsuha levanta o dedo:

— Não existe magia grátis.

GraphQL também traz desafios:

schemas
resolvers
cache
autorização
complexidade das consultas
observabilidade
N+1 queries
limitação de profundidade
controle de custo

Uma consulta aparentemente inocente pode gerar enorme trabalho internamente se a arquitetura estiver mal implementada.

Portanto:

GraphQL não é REST melhorado.

São modelos diferentes.

---

⚡ CAPÍTULO 5 — gRPC PARECE ESTRANHAMENTE FAMILIAR AO COBOLZEIRO

Mitsuha escreve:

CALL 'AUTORIZA'
    USING WS-CARTAO
          WS-VALOR
          WS-RETURN-CODE.

O programador sorri.

Finalmente alguma coisa familiar.

Então ela desenha:

SERVIÇO A

   chama

SERVIÇO B

RPC significa Remote Procedure Call.

A ideia geral é fazer uma operação localizada em outro processo ou máquina parecer, conceitualmente, uma chamada de procedimento.

gRPC é uma tecnologia moderna muito utilizada nesse universo.

Normalmente os contratos são definidos com Protocol Buffers.

Por exemplo:

service PaymentService {

    rpc Authorize(PaymentRequest)
        returns (PaymentResponse);

}

Temos um contrato bem definido.

Uma vantagem importante é a possibilidade de geração de código para diferentes linguagens.

Podemos ter:

Java
   |
  gRPC
   |
   v
Go Service

ou:

Python
   |
  gRPC
   |
   v
Java

Protocol Buffers utiliza representação binária compacta, diferentemente do JSON textual tão associado às APIs REST.

Isso torna gRPC particularmente interessante em muitos cenários de comunicação interna entre serviços.

Easter egg COBOL

O veterano olha para aquilo e comenta:

— Então inventaram CALL USING pela rede?

Não exatamente.

Mas como modelo mental inicial para nosso Padawan COBOL?

Funciona maravilhosamente bem.

---

🔥 CAPÍTULO 6 — WEBSOCKET MANTÉM O PORTAL ABERTO

Agora Mitsuha pergunta:

— Como você descobriria se apareceu uma nova mensagem?

O aprendiz responde:

— Perguntaria.

Tem mensagem?

Tem mensagem?

Tem mensagem?

Tem mensagem?

Tem mensagem?

Parabéns.

Você acabou de descobrir o polling.

Dependendo do problema, polling é perfeitamente aceitável.

O problema aparece quando milhares de clientes perguntam repetidamente:

mudou?

mudou?

mudou?

mudou?

mesmo quando nada mudou.

WebSocket permite manter uma conexão de comunicação bidirecional.

CLIENTE <====================> SERVIDOR

Depois de estabelecida a comunicação, ambos podem transmitir informações.

Isso é extremamente útil em:

chat
jogos multiplayer
dashboards
colaboração
telemetria
atualizações interativas

Imagine nossa War Room Mainframe:

           IBM Z
             |
       SMF / MONITOR
             |
             v
          Backend
             |
        WebSocket
             |
             v
+---------------------------+
|    WAR ROOM MAINFRAME     |
+---------------------------+
| CPU                 73%   |
| CICS RESPONSE       0.2s  |
| MQ DEPTH            173   |
| DB2                 OK    |
| BATCH               OK    |
+---------------------------+

Se algum indicador muda, o backend pode enviar imediatamente uma atualização.

---

📡 CAPÍTULO 7 — SSE: MITSUHA LIGA A ESTAÇÃO DE RÁDIO

Nem sempre precisamos de comunicação nos dois sentidos.

Às vezes queremos principalmente:

SERVIDOR
   |
   |
   |
   v
CLIENTE

É aqui que entram Server-Sent Events, ou SSE.

O cliente estabelece uma conexão HTTP e o servidor pode continuar enviando eventos.

Pense numa estação transmitindo:

evento 1
evento 2
evento 3
evento 4

Isso combina muito bem com:

notificações
feeds
status
progresso
logs
streaming de respostas

Um exemplo moderno está nas aplicações de IA.

Imagine esperar 40 segundos para receber:

RESPOSTA COMPLETA

Podemos, em vez disso, transmitir progressivamente:

COBOL

COBOL foi

COBOL foi criado

COBOL foi criado no...

A experiência percebida pelo usuário melhora muito.

WebSocket versus SSE

Guarde este desenho:

WebSocket

CLIENTE <==========> SERVIDOR


SSE

CLIENTE <----------- SERVIDOR

Precisa de conversa contínua nos dois sentidos?

WebSocket pode fazer sentido.

O servidor precisa principalmente transmitir atualizações ao cliente?

SSE pode ser uma solução mais simples.

---

🔔 CAPÍTULO 8 — WEBHOOK: “MITSUHA, EU TE AVISO”

Agora chegamos a um dos conceitos mais elegantes.

Imagine Mitsuha esperando um pagamento.

Uma estratégia seria:

Pagamento chegou?

Pagamento chegou?

Pagamento chegou?

Pagamento chegou?

Polling novamente.

Mas podemos inverter.

Mitsuha informa:

Quando acontecer,
mande a informação para cá.

Ela registra um endpoint:

https://loja.example/events/payment

Quando o pagamento acontece:

Sistema de pagamento
        |
        | HTTP POST
        v
Webhook Mitsuha
        |
        v
Processamento

Simples.

Até chegar a produção.

Porque o endpoint pode estar indisponível.

Então precisamos pensar em:

retry
timeout
backoff
assinatura
segurança
logs
monitoramento
duplicidade
idempotência

E aqui aparece um monstro fantástico.

---

👹 CAPÍTULO 9 — O DEMÔNIO DA DUPLICIDADE

Imagine:

Mitsuha envia pagamento de 100 moedas.

O servidor recebe.

Processa.

Debita.

Mas quando vai responder:

HTTP 200 OK

a conexão cai.

Para Mitsuha:

?????????

Ela não sabe se o pagamento aconteceu.

Então tenta novamente.

Se o sistema simplesmente processar outra vez:

100 moedas
+
100 moedas
=
200 moedas

Temos um problema sério.

Por isso sistemas de pagamento frequentemente trabalham com conceitos de idempotência.

Uma operação idempotente pode ser repetida sem produzir efeitos adicionais indevidos para a mesma intenção.

Podemos associar à operação uma chave:

IDEMPOTENCY-KEY:
PAY-20260925-000317

O servidor registra:

PAY-20260925-000317 = PROCESSADO

Se receber novamente:

PAY-20260925-000317

ele consegue reconhecer:

Eu já processei esta intenção.

Isso é extremamente importante em sistemas distribuídos.

E nosso easter egg apareceu:

03:17

Veteranos da War Room Bellacosa sabem que incidentes gostam de acontecer justamente quando ninguém gostaria de estar acordado.

---

📻 CAPÍTULO 10 — MQTT E O EXÉRCITO DE PEQUENOS DISPOSITIVOS

Mitsuha agora possui:

10 sensores

Depois:

1.000 sensores

Depois:

100.000 sensores

Cada um precisa transmitir pequenas informações.

Temperatura:

27.3

Pressão:

1012

Estado:

ON

MQTT foi projetado pensando em comunicação leve e funciona muito bem em cenários envolvendo IoT, dispositivos e redes com restrições.

Seu modelo clássico envolve:

PUBLISHER
    |
    v
  BROKER
    |
 +--+--+
 |  |  |
 v  v  v
S1 S2 S3

O produtor publica em um tópico:

factory/machine17/temperature

Os interessados assinam tópicos.

A máquina 17 não precisa conhecer todos os consumidores.

Ela apenas publica.

Isso produz uma propriedade arquitetural valiosíssima:

desacoplamento.

O produtor não precisa saber necessariamente quem consumirá aquela informação.

---

📨 CAPÍTULO 11 — O COBOLZEIRO RECONHECE IBM MQ NA TAVERNA

Nesse momento nosso aprendiz interrompe:

— Espera. Publisher, consumidor, mensagens, filas, desacoplamento... isso parece mensageria.

EXATAMENTE.

Agora estamos chegando a uma ponte maravilhosa entre arquitetura moderna e mainframe.

Imagine:

COBOL
   |
   v
IBM MQ
   |
   +------> SISTEMA A
   |
   +------> SISTEMA B
   |
   +------> INTEGRAÇÃO

O universo corporativo trabalha há décadas com conceitos como:

filas
mensagens
persistência
transações
assincronicidade
store-and-forward
publish/subscribe

Por isso um profissional mainframe experiente frequentemente encontra conceitos supostamente “moderníssimos” e pensa:

Já enfrentei esse monstro antes.

Mudaram as ferramentas.

Mudaram os nomes.

Mudaram as abstrações.

O problema fundamental continua reconhecível.

---

🧠 CAPÍTULO 12 — NÃO SÃO REALMENTE “SETE PROTOCOLOS IGUAIS”

Existe uma correção conceitual importante na imagem que iniciou nossa aventura.

Colocar tudo sob o título “7 API Protocols” facilita a comunicação, mas tecnicamente mistura categorias diferentes.

REST é essencialmente um estilo arquitetural.

GraphQL envolve linguagem de consulta, sistema de tipos e runtime.

gRPC é um framework/sistema de RPC.

WebSocket é efetivamente um protocolo.

MQTT também é protocolo.

Webhooks representam principalmente um padrão de integração orientado a eventos.

SSE é um mecanismo padronizado para eventos enviados pelo servidor sobre HTTP.

Portanto, imagine a placa:

7 FORMAS IMPORTANTES
DE SISTEMAS CONVERSAREM

Ela seria menos sexy para LinkedIn.

Mas pedagogicamente seria mais segura. 😄

---

🧙‍♀️ CAPÍTULO 13 — MITSUHA DESCOBRE QUE FALTAVAM PORTAIS

Nossa lista também não contém todo o universo.

Precisamos conhecer pelo menos conceitualmente outros habitantes dessa dungeon.

SOAP

Foi extremamente importante na história dos Web Services empresariais.

Normalmente associado a XML e contratos formais, apareceu intensamente em integrações corporativas.

Ainda existem muitos sistemas utilizando SOAP.

AMQP

Importante no universo de mensageria.

Kafka

Apache Kafka popularizou arquiteturas baseadas em event streaming em enorme escala.

O modelo mental começa a ficar diferente de simplesmente:

manda mensagem
recebe mensagem
acabou

Eventos podem formar um registro persistente que consumidores processam conforme suas necessidades.

IBM MQ

Para o COBOLzeiro e para ambientes empresariais críticos, seria impossível discutir seriamente integração sem mencionar MQ.

Especialmente quando começamos a conversar sobre confiabilidade.

---

🏦 CAPÍTULO 14 — UMA ARQUITETURA REAL USA VÁRIOS PORTAIS

Agora Mitsuha finalmente constrói seu império financeiro.

O aplicativo utiliza REST:

MOBILE
   |
 REST
   |
API GATEWAY

Internamente alguns microsserviços conversam via gRPC:

SERVICE A
   |
 gRPC
   |
SERVICE B

O mainframe continua responsável por determinadas regras:

API
 |
 v
z/OS Connect
 |
 v
CICS
 |
 v
COBOL
 |
 +---- Db2
 |
 +---- VSAM

Eventos importantes passam por mensageria:

COBOL
 |
 v
 MQ
 |
 +------> Fraud
 |
 +------> Settlement
 |
 +------> Notification

O parceiro externo recebe:

WEBHOOK

O dashboard recebe:

SSE

O chat utiliza:

WebSocket

Sensores de algum equipamento poderiam utilizar:

MQTT

Veja o ponto fundamental.

Não escolhemos:

REST OU gRPC OU MQ OU WebSocket

Podemos escolher:

REST
+
gRPC
+
MQ
+
Webhook
+
SSE

porque cada tecnologia ocupa uma posição diferente na arquitetura.

---

⚔️ CAPÍTULO 15 — O VERDADEIRO CHEFÃO É O SISTEMA DISTRIBUÍDO

Nosso aprendiz agora conhece sete tecnologias.

Ele está feliz.

Mitsuha, porém, abre a última porta.

Atrás dela existe um monstro gigantesco chamado:

DISTRIBUTED SYSTEM

Porque aprender sintaxe é relativamente fácil.

O difícil é responder perguntas como:

E se a rede cair?

E se a mensagem chegar duas vezes?

E se não chegar?

E se chegar fora de ordem?

E se o servidor processar,
mas não conseguir responder?

E se o consumidor ficar offline?

E se eu tiver 10.000 consumidores?

E se uma operação demorar 40 segundos?

E se ocorrer timeout?

Posso tentar novamente?

Como sei o que aconteceu?

É aqui que entram conceitos fundamentais:

timeout
retry
backoff
idempotência
circuit breaker
dead-letter queue
observabilidade
correlation ID
tracing
autenticação
autorização
rate limiting

---

🔍 CAPÍTULO 16 — OBSERVABILIDADE: QUEM NÃO ENXERGA NÃO INVESTIGA

Imagine uma transação:

Mobile
  |
API
  |
Service A
  |
MQ
  |
COBOL
  |
Db2

O cliente reclama:

Meu pagamento desapareceu.

Onde?

Precisamos seguir a transação.

Um identificador de correlação pode ajudar:

CORRELATION-ID

TX-20260925-00042

Então conseguimos procurar:

API
TX-20260925-00042

SERVICE
TX-20260925-00042

MQ
TX-20260925-00042

COBOL
TX-20260925-00042

Agora a investigação deixa de ser:

Acho que o problema está no mainframe.

E passa a ser:

14:31:02.103 API recebeu
14:31:02.121 API publicou
14:31:02.135 MQ recebeu
14:31:02.148 COBOL iniciou
14:31:02.172 Db2 COMMIT
14:31:02.181 resposta publicada

Isso é ouro operacional.

Em ambientes modernos distribuídos, observabilidade não deveria ser decoração.

É parte da arquitetura.

---

🗺️ CAPÍTULO 17 — O MAPA DE DECISÃO DE MITSUHA

Quando precisar escolher uma abordagem, não comece pela tecnologia.

Faça perguntas.

Passo 1 — Quem inicia a conversa?

Cliente?

Servidor?

Dispositivo?

Outro sistema?

Passo 2 — Preciso de resposta imediata?

Se sim, um modelo síncrono pode ser apropriado.

Se não, mensageria assíncrona pode oferecer vantagens.

Passo 3 — Preciso manter conexão aberta?

Se não:

REST
GraphQL
Webhook

podem aparecer entre as possibilidades, dependendo do problema.

Se sim:

WebSocket
SSE
gRPC streaming

podem entrar na análise.

Passo 4 — A comunicação é bidirecional?

Se for:

WebSocket

merece investigação.

Se for predominantemente servidor → cliente:

SSE

pode ser suficiente.

Passo 5 — Tenho muitos produtores e consumidores desacoplados?

Pense em:

MQ
MQTT
Kafka
event-driven architecture

Passo 6 — Posso perder uma mensagem?

Essa pergunta muda tudo.

Pergunte também:

Posso duplicar?

Preciso manter ordem?

Preciso fazer replay?

Por quanto tempo?

Preciso comprovar processamento?

Agora estamos fazendo arquitetura.

---

💰 CAPÍTULO 18 — MITSUHA ENSINA A REGRA DAS 80.000 MOEDAS

Existe uma armadilha recorrente em tecnologia:

“X é moderno.”

Logo:

“Vamos usar X.”

Não.

Imagine usar WebSocket para uma operação executada uma vez por mês.

Ou GraphQL para uma API trivial com três campos.

Ou introduzir Kafka onde uma fila simples resolveria perfeitamente.

Ou fazer polling a cada segundo quando um webhook resolveria o problema.

Complexidade também custa dinheiro.

Ela produz:

infraestrutura
monitoramento
treinamento
suporte
incidentes
dependências
documentação
segurança
manutenção

Mitsuha não ficaria rica gastando 80.000 moedas para resolver um problema de 8 moedas.

Arquitetura madura procura a solução adequada, não a solução com maior quantidade de siglas.

---

🏛️ CAPÍTULO 19 — A CATEDRAL MAINFRAME JÁ CONHECIA MUITOS DESSES MONSTROS

Existe uma deliciosa ironia histórica aqui.

Hoje falamos constantemente em:

mensageria
eventos
transações
filas
RPC
assíncrono
publish/subscribe
observabilidade
alta disponibilidade
processamento distribuído

Muitos desses problemas são antigos.

Mainframes empresariais enfrentam há décadas desafios relacionados a:

milhares de transações
concorrência
integridade
recuperação
auditoria
segurança
mensageria
disponibilidade

CICS, IMS, Db2, MQ e outras tecnologias nasceram e evoluíram dentro dessa realidade.

Isso não significa que:

“Mainframe já inventou tudo.”

Seria exagero.

Significa algo muito mais interessante:

Os problemas fundamentais da computação sobrevivem às gerações de tecnologia.

As abstrações mudam.

Os protocolos evoluem.

As interfaces ficam mais elegantes.

Mas continuamos perguntando:

Quem envia?

Quem recebe?

Quando?

Em qual ordem?

Quantas vezes?

O que acontece se falhar?

---

🥚 EASTER EGG — A TRANSAÇÃO FANTASMA DAS 03:17

Às 03:17 da manhã, Mitsuha recebe uma ligação.

— Produção caiu!

Ela abre o dashboard.

REST funcionando.

CICS funcionando.

Db2 funcionando.

MQ funcionando.

Tudo verde.

Mesmo assim, pagamentos estão sendo duplicados.

Depois de duas horas investigando, encontra:

Webhook
   |
timeout
   |
retry
   |
processamento novamente

A aplicação consumidora não implementava idempotência corretamente.

O mesmo evento havia sido processado várias vezes.

Mitsuha olha para o aprendiz.

— Qual protocolo falhou?

Ele pensa.

— Nenhum.

Exatamente.

O erro estava no desenho do sistema.

Essa talvez seja a lição mais importante desta dungeon.

---

☕ EPÍLOGO — O COBOLZEIRO ATRAVESSOU OS SETE PORTAIS

Nosso jovem programador começou acreditando que precisava decorar:

REST
GraphQL
gRPC
WebSocket
Webhook
SSE
MQTT

Terminou entendendo algo muito maior.

Essas tecnologias representam diferentes maneiras de sistemas trocarem informações.

REST ensina a pensar em recursos e interfaces HTTP.

GraphQL permite ao consumidor declarar dados de que necessita.

gRPC aproxima sistemas distribuídos de um modelo de chamada remota baseado em contratos fortemente definidos.

WebSocket mantém um canal bidirecional.

SSE permite ao servidor transmitir eventos continuamente ao cliente.

Webhooks invertem o polling:

não fique perguntando; eu aviso quando acontecer.

MQTT apresenta um modelo leve de publish/subscribe extremamente útil para dispositivos e IoT.

E mensageria empresarial, MQ, event streaming e tecnologias relacionadas expandem ainda mais essa dungeon.

Mas Mitsuha ensinou algo que nenhuma tabela comparativa consegue ensinar:

Antes de escolher o protocolo, descubra a natureza da conversa.

Pergunte:

Quem fala?

Quem escuta?

Quem começa?

Precisa responder?

Precisa esperar?

Pode repetir?

Pode perder?

Precisa preservar ordem?

O receptor pode estar offline?

Quantos participantes existem?

Como descubro que falhou?

Como recupero?

Como provo o que aconteceu?

Quando um programador começa a fazer essas perguntas, alguma coisa muda.

Ele deixa de pensar somente:

COMO IMPLEMENTO ESTA API?

e começa a perguntar:

COMO ESTE SISTEMA DEVE SE COMPORTAR?

Essa é uma mudança gigantesca.

É a passagem da programação para a engenharia de sistemas.

E talvez seja justamente por isso que um programador COBOL possui uma vantagem inesperada nessa aventura.

Ele vem de um universo no qual palavras como:

transação
commit
rollback
fila
batch
online
integridade
recuperação
auditoria
disponibilidade

nunca foram apenas buzzwords.

Quando um pagamento envolve dinheiro verdadeiro, não basta desenhar uma seta bonita entre dois quadradinhos num PowerPoint.

A transação precisa chegar.

Precisa ser processada corretamente.

Precisa sobreviver a falhas.

Precisa poder ser investigada.

E, às 03:17 da madrugada, alguém precisa conseguir descobrir exatamente o que aconteceu.

Mitsuha fecha o mapa dos sete portais, guarda algumas moedas e olha para nosso Padawan COBOL:

— Então, qual é o melhor protocolo?

Ele finalmente aprendeu.

— Depende da conversa que os sistemas precisam ter.

Mitsuha sorri.

A primeira dungeon estava concluída.

A próxima porta tinha uma placa ainda mais assustadora:

                 EVENT-DRIVEN ARCHITECTURE

                          |
             +------------+------------+
             |                         |
          IBM MQ                     Kafka
             |                         |
       Queues / Topics            Event Streams
             |                         |
             +------------+------------+
                          |
                    COBOL PROGRAM

E alguém havia escrito em letras pequenas no canto:

ATENÇÃO:

“EXACTLY ONCE”
PODE CONTER MAGIA,
MARKETING
E MUITAS LETRAS MIÚDAS.

Mitsuha pegou novamente sua calculadora.

O COBOLzeiro preparou outro café.

E os dois entraram.

🩸「Maou 77」– O Rei Demônio que Nasceu dos Códigos e dos Caos da Cultura Japonesa

 

🩸「Maou 77」– O Rei Demônio que Nasceu dos Códigos e dos Caos da Cultura Japonesa

(Um mergulho noturno por Bellacosa Mainframe, direto do blog El Jefe Midnight Lunch)

Era madrugada — claro, sempre é — quando esbarrei na expressão “Maou 77” navegando pelos confins da internet japonesa. E, como toda boa criatura noturna, fui atrás do rastro.
“Maou” (魔王) — o Rei Demônio — é uma das palavras mais fascinantes do idioma nipônico. Evoca medo, respeito e até... simpatia. Já o “77”? Aí mora a mística: sete é número espiritual, de sorte, mas duplicado vira ironia, sorte em dobro ou azar dobrado. No Japão, esse tipo de simbolismo numérico sempre carrega uma camada de filosofia disfarçada em superstição.

---

👹 A origem de “Maou”

O termo vem do budismo, onde Maou (魔王) era o senhor das tentações, aquele que tentou desviar Buda de alcançar a iluminação. No folclore japonês, ele se mistura a oni, demônios e divindades travessas.
Com o tempo, o Maou ganhou um novo status: o anti-herói dos tempos modernos.
Nos games e animes, ele não é mais apenas o vilão final — é o chefe que carrega traumas, dilemas existenciais e, muitas vezes, um coração cansado de lutar contra heróis que nem sabem o que é o bem.

---

⚔️ E o “77”?

“77” aparece em fóruns, nicknames, usernames e até títulos de fanfics e games indies japoneses, onde Maou 77 virou um símbolo meio underground: um “Rei Demônio moderno”, digital, glitchado, que reina sobre servidores, códigos e sistemas.
Nos bastidores, o número 77 também é usado por otakus como código para “dupla perfeição”, já que “7” é o número da plenitude. Assim, Maou 77 é o “vilão perfeito”, aquele que sabe que é vilão — e, mesmo assim, continua.

Há quem diga que nasceu em uma thread anônima do 2channel nos anos 2000, quando um usuário com o nick “Maou77” ficou famoso por comentários filosóficos e sarcásticos sobre a vida moderna e a hipocrisia da sociedade japonesa.
Outros acreditam que é um easter egg em alguns jogos RPG Maker da época, onde o vilão “Maou77” aparecia como um chefe secreto.
Nada confirmado — e é exatamente isso que mantém o mito vivo.

---

💫 Curiosidades de bastidor

• Nos círculos de fandom, “Maou77” é citado em memes como o “rei do caos digital”, símbolo dos otakus que viraram adultos mas continuam governando suas pequenas reinos geek.

• Há quem diga que o número 77 faz referência à versão 7.7 de um jogo que nunca existiu — uma ironia com os updates infinitos dos MMOs japoneses.

• Em fóruns de animes, “Maou77” também é usado como apelido para personagens tipo Overlord, Satan (Blue Exorcist), ou até Anos Voldigoad (The Misfit of Demon King Academy).

• Em algumas fanarts, Maou77 aparece com uma estética cyberpunk, um rei demônio que governa o submundo digital — o Mainframe infernal.

---

💬 Quem já falou sobre isso?

• Anos Voldigoad (do anime Maou Gakuin no Futekigousha) seria a representação mais moderna do conceito “Maou77”: poderoso, consciente do próprio mito e levemente debochado.

• Overlord (Ainz Ooal Gown) também carrega o espírito do “Rei Demônio perfeito” — um administrador de servidores que se torna governante de um novo mundo.

• Alguns críticos otaku em blogs japoneses independentes (como NicoBlog, Anibu.jp e YumeNet) mencionam “Maou77” como uma metáfora para o adulto nerd japonês que não se rendeu à monotonia corporativa.

• Há até vídeos no NicoNico Douga intitulados “Maou77 Reborn”, mesclando música techno e imagens de animes dark — um verdadeiro lore digital.

---

🕯️ Conclusão do Capitão Bellacosa

O Japão tem essa mania linda de transformar demônios em ídolos e ídolos em metáforas.
Maou77 é mais do que um personagem: é o retrato do homem (ou mulher) moderno que entende que o caos é inevitável — e escolhe governá-lo com estilo.
Um arquétipo hacker, um samurai digital, um Rei Demônio de silício e sono atrasado.

E talvez — só talvez — nós, criaturas da madrugada, sejamos todos um pouco Maou77:
lutando contra heróis inexistentes, rindo de nossas próprias falhas, e reinando, cada um, sobre o pequeno império que criamos entre cafés frios, ideias insanas e códigos que nunca compilam de primeira.

---

☕ Bellacosa Mainframe, direto do El Jefe Midnight Lunch.
"Porque até o Rei Demônio precisa de café às três da manhã."

---

Quer que eu escreva uma continuação com os “10 Maous mais icônicos dos animes” (tipo uma versão infernal do top shonen)? Isso renderia um post épico para a sequência.

蒸発者 (jōhatsu-sha) — Os “evaporados” do Japão

 Jōhatsu — Os “evaporados” do Japão

No Japão existe um termo curioso e sombrio: 蒸発者 (jōhatsu-sha), literalmente “a pessoa que evaporou”. A palavra vem de 蒸発 (jōhatsu), “evaporação” — o mesmo usado para a água que desaparece ao ferver. Mas aqui, ela se aplica a gente comum que decide sumir da própria vida.

🔹 Etimologia e contexto social
O verbo jōhatsu suru (蒸発する) significa “evaporar-se”. O Japão, com sua cultura que valoriza a honra e evita o confronto, criou um terreno fértil para o fenômeno: pessoas endividadas, envergonhadas ou em crise simplesmente desaparecem, cortando vínculos e recomeçando em silêncio.
A “fuga noturna” (夜逃げ — yonige) é parte dessa prática: famílias que saem de casa à noite para escapar de cobradores, divórcios ou empregos opressores. Existem até “yonige-ya”, agências que ajudam a desaparecer discretamente — empacotam seus pertences, transportam e te instalam em outra cidade sem deixar rastros.

🔹 Curiosidades históricas
O auge dos jōhatsu aconteceu entre as décadas de 1960 e 1990, com o crescimento urbano e o peso da cultura corporativa. Até hoje, há bairros inteiros em Tóquio e Osaka conhecidos por abrigar pessoas que “recomeçaram” — como Sanya ou Kamagasaki.
Embora desaparecer pareça extremo, muitos o fazem não por covardia, mas como um ato desesperado de liberdade em uma sociedade de expectativas sufocantes.

🔹 Na cultura pop e animes
Esse tema ecoa em várias obras japonesas. Em Tokyo Godfathers (2003), vemos pessoas marginalizadas tentando reconstruir suas vidas nas sombras. Em Erased (Boku dake ga Inai Machi), a sensação de desaparecer e recomeçar é simbólica — um salto entre realidades e arrependimentos. Já em Paranoia Agent, Satoshi Kon mostra como o peso da vergonha pode levar à fuga literal ou psicológica.

🔹 Reflexão e dica pessoal
O conceito de jōhatsu é um espelho social: fala sobre pressão, culpa e reinvenção. Mas também é um lembrete de que recomeçar não precisa significar desaparecer. Às vezes, basta se permitir mudar de ambiente, de ritmo ou de identidade — sem sumir do mapa.

No fim, todos nós “evaporamos” um pouco ao longo da vida — deixando versões antigas de nós mesmos para trás.
Mas diferente dos jōhatsu, voltamos.

#Bellacosa #CulturaJaponesa #Jōhatsu #Yonige #CuriosidadesJapão

Yashahime: The Second Act : Quando um Programador COBOL Descobre que a Modernização Não Termina no Primeiro Deploy...

 

Bellacosa Mainframe apresenta yashahim the second act

☕ Um Café no Bellacosa Mainframe

Yashahime: The Second Act (半妖の夜叉姫 弐の章) sem Mistérios

Quando um Programador COBOL Descobre que a Modernização Não Termina no Primeiro Deploy... Ela Continua Até que a Nova Equipe Consiga Manter o Sistema Sozinha

"Todo projeto de modernização possui duas fases. A primeira é colocar o sistema para funcionar. A segunda, muito mais difícil, é garantir que a nova geração consiga operá-lo sem depender eternamente dos arquitetos originais. Yashahime: The Second Act é exatamente essa segunda fase."

---

Introdução

Após uma primeira temporada que dividiu opiniões, Yashahime: The Second Act chegou em 2021 com uma missão clara:

Responder às perguntas deixadas em aberto.

Expandir o passado de Sesshomaru.

Explicar o destino de Inuyasha e Kagome.

Concluir a história das três protagonistas.

O resultado foi uma temporada muito mais focada.

Mais emocional.

Mais consistente.

E muito melhor recebida pelos fãs.

Para muitos, esta segunda temporada finalmente entregou aquilo que esperavam desde o anúncio da continuação.

---

Dados Técnicos

Título Original

半妖の夜叉姫 弐の章

Han'yō no Yashahime: Ni no Shō

Tradução aproximada:

Princesas Meio-Yokai – Segundo Capítulo

Título internacional:

Yashahime: Princess Half-Demon – The Second Act

---

Universo Original

Criado por

Rumiko Takahashi

Participação:

• design dos personagens

• supervisão visual

• conceitos gerais

---

Estúdio

Sunrise

(atualmente Bandai Namco Film Works)

---

Diretor

Teruo Sato

---

Roteiro

Katsuyuki Sumisawa

---

Exibição

02 de outubro de 2021

até

26 de março de 2022

---

Episódios

24

---

Gênero

• Fantasia

• Ação

• Aventura

• Drama

• Sobrenatural

• Mitologia Japonesa

• Shōnen

---

Classificação

14 anos

Contém:

• batalhas

• violência moderada

• sangue leve

• drama familiar

• perdas

• conflitos emocionais

---

Sinopse

Depois de inúmeros confrontos...

Towa...

Setsuna...

e Moroha...

aproximam-se da verdade.

Agora precisam compreender:

o plano de Sesshomaru

o verdadeiro objetivo de Kirinmaru

a ligação entre Zero e o destino das famílias.

Enquanto isso...

novas ameaças colocam em risco tanto o Japão Feudal quanto o mundo moderno.

---

Resumo

A temporada concentra-se em:

• recuperar memórias

• unir famílias

• derrotar Kirinmaru

• compreender Zero

• concluir a jornada iniciada na primeira temporada

É praticamente um grande arco final.

---

A História

Grande parte dos mistérios deixados pela primeira temporada finalmente recebe explicações.

Descobrimos:

por que Sesshomaru tomou determinadas decisões.

Como Inuyasha e Kagome sobreviveram.

Qual o verdadeiro significado da Árvore das Eras.

Como Kirinmaru interpretou a antiga profecia.

As batalhas tornam-se muito maiores.

O desenvolvimento emocional também.

---

Os Personagens

Towa

Agora assume definitivamente o papel de protagonista.

Aprende que força também exige responsabilidade.

---

Setsuna

Sua recuperação emocional é um dos pontos altos.

Finalmente compreende sua própria identidade.

---

Moroha

Continua sendo o coração da equipe.

Mistura humor.

Coragem.

Espontaneidade.

---

Sesshomaru

Talvez receba aqui seu maior desenvolvimento desde The Final Act.

Boa parte de suas atitudes finalmente faz sentido.

---

Kirinmaru

Deixa de ser apenas um grande guerreiro.

Mostra enorme complexidade.

Seu medo do futuro conduz muitas de suas escolhas.

---

Zero

Recebe um dos encerramentos mais emocionantes da temporada.

Mostra que ressentimento pode destruir séculos de felicidade.

---

Inuyasha

Mesmo aparecendo menos do que muitos fãs gostariam, continua sendo peça importante para o desfecho da história.

---

Kagome

Mantém seu papel como elo entre gerações e símbolo de esperança.

---

O Que Tem de Diferente?

A primeira temporada apresentava muitos mistérios.

A segunda responde praticamente todos.

Também há muito mais participação dos personagens clássicos, especialmente Sesshomaru, Inuyasha e Kagome, fortalecendo a conexão entre a nova geração e o legado original.

---

Temáticas

Família

Proteção exige escolhas difíceis.

---

Herança

Os filhos não precisam repetir os erros dos pais.

---

Destino

Pode ser mudado.

---

Perdão

Liberta mais do que a vingança.

---

Memória

Mesmo esquecida...

continua moldando quem somos.

---

Crescimento

A nova geração finalmente encontra seu próprio caminho.

---

Aventuras

As protagonistas enfrentam Kirinmaru em confrontos decisivos, exploram os mistérios da Árvore das Eras, recuperam lembranças perdidas e atravessam diferentes épocas para impedir que a profecia destrua o equilíbrio entre os mundos.

Ao longo dessa jornada, reencontros aguardados pelos fãs reforçam o vínculo entre pais e filhos e encerram conflitos iniciados ainda na série original.

---

Mensagens Ocultas

Pais Também Erram

Mesmo tentando proteger os filhos.

---

O Futuro Nunca Deve Ser Temer

Ele deve ser construído.

---

O Passado Explica

Mas não determina.

---

O Conhecimento Precisa Ser Compartilhado

Senão desaparece.

---

A Nova Geração Deve Superar

E não apenas copiar.

---

Impacto Cultural

A segunda temporada foi recebida de forma mais positiva que a primeira.

Os fãs elogiaram:

• explicações para mistérios importantes;

• maior presença dos personagens clássicos;

• evolução de Sesshomaru;

• encerramento da história principal;

• qualidade da animação nas batalhas finais.

Ainda assim, parte do público considerou que alguns conflitos poderiam ter recebido mais episódios para um desenvolvimento ainda mais profundo.

---

Censura

Assim como a primeira temporada, The Second Act praticamente não sofreu alterações relevantes fora do Japão.

Os ajustes limitaram-se à classificação indicativa e a pequenas reduções de sangue em algumas transmissões televisivas.

---

Mangás

O mangá de Yashahime, ilustrado por Takashi Shiina, continua adaptando e expandindo a história, acrescentando cenas inéditas e desenvolvendo personagens com maior profundidade do que o anime em diversos momentos.

---

Light Novels

Até o momento, não existe uma continuação oficial em formato de light novel para os acontecimentos após The Second Act.

---

Games

Os personagens da segunda temporada apareceram em:

• eventos especiais da franquia;

• jogos mobile japoneses;

• colaborações promocionais.

Não foi lançado um RPG exclusivo baseado nessa fase da história.

---

Curiosidades

• Muitos dos episódios finais foram elogiados por resolver mistérios que vinham sendo discutidos pelos fãs desde 2020.

• A trilha sonora de Kaoru Wada voltou a utilizar temas clássicos de Inuyasha em momentos decisivos, reforçando o sentimento de continuidade.

• O mangá de Takashi Shiina apresenta diferenças importantes em relação ao anime e é frequentemente recomendado para quem deseja uma versão mais detalhada da narrativa.

---

Easter Eggs

• O reencontro entre personagens clássicos simboliza a passagem definitiva do bastão para a nova geração.

• A Árvore das Eras continua funcionando como uma metáfora para a ligação entre memória, tempo e destino.

• Sesshomaru mantém sua postura reservada até o fim, preservando a coerência de sua evolução iniciada décadas antes.

---

Avaliação Bellacosa Mainframe

Aspecto	Nota
História	⭐⭐⭐⭐☆ (4,5/5)
Desenvolvimento dos Personagens	⭐⭐⭐⭐⭐ (5/5)
Ação	⭐⭐⭐⭐☆ (4,5/5)
Emoção	⭐⭐⭐⭐⭐ (5/5)
Trilha Sonora	⭐⭐⭐⭐⭐ (5/5)
Encerramento	⭐⭐⭐⭐☆ (4,5/5)
Reassistir	⭐⭐⭐⭐☆ (4,5/5)

Nota Final: 9,3/10

A segunda temporada consegue fortalecer a proposta de Yashahime, aproximando a nova geração do legado de Inuyasha e oferecendo um encerramento satisfatório para a maioria dos arcos apresentados.

---

☕ Bellacosa Mainframe

Imagine um grande projeto de modernização de um ambiente IBM Z.

Na primeira fase, a equipe migra aplicações, cria pipelines de CI/CD, integra APIs e documenta processos.

Mas o verdadeiro teste começa depois do deploy.

A nova equipe precisa operar o sistema sem depender diariamente dos arquitetos veteranos.

Towa representa a desenvolvedora que finalmente domina tanto as tecnologias modernas quanto o ambiente legado.

Setsuna simboliza a especialista operacional que recupera o contexto perdido e transforma experiência em conhecimento compartilhado.

Moroha é a analista criativa que une tradição e inovação para resolver problemas inesperados.

Sesshomaru assume o papel do arquiteto sênior que observa à distância, intervindo apenas quando realmente necessário, permitindo que a nova geração conquiste sua autonomia.

No fim, Yashahime: The Second Act transmite uma lição que todo profissional de tecnologia aprende cedo ou tarde: um projeto de modernização só pode ser considerado concluído quando o conhecimento deixa de estar preso a uma única pessoa e passa a fazer parte da cultura da equipe. O legado mais valioso nunca foi o código. Sempre foi a capacidade de ensinar outros a compreendê-lo e evoluí-lo.

SECTION e PARAGRAPH no COBOL sem Mistérios

 

Bellacosa Mainframe e a section e paragraph no cobol

☕ Um Café no Bellacosa Mainframe

SECTION e PARAGRAPH no COBOL sem Mistérios

Como um Programador COBOL Padawan Aprende a Organizar seu Código como um Oficial da Frota Estelar

"A diferença entre um programa que apenas funciona e um programa que sobrevive por décadas está na sua organização."

---

Introdução — A Primeira Missão do Padawan COBOL

Imagine que você acaba de chegar à USS Enterprise.

O Capitão pede para localizar um problema em um sistema de navegação criado há 35 anos.

Você abre o código.

São 18.000 linhas de COBOL.

Não existe um comentário.

Não existe uma SECTION.

Não existe um PERFORM.

Apenas um gigantesco fluxo de GO TO.

Você pensa:

"Quem escreveu isso?"

A resposta normalmente é:

"Alguém extremamente inteligente...
...
...
em 1984."

Bem-vindo ao mundo real do Mainframe.

Uma das primeiras lições que um programador COBOL aprende é que escrever código é relativamente fácil.

O difícil é escrever código que outra pessoa consiga entender vinte anos depois.

É exatamente aí que entram os conceitos de PARAGRAPH e SECTION.

Eles existem desde os primórdios da linguagem e continuam presentes até hoje, mesmo em programas escritos para IBM z17, COBOL 6.5 e aplicações modernas integradas com APIs REST.

E curiosamente, muita gente usa os dois sem realmente entender por que eles existem.

Hoje vamos viajar até a origem desse conceito.

---

A origem histórica

Para entender SECTION precisamos voltar aos anos 60.

Naquela época:

• memória custava uma fortuna;

• CPU era extremamente cara;

• cartões perfurados eram comuns;

• manutenção era muito mais importante que desenvolvimento.

A equipe que criou o COBOL queria que programas fossem parecidos com documentos administrativos.

Por isso surgiram divisões naturais:

IDENTIFICATION DIVISION

ENVIRONMENT DIVISION

DATA DIVISION

PROCEDURE DIVISION

Mas logo perceberam um problema.

A PROCEDURE DIVISION podia crescer para milhares de linhas.

Era necessário organizá-la.

Assim nasceram:

• Paragraphs

• Sections

Inspirados em capítulos e subtítulos de documentos.

Ou seja:

Documento

↓

Capítulo

↓

Subcapítulo

↓

Parágrafo

Exatamente como um livro.

---

O que é um Paragraph?

Um paragraph é simplesmente um bloco de instruções identificado por um nome.

Exemplo:

CALCULA-TOTAL.

    ADD VALOR TO TOTAL.

    COMPUTE IMPOSTO = TOTAL * 0.15.

    EXIT.

O nome termina com ponto.

Depois vêm os comandos.

---

Pode ser chamado assim:

PERFORM CALCULA-TOTAL

Muito simples.

---

O que é uma SECTION?

Uma SECTION é um agrupador de paragraphs.

Exemplo

CALCULO SECTION.

CALCULA-TOTAL.

...

CALCULA-IMPOSTO.

...

VALIDACOES SECTION.

VALIDA-CPF.

...

VALIDA-DATA.

...

Ou seja

Section

↓

Paragraph

↓

Comandos

---

É uma organização hierárquica.

---

Visualizando

PROCEDURE DIVISION

MAIN SECTION

   INICIO

   PROCESSA

   FINALIZA

LEITURA SECTION

   LE-DADOS

   LE-CLIENTE

CALCULOS SECTION

   SOMA

   DESCONTO

GRAVACAO SECTION

   ESCREVE

É praticamente uma árvore.

---

Por que isso foi criado?

Porque programas COBOL começaram a ficar enormes.

Muito antes da orientação a objetos.

Muito antes de módulos.

Muito antes de classes.

A SECTION funcionava como um "módulo lógico".

---

Como funciona internamente?

Quando fazemos

PERFORM CALCULA-TOTAL

O runtime:

guarda o endereço atual

↓

salta

↓

executa

↓

volta

Semelhante a uma chamada de função.

---

Quando fazemos

PERFORM CALCULO

e CALCULO é uma SECTION...

Ele executa TODOS os paragraphs daquela section.

Exemplo

CALCULO SECTION.

SOMA.

...

IMPOSTO.

...

DESCONTO.

Resultado

SOMA

↓

IMPOSTO

↓

DESCONTO

Tudo automaticamente.

---

Este detalhe pega muitos iniciantes

Imagine

VALIDACAO SECTION.

VALIDA-A.

...

VALIDA-B.

...

VALIDA-C.

...

Se fizer

PERFORM VALIDACAO

Executará

A

↓

B

↓

C

Mesmo que você só queira A.

---

Então por que existem paragraphs?

Porque podemos chamar apenas um deles.

PERFORM VALIDA-B

Executa somente aquele.

---

O famoso EXIT

Quase todo mundo vê isso

EXIT.

e pensa

"isso encerra o paragraph."

Na verdade...

Não exatamente.

EXIT é praticamente um "não faça nada".

Uma instrução nula.

Ela existe para marcar explicitamente um ponto de saída.

---

Exemplo

CALCULA.

   ADD 1 TO TOTAL.

   EXIT.

O runtime simplesmente passa por ela.

---

Então por que usar?

Porque melhora a legibilidade.

Especialmente quando existem PERFORM THRU.

---

EXIT SECTION

Existe também

EXIT SECTION

Muito mais moderno.

Ele encerra imediatamente a section.

---

EXIT PARAGRAPH

Também existe.

EXIT PARAGRAPH

Ele retorna imediatamente daquele paragraph.

Muito mais claro.

---

Antigamente

Antes dessas instruções modernas era comum encontrar

GO TO FIM-ROTINA.

Hoje isso é considerado má prática.

---

GO TO versus PERFORM

Imagine

A

↓

GO TO C

↓

B

↓

GO TO D

↓

C

↓

GO TO A

Parece um prato de espaguete.

Daí surgiu o termo

Spaghetti Code.

---

PERFORM resolveu boa parte desse problema.

---

Curiosidade

Nos anos 70 havia programas COBOL com mais de:

300 paragraphs

100 sections

40 mil linhas

E muitos ainda funcionam hoje.

---

Performance

Uma pergunta muito comum.

"Section é mais lenta?"

Resposta:

Praticamente não.

O compilador moderno otimiza quase tudo.

A diferença costuma ser insignificante.

---

Onde realmente existe custo?

PERFORM

↓

retorno

↓

pilha

↓

controle

Mas isso é extremamente pequeno.

---

Na prática

Legibilidade vale infinitamente mais.

---

PERFORM THRU

Exemplo

PERFORM A THRU C

Executa

A

↓

B

↓

C

Muito usado antigamente.

Hoje muitos times evitam.

---

Por quê?

Porque se alguém inserir

B2

no meio...

O comportamento muda.

Sem ninguém perceber.

---

Truque interessante

Sections permitem criar fases.

INICIALIZACAO

PROCESSAMENTO

RELATORIOS

FINALIZACAO

Cada uma possui seus próprios paragraphs.

Muito organizado.

---

Outro truque

Usar prefixos.

1000-INICIO

1100-LE-DADOS

1200-PROCESSA

1300-GRAVA

9000-FIM

Muito comum em bancos.

---

Por quê?

Porque facilita localizar no editor.

---

Outro padrão clássico

A000

A100

A200

B000

B100

Também extremamente comum.

---

Cuidados

Nunca misture assuntos.

Ruim

CLIENTE

↓

GRAVA ARQUIVO

↓

FAZ SQL

↓

ENVIA MQ

↓

CALCULA IMPOSTO

Bom

CLIENTE SECTION

↓

DB2 SECTION

↓

MQ SECTION

↓

CALCULO SECTION

---

Outro cuidado

Não faça Sections gigantes.

Ruim

PROCESSA SECTION

3500 linhas

Bom

LEITURA

VALIDACAO

NEGOCIO

DB2

LOG

MQ

FINAL

---

Quantos paragraphs?

Não existe regra.

Mas normalmente:

5

10

20

é confortável.

---

Deve existir apenas uma MAIN?

Quase sempre sim.

Exemplo

MAIN.

PERFORM INICIALIZA

PERFORM PROCESSA

PERFORM FINALIZA

STOP RUN

A leitura fica excelente.

---

Curiosidade histórica

Muitos compiladores antigos geravam código praticamente na mesma ordem dos paragraphs.

Hoje isso mudou completamente.

O compilador reorganiza diversas instruções.

---

O compilador pode ignorar Sections?

Em muitos casos sim.

Principalmente quando faz otimizações.

Ele pode inline routines.

Eliminar saltos.

Fundir blocos.

---

O que IBM recomenda?

Hoje a IBM incentiva:

✔ PERFORM

✔ EXIT PARAGRAPH

✔ EXIT SECTION

✔ evitar GO TO

✔ evitar ALTER

✔ modularização

✔ nomes claros

---

Um exemplo elegante

PROCEDURE DIVISION.

MAIN.

    PERFORM INICIALIZA

    PERFORM PROCESSA-PEDIDOS

    PERFORM GERA-RELATORIO

    PERFORM FINALIZA

    GOBACK.

Depois

PROCESSA-PEDIDOS SECTION.

LE-DADOS.

VALIDA-DADOS.

ATUALIZA-DB2.

ENVIA-MQ.

EXIT.

A leitura fica praticamente uma documentação.

---

Quando NÃO usar Sections?

Existem equipes modernas que preferem apenas paragraphs.

Por quê?

Porque:

PERFORM paragraph

é suficiente.

Especialmente em programas pequenos.

---

Quando usar Sections?

Em sistemas grandes.

Com dezenas de módulos lógicos.

Principalmente:

• Bancos

• Seguradoras

• Governo

• Telecom

• ERP

---

Easter Egg Mainframe ☕

Existe uma brincadeira antiga entre programadores veteranos.

Se um programa possui:

• GO TO para todos os lados

• ALTER

• PERFORM THRU cruzando o programa inteiro

• sem SECTION

• sem comentários

ele recebe um apelido carinhoso:

"Programa Teletransporte."

Você nunca sabe exatamente onde está.

Assim como um oficial preso em um teletransporte defeituoso da Frota Estelar.

---

Analogia com a USS Enterprise

Imagine a Enterprise.

Ela possui setores.

Engenharia

Ponte

Enfermaria

Hangar

Laboratórios

Cada setor possui equipes.

Na Engenharia:

Reator

Motores

Dilithium

Warp

Isso é exatamente uma SECTION contendo diversos PARAGRAPHS.

Ninguém colocaria o controle do motor Warp dentro da enfermaria.

Da mesma forma, um programa COBOL bem projetado separa responsabilidades em áreas distintas, facilitando a manutenção e reduzindo o risco de alterações acidentais.

---

Boas práticas para o Padawan COBOL

Ao longo de décadas de evolução do COBOL, algumas práticas se mostraram consistentes em equipes de alta maturidade:

• Mantenha uma MAIN pequena, que apenas orquestre o fluxo principal.

• Agrupe rotinas relacionadas em SECTIONs com responsabilidade única.

• Dê nomes descritivos aos PARAGRAPHs, usando verbos que indiquem claramente sua função, como VALIDA-CLIENTE, CALCULA-TOTAL ou GRAVA-HISTORICO.

• Prefira PERFORM a GO TO para manter o fluxo previsível.

• Utilize EXIT PARAGRAPH e EXIT SECTION quando desejar uma saída explícita e fácil de entender.

• Evite PERFORM THRU em novos desenvolvimentos, pois pequenas alterações podem modificar o comportamento sem chamar atenção.

• Procure manter cada paragraph relativamente curto. Se ele começa a fazer muitas coisas diferentes, provavelmente merece ser dividido.

• Separe regras de negócio, acesso a banco, manipulação de arquivos e integração com outros sistemas em blocos distintos.

• Comente o motivo das decisões mais complexas, e não apenas o que o código faz.

---

Pontos para Fixar

✔ Paragraph é uma rotina identificada por um nome.

✔ Section é um agrupamento de paragraphs relacionados.

✔ PERFORM paragraph executa apenas aquele bloco.

✔ PERFORM section executa todos os paragraphs pertencentes àquela section, em sequência.

✔ EXIT. é uma instrução nula usada tradicionalmente como marcador de fim.

✔ EXIT PARAGRAPH e EXIT SECTION tornam o fluxo de saída mais explícito e legível.

✔ O ganho de organização quase sempre supera qualquer preocupação com desempenho.

✔ O compilador Enterprise COBOL moderno realiza diversas otimizações, tornando diferenças de performance entre uma boa organização em sections e paragraphs praticamente irrelevantes na maioria das aplicações.

✔ Código legível reduz tempo de manutenção, facilita revisões e diminui a probabilidade de defeitos em sistemas que frequentemente permanecem em produção por décadas.

---

Conclusão — Organizando a Ponte de Comando

No universo de Jornada nas Estrelas, a USS Enterprise não funciona porque possui apenas motores potentes. Ela funciona porque cada setor conhece sua responsabilidade, cada oficial sabe quando agir e a cadeia de comando é clara.

Um programa COBOL de qualidade segue exatamente essa filosofia.

As SECTIONs representam os grandes departamentos da nave. Os PARAGRAPHs são as equipes especializadas que executam cada missão. O PERFORM atua como a ordem do capitão, chamando apenas a rotina necessária no momento certo. Já o EXIT PARAGRAPH e o EXIT SECTION funcionam como um retorno organizado ao posto de comando, sem desvios inesperados.

Muitos sistemas críticos escritos há mais de quarenta anos continuam processando milhões de transações diárias justamente porque foram estruturados com disciplina. A tecnologia evoluiu, o compilador ficou mais inteligente, surgiram otimizações, integração com APIs, DevOps e inteligência artificial, mas um princípio permaneceu praticamente inalterado desde o nascimento do COBOL: um código bem organizado é um código que atravessa gerações.

Como diria o Sr. Spock, adaptando sua lógica ao mundo do IBM Z:

"A elegância de um programa não está na quantidade de instruções, mas na clareza com que cada uma cumpre seu propósito."

E esse talvez seja o maior aprendizado para todo Programador COBOL Padawan: escrever para o computador é fácil; escrever para os próximos cinquenta anos de manutenção é a verdadeira arte do Mainframe.

Shūmatsu no Hāremu (終末のハーレム / World's End Harem)

 

Bellacosa Mainframe apresenta shumatsu no haremu

☕ Um Café no Bellacosa Mainframe

Shūmatsu no Hāremu (終末のハーレム / World's End Harem)

Quando um Programador COBOL Descobre que a Continuidade do Sistema Depende de Apenas Cinco Recursos Críticos

---

Dados da Obra

• Título original: 終末のハーレム (Shūmatsu no Hāremu)

• Título internacional: World's End Harem

• Autor (roteiro): LINK

• Ilustrador: Kotaro Shōno

• Mangá: 8 de maio de 2016

• Anime: estreia em 8 de outubro de 2021, com os episódios seguintes adiados e reestreia completa em 7 de janeiro de 2022, encerrando em 18 de março de 2022. (Wikipedia)

• Estúdios: Studio Gokumi × AXsiZ

• Diretor: Yuu Nobuta

• Roteiro: Tatsuya Takahashi

• Episódios: 11

• Duração: cerca de 24 minutos por episódio

• Gênero: Ficção científica, suspense, drama, romance, ecchi, harém, mistério. (Wikipedia)

---

Sinopse

Em 2040, um vírus chamado MK (Male Killer) extermina aproximadamente 99,9% da população masculina mundial.

Cinco homens sobrevivem graças à criogenia.

Ao despertar cinco anos depois, Reito Mizuhara descobre um planeta governado quase exclusivamente por mulheres.

Agora ele possui duas escolhas:

• participar do programa de reprodução da humanidade;

• descobrir quem criou o vírus e encontrar sua amada Erisa.

A partir daí, começa uma conspiração mundial muito maior do que aparenta. (Wikipedia)

---

Resumo

À primeira vista, parece apenas um anime de fanservice.

Na prática, é um thriller de ficção científica.

A narrativa mistura:

• pandemia;

• manipulação genética;

• conspirações internacionais;

• controle populacional;

• ética científica;

• biopolítica.

O ecchi funciona como consequência da premissa, não como único objetivo da história.

---

História

Após o desaparecimento quase completo dos homens, surge uma nova ordem mundial administrada pela organização UW (United Women).

Ela controla:

• governos;

• pesquisas;

• informações;

• sobreviventes;

• reprodução humana.

Os cinco sobreviventes recebem o título de Numbers, homens naturalmente imunes ao vírus.

Cada um reage de maneira diferente ao novo mundo.

Enquanto alguns aceitam os privilégios oferecidos, Reito desconfia que existe algo profundamente errado.

Sua investigação revela uma conspiração envolvendo poder, ciência e manipulação da própria evolução humana.

---

Principais Personagens

Reito Mizuhara

O protagonista.

Estudante de medicina.

Representa ética, racionalidade e curiosidade científica.

Recusa-se inicialmente a cumprir seu papel reprodutivo porque continua apaixonado por Erisa.

---

Mira Suou

Assistente oficial designada para acompanhar Reito.

Inicialmente parece apenas uma funcionária da UW.

Com o passar da história demonstra grande evolução emocional.

---

Erisa Tachibana

Namorada de infância de Reito.

Seu desaparecimento impulsiona toda a investigação.

É uma das maiores peças do mistério.

---

Shota Doi

Talvez o personagem mais interessante psicologicamente.

Antes era vítima de bullying.

Depois torna-se um dos homens mais poderosos do planeta.

Mostra como poder absoluto pode transformar completamente uma pessoa.

---

Reito Kuroda

Outro sobrevivente.

Segue um caminho completamente diferente do protagonista.

Serve para mostrar que pessoas distintas respondem de maneiras diferentes à mesma crise.

---

O que diferencia World's End Harem?

O diferencial não é o ecchi.

É a premissa.

Enquanto muitos animes harém utilizam situações escolares ou mágicas, Shūmatsu no Hāremu cria uma justificativa científica para todo o cenário.

Além disso, a obra aborda:

• engenharia genética;

• pandemias;

• propaganda estatal;

• experimentação humana;

• ética médica;

• manipulação da informação.

Tudo isso lembra bastante romances de ficção científica clássicos.

---

Temática

Os grandes temas incluem:

• sobrevivência da humanidade;

• liberdade individual;

• responsabilidade científica;

• ética da reprodução;

• abuso do poder;

• engenharia genética;

• desigualdade de informação;

• corrupção institucional;

• manipulação política.

---

Classificação

Faixa etária: +18

Motivos:

• nudez;

• erotismo;

• violência;

• conteúdo psicológico;

• temas adultos.

Apesar disso, existe uma narrativa consistente por trás do fanservice.

---

Aventuras

Durante a série encontramos:

• laboratórios secretos;

• organizações internacionais;

• espionagem;

• investigações científicas;

• perseguições;

• ataques biológicos;

• conspirações políticas;

• descobertas sobre o vírus MK.

Conforme a história avança, o romance perde espaço para o suspense.

---

Mensagens Ocultas

1. Recursos escassos mudam toda a arquitetura

No anime existem apenas cinco homens férteis.

No IBM Z acontece algo parecido.

Imagine um banco perder praticamente todos os especialistas COBOL.

Os poucos restantes tornam-se recursos estratégicos.

Toda a organização passa a depender deles.

---

2. Informação vale mais que força

Reito não vence por lutar.

Ele vence porque faz perguntas.

No mundo corporativo acontece exatamente o mesmo.

Quem entende o negócio possui vantagem muito maior que quem apenas conhece tecnologia.

---

3. A ética precisa acompanhar a inovação

A ciência cria possibilidades.

Mas quem decide como utilizá-las são pessoas.

O anime questiona constantemente:

"Até onde podemos ir para garantir a sobrevivência da espécie?"

---

4. Sistemas fechados escondem riscos

A UW controla praticamente todas as informações.

Sem transparência, qualquer sistema pode ser manipulado.

É um excelente paralelo com governança de TI.

---

5. Nem toda crise é apenas uma crise

O vírus parece ser o problema.

Depois descobrimos que ele também se tornou instrumento político.

Grandes eventos frequentemente produzem novas estruturas de poder.

---

Bellacosa Mainframe

Imagine um banco mundial.

Uma falha elimina 99,9% dos programadores COBOL experientes.

Restam apenas cinco.

Esses cinco passam a decidir:

• continuidade operacional;

• modernização;

• recuperação de incidentes;

• conhecimento institucional.

É exatamente essa lógica de escassez extrema que move toda a narrativa de World's End Harem.

O verdadeiro protagonista não é o harém.

É a administração de um recurso crítico.

---

Studio Gokumi × AXsiZ

A animação apresenta:

Pontos fortes

• personagens visualmente bem desenhados;

• boa iluminação;

• excelente direção de arte;

• trilha sonora competente;

• atmosfera futurista.

Pontos fracos

• animação limitada em cenas de ação;

• ritmo irregular;

• adaptação acelerada;

• várias partes do mangá ficaram de fora.

Mesmo assim, a produção entrega uma ambientação convincente para um thriller de ficção científica. (Wikipedia)

---

Impacto Cultural

World's End Harem chamou atenção antes mesmo da estreia por sua premissa provocativa. Após a exibição antecipada do primeiro episódio em outubro de 2021, a produção foi adiada para janeiro de 2022 para revisão da qualidade, o que gerou intensa discussão entre fãs. A série também impulsionou debates sobre pandemia, bioética, liberdade individual e manipulação científica, especialmente em um período em que o mundo ainda vivia os reflexos da COVID-19. (Wikipedia)

---

Curiosidades

• O mangá começou em Shōnen Jump+ em 2016.

• A franquia ganhou derivados como World's End Harem: Fantasia, ambientado em um universo de fantasia medieval, e outras obras paralelas. (Wikipedia)

---

Veredito Bellacosa

Categoria	Nota
História	⭐⭐⭐⭐☆ (8,5)
Ficção Científica	⭐⭐⭐⭐⭐ (9,2)
Suspense	⭐⭐⭐⭐☆ (8,7)
Construção de Mundo	⭐⭐⭐⭐☆ (8,6)
Personagens	⭐⭐⭐⭐☆ (8,4)
Ecchi/Fanservice	⭐⭐⭐⭐⭐
Originalidade	⭐⭐⭐⭐⭐ (9,5)

Nota Final

⭐⭐⭐⭐☆ (8,8/10)

Shūmatsu no Hāremu costuma ser lembrado pelo fanservice, mas sua verdadeira força está na combinação de suspense, ficção científica e dilemas éticos. Para um leitor ou espectador disposto a olhar além da superfície, a obra levanta questões relevantes sobre poder, ciência, governança e o valor estratégico dos recursos mais escassos — uma metáfora que conversa surpreendentemente bem com o universo dos grandes sistemas corporativos e do IBM Mainframe.

ABEND sem Mistérios — Parte VIII

 

Bellacosa Mainframe e o abend sem misterios parte viii

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte VIII

Muito Além do ABEND

Como Pensam os Grandes Especialistas em Mainframe e Por Que Resolver Erros é Apenas uma Pequena Parte da Engenharia de Software no IBM Z

"O iniciante aprende a corrigir ABENDs. O especialista aprende a construir sistemas onde eles se tornam cada vez mais raros."

---

Introdução

Chegamos ao último capítulo desta jornada.

Ao longo desta série, percorremos praticamente todo o universo dos ABENDs no Mainframe.

Começamos compreendendo o significado da palavra ABEND e conhecendo os principais erros encontrados no COBOL, no JCL, no CICS e no z/OS.

Depois aprendemos a investigar mensagens do JES2, utilizar o SDSF, interpretar CEEDUMPs, analisar dumps, compreender o funcionamento da CPU IBM Z, conhecer registradores, PSW, TCB, RB, arquitetura do sistema operacional e até explorar como Inteligência Artificial e Observabilidade estão revolucionando a investigação de incidentes.

Também criamos laboratórios, reproduzimos erros, estudamos engenharia de confiabilidade e analisamos dezenas de práticas utilizadas pelos maiores bancos do mundo.

Mas existe uma pergunta que ainda precisa ser respondida.

Depois de dominar os ABENDs... o que realmente muda?

A resposta é simples.

Tudo.

Porque, na verdade, esta série nunca foi apenas sobre ABENDs.

Ela sempre foi sobre aprender a pensar.

---

O verdadeiro objetivo nunca foi decorar códigos

Existe uma armadilha muito comum entre iniciantes.

Depois de conhecer:

• S0C4

• S0C7

• S013

• S806

• SB37

• ASRA

alguns acreditam que aprenderam a resolver problemas.

Na realidade,

eles aprenderam apenas os sintomas.

O especialista faz outra pergunta.

"Por que esse sistema permitiu que esse problema chegasse até aqui?"

Essa pergunta muda completamente a forma de enxergar software.

---

O Mainframe nunca foi apenas COBOL

Existe outro equívoco bastante comum.

Muitos profissionais dizem:

"Eu sou programador COBOL."

Mas observemos uma execução típica.

Usuário

↓

Canal Digital

↓

API

↓

Load Balancer

↓

Firewall

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

Db2

↓

MQ

↓

Storage

↓

Discos

↓

IBM Z

Onde exatamente termina o COBOL?

A resposta é:

Ele nunca esteve sozinho.

O Mainframe sempre foi um ecossistema.

---

O Programador Padawan

No início da carreira,

a maior preocupação costuma ser:

"Meu programa compilou?"

Depois evolui para:

"Meu programa executou?"

Mais tarde:

"Meu programa funciona?"

O especialista vai além.

Ele pergunta:

"Meu programa continuará funcionando daqui a dez anos?"

Essa é a diferença entre escrever código e construir sistemas.

---

A evolução do pensamento técnico

Observe como um profissional amadurece.

Nível 1

Escreve código.

↓

Nível 2

Corrige erros.

↓

Nível 3

Investiga ABENDs.

↓

Nível 4

Entende arquitetura.

↓

Nível 5

Previne incidentes.

↓

Nível 6

Melhora processos.

↓

Nível 7

Ensina outras pessoas.

É nesse último estágio que nasce um verdadeiro especialista.

---

O valor da curiosidade

Existe uma característica comum entre praticamente todos os grandes profissionais de Mainframe.

Eles fazem perguntas.

Muitas perguntas.

Por exemplo.

Por que existe um PSW?

Por que o CICS funciona dessa maneira?

Como o Dispatcher escolhe a próxima tarefa?

Por que um dump possui milhares de páginas?

Como o WLM distribui CPU?

Como o Db2 gerencia locks?

Por que um S0C4 acontece exatamente naquele endereço?

A curiosidade é um acelerador de carreira.

---

Os profissionais mais respeitados não decoram comandos

Eles compreendem conceitos.

Imagine dois programadores.

O primeiro decorou:

DISPLAY

LISTCAT

IDCAMS

ALLOC

FREE

LISTDSI

O segundo entende:

• armazenamento;

• catálogo;

• datasets;

• buffers;

• VSAM;

• acesso sequencial;

• acesso direto.

Quem terá mais facilidade para aprender novas ferramentas?

Naturalmente o segundo.

Conceitos sobrevivem.

Comandos mudam.

---

O papel da documentação

Em muitas empresas,

resolver um incidente é apenas metade do trabalho.

A outra metade é responder:

Como documentar?

Como compartilhar?

Como evitar novamente?

Um incidente que não gera conhecimento provavelmente voltará a acontecer.

---

A importância da humildade técnica

Existe uma frase muito conhecida na Engenharia.

"Todo software suficientemente complexo possui comportamentos que seus próprios autores não conseguem explicar."

Isso vale para Mainframe.

Vale para Cloud.

Vale para Inteligência Artificial.

Ninguém sabe tudo.

Os melhores profissionais estudam continuamente.

---

O conhecimento coletivo

Os maiores bancos do mundo não dependem apenas de profissionais brilhantes.

Eles dependem de equipes.

Uma investigação normalmente envolve:

• Desenvolvimento;

• Operação;

• SysProg;

• DBA;

• Redes;

• Segurança;

• Middleware;

• Negócio.

Cada grupo observa o incidente por um ângulo diferente.

É essa diversidade que produz as melhores soluções.

---

O papel da IA

Existe muito entusiasmo em torno da Inteligência Artificial.

Ela realmente está mudando o desenvolvimento de software.

Hoje conseguimos:

• resumir dumps;

• explicar SQLCODEs;

• interpretar mensagens IEC;

• sugerir causas prováveis;

• gerar documentação;

• produzir testes.

Mas existe algo que continua exclusivamente humano.

Julgamento.

A IA trabalha com probabilidades.

O engenheiro trabalha com responsabilidade.

---

O especialista não procura culpados

Quando um incidente acontece,

existem duas culturas.

A primeira pergunta:

"Quem escreveu esse programa?"

A segunda pergunta:

"O que precisamos melhorar para que isso nunca mais aconteça?"

A primeira cria medo.

A segunda cria evolução.

As organizações mais maduras escolhem sempre a segunda.

---

A engenharia de software no IBM Z

Hoje um profissional Mainframe trabalha com muito mais do que COBOL.

Ele precisa compreender:

• APIs REST;

• JSON;

• Git;

• DevOps;

• Containers;

• OpenShift;

• z/OS Connect;

• MQ;

• Kafka;

• Observabilidade;

• Automação;

• Inteligência Artificial.

Curiosamente,

isso não diminuiu a importância do COBOL.

Pelo contrário.

Aumentou.

Porque agora ele conversa com praticamente todo o restante da empresa.

---

A cultura da melhoria contínua

Os melhores ambientes seguem um ciclo permanente.

Desenvolver

↓

Testar

↓

Implantar

↓

Monitorar

↓

Aprender

↓

Melhorar

↓

Automatizar

↓

Repetir

Perceba que nunca existe um "fim".

Sempre existe uma próxima evolução.

---

O Mainframe continua ensinando

Existe algo fascinante no IBM Z.

Mesmo profissionais com quarenta anos de experiência continuam aprendendo.

Sempre aparece:

• um novo recurso;

• uma nova arquitetura;

• um novo compilador;

• uma nova API;

• uma nova forma de integrar sistemas;

• uma nova ferramenta de observabilidade.

Essa evolução constante mantém o Mainframe extraordinariamente atual.

---

O legado que realmente importa

No final da carreira,

ninguém será lembrado apenas pelos programas que escreveu.

Será lembrado por:

• sistemas que ajudou a construir;

• incidentes que resolveu;

• pessoas que formou;

• conhecimento que compartilhou.

O código envelhece.

O conhecimento permanece.

---

O Bellacosa Mainframe

Quando comecei a compartilhar conhecimento sobre Mainframe,

o objetivo nunca foi apenas explicar comandos.

Sempre acreditei que tecnologia pode ser ensinada de maneira humana.

Com café.

Com histórias.

Com analogias.

Com curiosidade.

Com respeito por quem está começando.

Todo especialista já foi um Padawan.

E ninguém chega longe sozinho.

Se esta série ajudou você a compreender um pouco melhor o universo dos ABENDs, então ela já cumpriu sua missão.

---

O próximo passo do Programador Padawan

Depois desta série, minha sugestão é continuar explorando temas que complementam a investigação de incidentes:

• Enterprise COBOL 6.x e otimizações do compilador.

• JCL avançado e utilitários do z/OS.

• VSAM em profundidade.

• CICS Transaction Server.

• Db2 for z/OS.

• Language Environment.

• IPCS avançado.

• Fault Analyzer e Debug Tool.

• SMF e RMF.

• WLM e desempenho.

• z/OS Connect e APIs REST.

• Observabilidade no IBM Z.

• DevOps e Git para Mainframe.

• Inteligência Artificial aplicada ao desenvolvimento COBOL.

Cada um desses assuntos amplia sua capacidade de compreender por que um sistema funciona, por que falha e como pode evoluir.

---

Uma última reflexão

Existe uma frase muito conhecida entre os engenheiros aeronáuticos.

"Todo acidente é um relatório técnico esperando para ser escrito."

No Mainframe, podemos adaptar essa ideia.

"Todo ABEND é uma aula de Engenharia de Software esperando para ser compreendida."

Cada S0C7 ensina a validar dados.

Cada S0C4 ensina a respeitar a memória.

Cada S013 ensina que aplicações dependem do ambiente onde executam.

Cada ASRA lembra que uma transação faz parte de um sistema muito maior.

Cada U4038 mostra que uma mensagem nem sempre revela toda a verdade.

E cada investigação bem conduzida torna o profissional mais preparado para o próximo desafio.

---

Conclusão

Esta série não teve como objetivo transformar você em alguém capaz de decorar centenas de códigos de ABEND. Seu propósito foi muito maior: desenvolver uma forma de pensar.

Pensar de maneira sistêmica.

Pensar orientado por evidências.

Pensar em causas, não apenas em sintomas.

Pensar em prevenção antes da correção.

Pensar em qualidade antes da urgência.

Esse é o verdadeiro diferencial dos grandes especialistas em IBM Z.

Porque o melhor engenheiro Mainframe não é aquele que resolve o maior número de ABENDs.

É aquele que projeta sistemas, processos e equipes capazes de impedir que eles aconteçam.

E quando um dia eles inevitavelmente surgirem, saberá que cada incidente representa uma oportunidade de aprender, compartilhar conhecimento e tornar o próximo sistema ainda melhor do que o anterior.

Enquanto existir um IBM Z processando milhões de transações com segurança, sempre haverá espaço para profissionais curiosos, disciplinados e apaixonados por aprender. Afinal, no Mainframe, a tecnologia evolui continuamente — e nós evoluímos junto com ela.