Bellacosa Mainframe introduz o IBM RPA

💥 SEU COBOL NÃO É LEGADO — É OURO AUTOMATIZÁVEL: Como o IBM RPA Transforma Mainframe em Máquina de Produtividade

Se você é um dev COBOL raiz, daqueles que já domou JCL, sobreviveu a dumps indecifráveis e conversa com o CICS como quem pede café… então segura essa: RPA não é modinha de mercado — é multiplicador de mainframe.

E quando falamos de RPA corporativo de verdade, estamos falando de IBM — que resolveu levar automação além da superfície e conectar com o coração do legado: o seu COBOL.

---

🧠 O que é IBM RPA (sem papo de vendedor)

O IBM Robotic Process Automation (RPA) é uma plataforma que cria “robôs de software” capazes de:

• Simular ações humanas (digitar, clicar, navegar)
• Integrar sistemas que nunca foram pensados para conversar
• Automatizar processos repetitivos
• Orquestrar fluxos complexos (inclusive com IA)

👉 Em linguagem de mainframe:

É como ter um operador batch + usuário TSO + integrador MQ + analista funcional… tudo em um script automatizado.

---

🕰️ Origem e evolução (sim, isso tem história)

Antes de virar hype:

• Anos 70–90: Automação já existia… via JCL, CLIST, REXX
• Anos 2000: Scripts de automação GUI começam a aparecer
• Pós-2015: Surge o conceito moderno de RPA
• IBM entra no jogo e evolui para algo corporativo, robusto e integrável com:
  • z/OS
  • APIs REST
  • IA (Watson)

💡 Ou seja:

O RPA moderno é o “REXX com esteróides + interface gráfica + IA”

---

🔥 Por que isso importa para quem vive no COBOL?

Porque o problema nunca foi o COBOL.

O problema é:

• Integração com sistemas modernos
• Processos manuais
• Interfaces antigas (green screen, alguém? 😏)
• Dependência humana para tarefas repetitivas

👉 O RPA resolve isso SEM reescrever seu sistema.

---

💡 Caso real (estilo Bellacosa)

🎯 Cenário

Sistema COBOL no CICS que:

• Consulta saldo
• Atualiza registros VSAM
• Não tem API
• Só acessível via terminal 3270

😵 Problema

Um time precisa consultar 5.000 registros/dia manualmente

---

🤖 Solução com IBM RPA

O robô:

1. Abre emulador 3270
2. Loga no sistema
3. Navega pelas telas
4. Executa transações CICS
5. Captura dados
6. Exporta para CSV / envia via API

---

🧾 Resultado

Antes	Depois
6 horas humanas	15 minutos
Erros manuais	Zero
Stress operacional	Eliminado

💥 E o melhor:

Nenhuma linha de COBOL alterada

---

⚙️ Como funciona por dentro (visão técnica)

O IBM RPA tem três pilares:

1. 🧩 Designer

• Interface visual (drag & drop)
• Criação de bots
• Integração com scripts

2. 🤖 Bots

• Executam tarefas
• Podem ser:
  • Attended (com usuário)
  • Unattended (totalmente automáticos)

3. 🎛️ Control Center

• Orquestra execução
• Agenda jobs
• Monitora performance

👉 Sim, é tipo um JES2 moderno… só que para automação 😄

---

🛠️ Exemplo prático (pseudo fluxo)

START BOT
|
|-- Launch Terminal 3270
|-- Send Keys: USER/PASSWORD
|-- Navigate: CICS TXN ABCD
|-- Read Screen Field
|-- Store Data
|-- Loop Records
|-- Export CSV
|
END BOT

💡 Para um coboleiro:

Isso é basicamente um PERFORM UNTIL… com tela verde no meio

---

🧪 Easter Eggs que poucos sabem

🔥 1. RPA + MQ = integração invisível
Você pode acionar bots via filas MQ → automação baseada em eventos

🔥 2. RPA pode chamar APIs REST e depois alimentar COBOL
Bridge perfeita entre cloud e z/OS

🔥 3. Pode automatizar ISPF
Sim… ISPF. Aquela telinha azul dos anos 80 😄

🔥 4. Substitui scripts Frankenstein
Adeus .bat + macro Excel + script Python + reza

---

🧠 Curiosidades que mudam o jogo

• RPA NÃO é só front-end → pode orquestrar backend
• RPA NÃO substitui COBOL → potencializa COBOL
• RPA NÃO é só “clicador” → pode tomar decisões com IA

---

⚠️ Onde tomar cuidado

RPA NÃO é bala de prata.

Evite usar quando:

• Existe API bem definida → use integração direta
• Processo é instável → bot quebra fácil
• Tela muda frequentemente → manutenção alta

👉 Regra de ouro:

Use RPA para estabilizar o legado, não para mascarar caos

---

🚀 Passo a passo para começar (mentalidade mainframe)

1. Identifique processos repetitivos

• Batch manual?
• Consulta operacional?
• Input humano?

2. Escolha um “quick win”

• Algo pequeno, mas visível

3. Modele o fluxo

• Pense como um JCL + COBOL

4. Crie o bot no IBM RPA

5. Teste como se fosse produção

• Simule erro
• Timeout
• Input inválido

6. Coloque sob controle (governança!)

• Logs
• Monitoramento
• Auditoria

---

🔥 Insight final (pra fechar com impacto)

Você não precisa modernizar o mainframe jogando ele fora.

Você moderniza quando:

• Conecta
• Automatiza
• Orquestra

E o IBM RPA faz exatamente isso:

Ele não substitui o COBOL…
Ele transforma seu COBOL em uma API viva — mesmo sem API.

---

☕ Conclusão no estilo Bellacosa

Se o JCL foi o maestro do batch…
Se o CICS foi o rei do online…

Então o RPA é:

💥 O operador invisível que nunca erra, nunca cansa e nunca pede férias

 

Bellacosa Mainframe do jcl ao json laboratorio pratico

🧪 LABORATÓRIO — DO JCL AO JSON

🐍 Missão: Dominar dados reais com Python

👉 Formato: desafios práticos
👉 Nível: iniciante → intermediário
👉 Ideal para 1–2 dias de hands-on
👉 Pode virar curso ou workshop

---

🔹 BLOCO 1 — Arquivos (I/O)

🧩 Desafio 1 — Leitor de arquivo sequencial

Crie um programa que:

• Leia clientes.txt
• Mostre número total de linhas
• Mostre a primeira e última linha

💡 Analog: processamento sequencial COBOL

---

🧩 Desafio 2 — Contador de registros válidos

Arquivo contém linhas vazias e comentários iniciados por #.

Conte apenas registros válidos.

---

🧩 Desafio 3 — Gerador de arquivo batch

Crie um arquivo relatorio.txt contendo:

• Data/hora atual
• Total de registros processados
• Status “OK”

---

🧩 Desafio 4 — Conversor TXT → CSV

Entrada:

123;Ana;1200
456;João;950

Produza um CSV com cabeçalho.

---

🧩 Desafio 5 — Copiador com filtro

Copie transacoes.txt para aprovadas.txt
apenas registros com valor > 1000.

---

🔹 BLOCO 2 — Pandas (Dados tabulares)

🧩 Desafio 6 — Carregar dataset

Use Pandas para:

• Ler um CSV
• Mostrar as 5 primeiras linhas
• Mostrar número de registros

---

🧩 Desafio 7 — Filtro de negócios

Mostre apenas clientes com saldo > 1000.

Ordene por saldo decrescente.

---

🧩 Desafio 8 — Estatísticas rápidas

Calcule:

• Média do saldo
• Máximo
• Mínimo
• Total

---

🧩 Desafio 9 — Agrupamento

Agrupe clientes por cidade e conte quantos há em cada uma.

💡 Similar a GROUP BY

---

🧩 Desafio 10 — Pipeline batch moderno

Leia um CSV → filtre → salve novo CSV com resultados.

---

🔹 BLOCO 3 — NumPy (Processamento numérico)

🧩 Desafio 11 — Operações vetoriais

Crie dois arrays e calcule:

• Soma elemento a elemento
• Produto elemento a elemento
• Produto escalar

---

🧩 Desafio 12 — Matriz de desempenho

Simule vendas por região:

• Matriz 3×4
• Calcule totais por linha e coluna

---

🔹 BLOCO 4 — APIs (Integração moderna)

🧩 Desafio 13 — Consumidor de API

Use uma API pública (ex.: cotação de moedas).

Exiba:

• Valor atual
• Data/hora
• Fonte

💡 Biblioteca: requests

---

🧩 Desafio 14 — API → DataFrame

Obtenha dados JSON de uma API e:

• Converta para Pandas
• Mostre estatísticas
• Salve em CSV

---

🔹 BLOCO 5 — Web Scraping

🧩 Desafio 15 — Minerador de dados web

Extraia dados de uma página pública:

• Títulos de notícias OU
• Tabela da Wikipedia

Salve em arquivo estruturado.

💡 Bibliotecas:

requests
BeautifulSoup
pandas.read_html()

---

🏆 DESAFIO EXTRA (Modo Arquitetura)

🔥 Mega-missão — Pipeline completo

Construa um fluxo:

👉 Coletar dados de API
👉 Complementar com dados de arquivo local
👉 Processar com Pandas
👉 Salvar resultado final

💥 Isso simula um ETL moderno.

---

🎯 O que você dominará ao concluir

✔ Manipulação de arquivos
✔ Processamento tabular
✔ Computação numérica
✔ Integração com sistemas externos
✔ Coleta de dados da web
✔ Data pipelines
✔ Base para Data Science

---

🚀 Tradução para linguagem mainframe

Arquivos → Dataset sequencial

Pandas → DB2 em memória

NumPy → cálculo científico

APIs → integração online

Scraping → coleta automática

 

Bellacosa Mainframe apresenta guia de tabelas no COBOL

☕ “Se Você Ainda Usa Subscript… o Batch Já Está Rindo de Você”

O Guia Jedi de Tabelas COBOL que Todo Padawan Precisa Antes que o CPU Account Chegue 💸

“No Mainframe, memória é preciosa… mas CPU é dinheiro vivo.”

Padawan, aproxime-se do terminal. Hoje vamos falar de um dos poderes mais silenciosos — e mais subestimados — do universo COBOL:

🛰️ TABELAS. ÍNDICES. BUSCAS. MEMÓRIA PURA.

Se você domina isso… domina o coração do batch.
Se não domina… o batch domina você.

---

🧠 Parte 1 — A Verdade Oculta: OCCURS Não É Só Um Array

Muitos iniciantes pensam:

“Ah, OCCURS é só um array.”

Não, jovem padawan.
É um buffer estruturado diretamente na memória do programa.

01 EMP-TABLE.
   05 EMP-ENTRY OCCURS 100 TIMES.
      10 EMP-ID     PIC 9(6).
      10 EMP-NAME   PIC X(30).

Isso cria 100 registros contíguos.
Sem ponteiros. Sem heap. Sem frescura.

💡 Curiosidade:
COBOL foi projetado quando memória era absurdamente cara — por isso layouts são fixos e previsíveis.

---

⚔️ Parte 2 — Subscript vs Index: A Batalha dos Dois Caminhos

🔢 Subscript (o caminho do aprendiz)

MOVE EMP-NAME (WS-I) TO PRINT-NAME

✔ Simples
✔ Numérico
❌ Mais lento
❌ Recalcula endereço toda vez

---

⚡ Index (o caminho do Jedi)

05 EMP-ENTRY OCCURS 100 TIMES
   INDEXED BY EMP-IDX.

Uso:

SET EMP-IDX TO 1
MOVE EMP-NAME (EMP-IDX) TO PRINT-NAME

✔ Ponteiro interno
✔ Muito mais eficiente
✔ Necessário para SEARCH
✔ Não é numérico

🧙‍♂️ Easter Egg técnico:
Internamente, o índice é um deslocamento binário — não um número “1, 2, 3”.

---

🪄 Parte 3 — O Erro que Entrega o Padawan

Se você já escreveu isso:

ADD 1 TO EMP-IDX

🚨 O compilador não apenas desaprova…
ele julga sua linhagem inteira.

Índice só aceita:

SET EMP-IDX UP BY 1
SET EMP-IDX DOWN BY 1
SET EMP-IDX TO 1

💡 Índice NÃO é variável numérica.

---

🔍 Parte 4 — SEARCH: A Varredura do Deserto

Busca sequencial:

SEARCH EMP-ENTRY
   AT END DISPLAY "NOT FOUND"
   WHEN EMP-ID (EMP-IDX) = TARGET-ID
      DISPLAY "FOUND"
END-SEARCH

Características:

✔ Examina um a um
✔ Não precisa ordenar
✔ Começa na posição atual do índice

💎 Dica avançada:

SET EMP-IDX TO 5

Vai procurar do elemento 5 até o fim.

👉 Muito usado para retomar processamento após checkpoint.

---

🚀 Parte 5 — SEARCH ALL: O Salto no Hiperespaço

Busca binária:

SEARCH ALL EMP-ENTRY
   WHEN EMP-ID (EMP-IDX) = TARGET-ID
      DISPLAY "FOUND"
END-SEARCH

Mas cuidado…

⚠️ Regra de Ferro:

👉 A tabela DEVE estar ordenada pela chave da busca

Sem isso:

💀 Pode não encontrar valores existentes
💀 Não gera erro
💀 Bugs fantasma nas madrugadas de fechamento

---

📊 Comparação brutal

Método	Comparações (1 milhão itens)
Serial	até 1.000.000
Binária	~20

💸 Sim, isso vira dinheiro na fatura de CPU.

---

🔄 Parte 6 — SORT em Memória: O Poder Esquecido

Poucos padawans sabem:

COBOL pode ordenar uma tabela OCCURS inteira.

SORT EMP-ENTRY ASCENDING KEY EMP-ID

Se não especificar chave…

👉 Usa a KEY definida na tabela.

ASCENDING KEY EMP-ID

---

🧬 Parte 7 — REDEFINES: O Lado Negro da Memória

Aqui começa a magia obscura.

01 RAW-DATA PIC X(24).

01 EMP-TABLE REDEFINES RAW-DATA.
   05 EMP OCCURS 4 TIMES.
      10 EMP-ID PIC 9(2).
      10 EMP-NAME PIC X(4).

Nenhum byte é movido.

👉 Apenas reinterpretado.

---

🎯 Exemplo clássico

"10JOAO15MARIA20CARL"

Pode virar:

ID	Nome
10	JOAO
15	MARIA
20	CARL

💡 Isso é parsing sem custo de CPU.

---

🧹 Parte 8 — INITIALIZE: O Reset Jedi

INITIALIZE EMP-TABLE

Resultado:

✔ Alfanuméricos → espaços
✔ Numéricos → zeros

---

✈️ Variante poderosa

INITIALIZE EMP-TABLE
   REPLACING ALPHANUMERIC DATA BY "ABC"

Todos os campos recebem "ABC".

---

📚 Parte 9 — VALUE: Carregando a Tabela na Compilação

01 CITY-TABLE VALUE "LHRPEKMELJFK".
   02 CITY PIC X(3) OCCURS 4 TIMES.

Distribuição:

1 → LHR
2 → PEK
3 → MEL
4 → JFK

💡 Zero custo em runtime.

---

🏦 Parte 10 — O Que Bancos REALMENTE Fazem

Tabelas OCCURS são usadas para:

✔ Parâmetros carregados em memória
✔ Tabelas de códigos
✔ Conversões
✔ Regras de negócio
✔ Buffers massivos
✔ Lookups ultra rápidos

Em muitos sistemas críticos, elas substituem chamadas a banco.

---

🧠 Curiosidade Histórica

COBOL foi criado quando:

🧊 CPU era lenta
💾 Memória era caríssima
📼 Disco era ainda mais lento

Por isso:

👉 Processar em memória sempre foi o caminho do mestre.

---

🏆 Conclusão — O Segredo que Separa Padawans de Mestres

Se você entendeu este artigo…

Você aprendeu a:

✔ Controlar memória manualmente
✔ Otimizar CPU
✔ Implementar buscas eficientes
✔ Manipular dados sem cópia
✔ Pensar como um engenheiro mainframe

---

☕ Regra Suprema do Batch

“Quem domina tabelas… domina o tempo de execução.”

💣🔥 “10 MIL SEGUNDOS ROUBADOS POR DIA: O ASSASSINO SILENCIOSO DO SEU MAINFRAME” 🔥💣 Por que cada milissegundo no z/OS pode ser a diferença entre lucro e caos 🧠 Tradução + Expansão (na veia, sem anestesia) No mundo do processamento de transações em alto volume, “rápido o suficiente” é uma mentira confortável. Quando você roda milhões (ou bilhões) de transações por dia em um ambiente como z/OS, qualquer ineficiência — mesmo microscópica — vira um monstro financeiro. Não importa se você escreve em COBOL, PL/I ou Java. Se o seu código desperdiça tempo, o mainframe cobra — e cobra caro. 👉 Performance tuning não é “nice to have”. 👉 É sobrevivência corporativa. ⚙️ O Efeito Multiplicador (ou: como 10ms viram uma conta absurda) Vamos ao ponto crítico: Você otimiza um trecho e economiza 10 milissegundos. Agora multiplica isso: 1.000.000 execuções por dia Resultado: 👉 10.000 segundos economizados/dia (~2h46min de CPU) Agora entra o mundo real: Menos CPU → menos consumo de MSU Menos MSU → menor custo de licenciamento Menos contenção → mais throughput Mais throughput → mais negócio rodando 💣 Resumo estilo Bellacosa: “Você não economizou milissegundos… você salvou dinheiro REAL.” 🧨 Onde isso explode na prática 💥 Cenário clássico (batch assassino) Um JOB COBOL com loop: PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I > 1000000 EXEC SQL SELECT * INTO :HOST-VAR FROM CLIENTES WHERE ID = :WS-I END-EXEC END-PERFORM 💀 Problemas: SELECT * (crime hediondo) 1 milhão de chamadas SQL Possível table scan 🔧 Cirurgia de performance (passo a passo) 1️⃣ Reduzir dados (SQL cirúrgico) SELECT NOME, STATUS FROM CLIENTES WHERE ID = ? ✔ Menos I/O ✔ Menos CPU ✔ Menos transporte de dados 2️⃣ Garantir acesso via índice Use EXPLAIN no DB2: Evite: TABLE SCAN 😱 Busque: INDEX SEEK 😎 3️⃣ Trocar loop por processamento em bloco 💡 Em vez de 1 milhão de SELECTs: Use cursor Ou fetch em lote 4️⃣ Buffer Pool tuning (ouro puro) Se seu dado é acessado frequentemente: Ajuste buffer pools Evite I/O físico 💣 Easter Egg: Em muitos ambientes, só ajustar buffer pool já deu ganho de 30%+ sem mexer em uma linha de código. 🚀 Quick Wins que parecem pequenos… mas NÃO são 🧩 1. SQL eficiente Nunca use SELECT * Sempre valide acesso via índice Use EXPLAIN como religião ⚡ 2. Compiler moderno (COBOL v6+) Se você ainda usa compilador antigo: 💀 Você está ignorando otimizações do hardware moderno Ganhos comuns: Melhor uso de CPU Otimização automática de loops Instruções mais eficientes 💾 3. Movimento de dados (I/O mata performance) Regra de ouro: “Disco é lento. Memória é rei.” Faça: Cache inteligente Sort interno (quando adequado) Evite leituras repetidas 🧠 Curiosidade de guerra (história real de bastidor) Em um banco: Um único SELECT mal indexado Executado milhões de vezes/dia Resultado após correção: 👉 Redução de MSU suficiente para economizar dezenas de milhares por mês 💣 O código tinha 10 anos em produção 💣 Ninguém questionava 💣 Até alguém olhar com lupa 🔍 Análise profunda (nível arquiteto) Performance no mainframe não é só código. É um ecossistema: CPU (MIPS/MSU) I/O (disco vs memória) Locking (DB2) Concorrência (CICS) Batch window 👉 Uma otimização local pode gerar ganho global 👉 Ou causar efeito colateral (cuidado!) 🧨 Anti-patterns que destroem performance SELECT * Loop com SQL dentro Falta de índice Reprocessamento de dados Leitura repetida de VSAM/DB2 Uso de compilador legado 🏆 O verdadeiro “modernizar o mainframe” Não é só: API Cloud Microservices 💣 Isso é maquiagem se o core estiver ineficiente Modernizar de verdade é: ✔ Código otimizado ✔ Banco bem indexado ✔ CPU bem utilizada ✔ I/O sob controle 🔥 Conclusão (estilo Bellacosa raiz) “Mainframe não é lento. Código ruim é.” Um sistema bem ajustado não é só estável — 👉 Ele vira vantagem competitiva. 🛠️ Provocação final Qual foi aquele “fix ridiculamente simples” que você fez e: Derrubou consumo de CPU? Salvou batch window? Ou evitou um caos em produção? Se cavar… todo ambiente tem um “vilão escondido” esperando alguém enxergar. E quando você acha… 💣 o ganho vem em escala industrial.

 

Bellacosa Mainframe falando sobre performance e custo de processamento

💣🔥 10 MIL SEGUNDOS ROUBADOS POR DIA: O ASSASSINO SILENCIOSO DO SEU MAINFRAME 🔥💣

Por que cada milissegundo no z/OS pode ser a diferença entre lucro e caos

---

🧠 Performance na veia, sem anestesia

No mundo do processamento de transações em alto volume, “rápido o suficiente” é uma mentira confortável.

Quando você roda milhões (ou bilhões) de transações por dia em um ambiente como z/OS, qualquer ineficiência — mesmo microscópica — vira um monstro financeiro.

Não importa se você escreve em COBOL, PL/I ou Java.
Se o seu código desperdiça tempo, o mainframe cobra — e cobra caro.

👉 Performance tuning não é “nice to have”.
👉 É sobrevivência corporativa.

---

⚙️ O Efeito Multiplicador (ou: como 10ms viram uma conta absurda)

Vamos ao ponto crítico:

Você otimiza um trecho e economiza 10 milissegundos.

Agora multiplica isso:

• 1.000.000 execuções por dia
• Resultado:
  👉 10.000 segundos economizados/dia (~2h46min de CPU)

Agora entra o mundo real:

• Menos CPU → menos consumo de MSU
• Menos MSU → menor custo de licenciamento
• Menos contenção → mais throughput
• Mais throughput → mais negócio rodando

💣 Resumo estilo Bellacosa:

“Você não economizou milissegundos… você salvou dinheiro REAL.”

---

🧨 Onde isso explode na prática

💥 Cenário clássico (batch assassino)

Um JOB COBOL com loop:

PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I > 1000000
   EXEC SQL
      SELECT * INTO :HOST-VAR
      FROM CLIENTES
      WHERE ID = :WS-I
   END-EXEC
END-PERFORM

💀 Problemas:

• SELECT * (crime hediondo)
• 1 milhão de chamadas SQL
• Possível table scan

---

🔧 Cirurgia de performance (passo a passo)

1️⃣ Reduzir dados (SQL cirúrgico)

SELECT NOME, STATUS
FROM CLIENTES
WHERE ID = ?

✔ Menos I/O
✔ Menos CPU
✔ Menos transporte de dados

---

2️⃣ Garantir acesso via índice

Use EXPLAIN no DB2:

• Evite:
  • TABLE SCAN 😱
• Busque:
  • INDEX SEEK 😎

---

3️⃣ Trocar loop por processamento em bloco

💡 Em vez de 1 milhão de SELECTs:

• Use cursor
• Ou fetch em lote

---

4️⃣ Buffer Pool tuning (ouro puro)

Se seu dado é acessado frequentemente:

• Ajuste buffer pools
• Evite I/O físico

💣 Easter Egg:

Em muitos ambientes, só ajustar buffer pool já deu ganho de 30%+ sem mexer em uma linha de código.

---

🚀 Quick Wins que parecem pequenos… mas NÃO são

🧩 1. SQL eficiente

• Nunca use SELECT *
• Sempre valide acesso via índice
• Use EXPLAIN como religião

---

⚡ 2. Compiler moderno (COBOL v6+)

Se você ainda usa compilador antigo:

💀 Você está ignorando otimizações do hardware moderno

Ganhos comuns:

• Melhor uso de CPU
• Otimização automática de loops
• Instruções mais eficientes

---

💾 3. Movimento de dados (I/O mata performance)

Regra de ouro:

“Disco é lento. Memória é rei.”

Faça:

• Cache inteligente
• Sort interno (quando adequado)
• Evite leituras repetidas

---

🧠 Curiosidade de guerra (história real de bastidor)

Em um banco:

• Um único SELECT mal indexado
• Executado milhões de vezes/dia

Resultado após correção:

👉 Redução de MSU suficiente para economizar dezenas de milhares por mês

💣 O código tinha 10 anos em produção
💣 Ninguém questionava
💣 Até alguém olhar com lupa

---

🔍 Análise profunda (nível arquiteto)

Performance no mainframe não é só código.

É um ecossistema:

• CPU (MIPS/MSU)
• I/O (disco vs memória)
• Locking (DB2)
• Concorrência (CICS)
• Batch window

👉 Uma otimização local pode gerar ganho global
👉 Ou causar efeito colateral (cuidado!)

---

🧨 Anti-patterns que destroem performance

• SELECT *
• Loop com SQL dentro
• Falta de índice
• Reprocessamento de dados
• Leitura repetida de VSAM/DB2
• Uso de compilador legado

---

🏆 O verdadeiro “modernizar o mainframe”

Não é só:

• API
• Cloud
• Microservices

💣 Isso é maquiagem se o core estiver ineficiente

Modernizar de verdade é:

✔ Código otimizado
✔ Banco bem indexado
✔ CPU bem utilizada
✔ I/O sob controle

---

🔥 Conclusão (estilo Bellacosa raiz)

“Mainframe não é lento.
Código ruim é.”

Um sistema bem ajustado não é só estável —
👉 Ele vira vantagem competitiva.

---

🛠️ Provocação final

Qual foi aquele “fix ridiculamente simples” que você fez e:

• Derrubou consumo de CPU?
• Salvou batch window?
• Ou evitou um caos em produção?

Se cavar… todo ambiente tem um “vilão escondido” esperando alguém enxergar.

E quando você acha…

💣 o ganho vem em escala industrial.

A Maior Mentira da Modernização Mainframe: Por Que Transformar COBOL em Java Não Resolve Quase Nada

Bellacosa Mainframe o cobol nao é o problema

---

☕💣🚨 PADAWAN, O COBOL NÃO É O PROBLEMA! O VERDADEIRO MONSTRO ESTÁ ESCONDIDO DENTRO DO SISTEMA

A Maior Mentira da Modernização Mainframe: Por Que Transformar COBOL em Java Não Resolve Quase Nada

---

A Guerra Contra o COBOL

Existe uma frase que se repete há mais de 30 anos:

"Precisamos eliminar o COBOL."

O curioso é que enquanto essa frase era repetida por consultorias, vendors, CIOs e arquitetos corporativos, o COBOL continuava fazendo aquilo que sempre fez:

• pagando aposentadorias;

• processando cartões;

• calculando seguros;

• movimentando bilhões em transações;

• sustentando governos inteiros.

O COBOL nunca foi o problema.

O problema sempre foi outro:

ninguém mais sabia exatamente o que estava escondido dentro dele.

---

O Dia em Que a Empresa Descobriu Que Ninguém Entendia o Sistema

Imagine um banco.

Ele possui:

• 18 milhões de linhas COBOL;

• 4.000 jobs batch;

• 1.500 copybooks;

• centenas de tabelas DB2;

• regras de negócio escritas desde 1987.

Um consultor chega e diz:

"Vamos converter tudo para Java."

A diretoria aprova.

O projeto custa dezenas de milhões.

Três anos depois...

O sistema agora roda em Java.

E o problema continua exatamente igual.

Porque ninguém entendeu o negócio.

Apenas trocaram a sintaxe.

---

O Efeito "Jobol"

O artigo menciona um termo fantástico:

JOBOL

Java + COBOL

Código Java que continua pensando como COBOL.

Exemplo:

COBOL

IF CLIENTE-ATIVO = 'S'
   COMPUTE DESCONTO = VALOR * 0.10
END-IF

Convertido automaticamente:

if(clienteAtivo.equals("S")){
    desconto = valor * 0.10;
}

Parece moderno.

Mas pergunte:

• Por que 10%?

• Desde quando?

• Existe legislação envolvida?

• Existe exceção?

Ninguém sabe.

A lógica foi transportada.

O conhecimento não.

---

O Easter Egg Mais Perigoso do Mainframe

Todo sistema antigo possui algo parecido.

Um trecho de código aparentemente absurdo:

IF DATA = '31121999'
   MOVE ZERO TO TAXA
END-IF

O programador novo pergunta:

"Quem colocou isso?"

Ninguém sabe.

Remove.

Produção explode.

Meses depois descobrem:

Aquilo corrigia um problema de cálculo criado por uma mudança tributária em 1999.

O código era feio.

Mas carregava uma regra de negócio invisível.

---

O Mainframe Guarda Mais Conhecimento Que os Documentos

Muitas empresas acreditam que possuem documentação.

Não possuem.

Possuem:

• manuais desatualizados;

• diagramas antigos;

• apresentações esquecidas.

O verdadeiro conhecimento está em:

• COBOL;

• PL/I;

• Natural;

• JCL;

• PROC;

• CICS;

• IMS;

• DB2;

• VSAM.

O código virou documentação viva.

---

Laboratório Bellacosa

Descobrindo Conhecimento Escondido

Imagine um programa de cálculo de seguro.

Passo 1

Procure constantes misteriosas.

MOVE 0.732 TO FATOR-AJUSTE

Pergunta:

Por que 0.732?

---

Passo 2

Procure datas mágicas.

IF DATA > '01012015'

Pergunta:

O que aconteceu em 2015?

---

Passo 3

Procure exceções.

IF UF = 'SP'

Pergunta:

Por que somente São Paulo?

---

Passo 4

Converse com usuários antigos.

Muitas vezes eles sabem mais que a documentação.

---

Resultado

Você começa a reconstruir o domínio do negócio.

Exatamente o que o DDD propõe.

---

Domain Driven Design Explicado Para Mainframeiros

Muita gente acha que DDD é moda.

Na verdade, o mainframe fazia DDD sem saber.

---

Exemplo

Sistema de seguros.

Temos:

Domínio

Seguros

Subdomínio

Sinistros

Contexto delimitado

Regulação

Linguagem ubíqua

Termos que o negócio entende:

• apólice;

• prêmio;

• segurado;

• franquia;

• indenização.

---

O Erro Clássico

Código moderno:

processEntity()

Código orientado ao domínio:

aprovarIndenizacao()

Qual transmite melhor o negócio?

---

O Grande Segredo dos Batchs

Existe uma verdade inconveniente.

Muitas regras de negócio não estão nos programas.

Estão na sequência dos jobs.

---

Exemplo:

JOB001 - IMPORTA CLIENTES
JOB002 - CALCULA JUROS
JOB003 - EMITE FATURAS
JOB004 - GERA ARQUIVO BACEN

Troque a ordem.

O banco para.

O fluxo batch também é conhecimento corporativo.

---

O Perigo da Reescrita Total

Todo arquiteto sonha com:

"Vamos reescrever tudo."

Na prática:

Forças

• arquitetura limpa;

• tecnologias novas;

• documentação moderna.

Fraquezas

• altíssimo risco;

• anos de projeto;

• perda de regras escondidas.

Perigos

• divergência de cálculo;

• problemas regulatórios;

• inconsistências financeiras.

---

A Estratégia Que Mais Funciona

O artigo cita o conceito mais inteligente da modernização moderna.

Strangler Fig

A Figueira Estranguladora.

Ela cresce ao redor da árvore antiga.

Até substituí-la.

---

No Mainframe

Fase 1

COBOL continua funcionando.

Fase 2

Criamos APIs.

Fase 3

Novos sistemas consomem APIs.

Fase 4

Partes são substituídas.

Fase 5

O legado diminui gradualmente.

Sem Big Bang.

Sem suicídio corporativo.

---

Raincode: O Que Muita Gente Não Entendeu

Muitos acreditam que Raincode é uma ferramenta de migração.

Na verdade:

É uma ferramenta de sobrevivência.

Ela permite:

• retirar carga do Z;

• migrar gradualmente;

• reduzir custos;

• ganhar tempo.

Mas atenção:

Ela não resolve:

• arquitetura ruim;

• regras escondidas;

• documentação ausente.

---

A Nova Função do Especialista COBOL

Aqui está a maior mudança dos próximos anos.

O programador COBOL deixa de ser:

• mantenedor;

• bombeiro de produção;

• operador de emergência.

E passa a ser:

Arqueólogo Digital

A pessoa capaz de responder:

"Por que o sistema faz isso?"

Essa resposta vale mais que escrever código.

---

Curiosidade Histórica

Muitas regras de negócio existentes hoje foram criadas por programadores que já faleceram ou estão aposentados há décadas.

Mesmo assim:

• seus algoritmos continuam rodando;

• suas decisões continuam afetando clientes;

• suas validações continuam protegendo empresas.

Em alguns casos, o código virou literalmente um patrimônio intelectual da organização.

---

O Verdadeiro Inimigo

Não é COBOL.

Não é JCL.

Não é CICS.

Não é IMS.

Não é DB2.

O verdadeiro inimigo é:

🚨 conhecimento implícito.

Aquilo que ninguém documentou.

Aquilo que ninguém explica.

Aquilo que só existe dentro do código.

---

Conclusão Bellacosa Mainframe

O mercado passou décadas tentando responder à pergunta errada.

Perguntavam:

"Como eliminamos o COBOL?"

Quando deveriam perguntar:

"Como preservamos o conhecimento do negócio?"

Porque uma empresa pode trocar:

• COBOL por Java;

• Java por C#;

• C# por Rust;

• Rust por IA Generativa.

Mas se perder o conhecimento embutido em 40 anos de operação...

não estará modernizando.

Estará apenas reconstruindo um problema antigo com ferramentas novas.

E como todo velho operador sabe:

"Trocar a cor do terminal não muda o que acontece quando você aperta ENTER." ☕💣🚨

 

Bellacosa Mainframe fala sobre o guardião invisivel SMP/E no Z/OS

☕🔥 SMP/E — O Guardião Invisível do z/OS (ou: por que seu COBOL roda há 30 anos sem quebrar)

Se você é dev COBOL sênior, já viu de tudo: batch que roda desde o século passado, CICS que nunca cai, DB2 que parece imortal.

Mas tem um herói silencioso nisso tudo.

👉 O SMP/E (System Modification Program/Extended)

E hoje você vai enxergar ele como nunca viu:
não como ferramenta… mas como sistema de governança do caos controlado.

---

🧠 Antes de tudo: por que o SMP/E existe?

Volta comigo…

Década de 70/80.

• Software entregue em fita
• Correções manuais
• Dependências no papel
• Atualizar = rezar

👉 Resultado?

💥 Ambientes quebrando
💥 Versões inconsistentes
💥 “Funciona em um LPAR, não no outro”

---

💡 A resposta da IBM

Criar um sistema que:

• Controla tudo
• Versiona tudo
• Rastreia tudo
• Permite rollback

👉 Nasce o SMP… depois o SMP/E

---

🧬 O conceito que muda tudo

“No mainframe, nada é sobrescrito… tudo é versionado.”

---

🔄 O pipeline que mantém seu COBOL vivo

📦 RECEIVE

• Entrada de PTF/APAR
• Vai para SMPPTS

---

⚙️ APPLY

• Atualiza target libraries
• Seu programa começa a usar

---

💾 ACCEPT

• Consolida na DLIB
• Torna oficial

---

💡 Easter egg Bellacosa:

APPLY é tipo rodar um programa em teste
ACCEPT é dar “commit em produção”

---

🧩 FMID, PTF, APAR — o trio que você precisa dominar

🏗️ FMID

• Produto base
• Vem em RELFILE

---

🔧 PTF

• Correção definitiva

---

🚨 APAR

• Problema identificado

---

💡 Insight:

APAR é o bug report…
PTF é o merge aprovado 😄

---

📦 Onde as coisas realmente vivem

🧠 CSI (o cérebro)

• VSAM KSDS
• Guarda:
  • histórico
  • elementos
  • zones

---

🌍 Zones

Zone	Função
Global	controle
Target	runtime
DLIB	baseline

---

📁 Datasets que poucos explicam direito

Dataset	Função
SMPPTS	entrada (PTF/APAR)
SMPSCDS	source temporário
SMPMTS	macros
SMPSTS	backup (RESTORE)
SMPLOG	logs

---

💥 Curiosidade:

Um APPLY grande pode alocar +100 datasets automaticamente

---

🔗 Dependências — onde o caos vira matemática

Você pede:

APPLY PTFZ

O SMP/E resolve:

PTFX → PTFY → PTFZ

E ainda entende:

• supersede
• co-requisites
• IFREQ

---

💡 Insight:

SMP/E é um resolvedor de dependência muito antes do npm existir 😎

---

🛑 HOLDDATA — o “não faça isso agora”

6

📌 Exemplo real

++HOLD(PTF001) SYSTEM REASON(IPL)

👉 Significa:

• precisa IPL
• impacto sistêmico

---

🧠 Tipos

• ERROR
• SYSTEM
• USER
• DOC

---

🔥 Easter egg

Você pode ignorar:

APPLY BYPASS(HOLDSYSTEM)

Mas…

“Com grandes poderes vêm grandes incidentes” 😄

---

🧬 Rastreabilidade absurda (nível mainframe)

Cada módulo tem:

• FMID (origem)
• RMID (quem substituiu)
• UMID (última mudança)

---

💡 Pergunta de produção:

“Quem alterou esse módulo?”

👉 SMP/E responde.

---

❌ REJECT vs 🔄 RESTORE

Ação	Comando
Desfazer RECEIVE	REJECT
Desfazer APPLY	RESTORE

---

💥 Regra de ouro:

RECEIVE → REJECT
APPLY   → RESTORE

---

🏗️ DDDEF — o detalhe que poucos dominam

👉 Define datasets para SMP/E

• Nome
• Espaço
• Formato

---

💡 Insight forte:

DDDEF transforma SMP/E em sistema autônomo

---

🧠 UCLIN — mexendo no cérebro do sistema

UCLIN.
  ADD DDDEF(...)
  ADD TARGETZONE(...)
ENDUCL.

---

⚠️ Curiosidade:

UCLIN é poderoso o suficiente para quebrar tudo… silenciosamente 😄

---

🔧 Administração avançada (nível operador raiz)

Comando	Função
ZONECOPY	clonar ambiente
ZONEEXPORT	backup
ZONEIMPORT	restore
ZONEEDIT	alteração em massa
UNLOAD	gerar UCLIN

---

📊 Relatórios — onde o SMP/E fala com você

• SYSMOD STATUS → deu certo?
• ELEMENT SUMMARY → o que mudou?
• ERRSYSMODS → risco ativo

---

💡 Insight:

APPLY instala… relatório valida.

---

🌐 SMP/E moderno (sim, ele evoluiu)

RECEIVE ORDER CONTENT(ALL)

👉 Baixa direto da IBM:

• PTF
• APAR
• HOLDDATA

---

💥 Curiosidade:

Algumas empresas rodam isso automaticamente semanalmente

---

🧪 Mini cenário real (pra fixar)

Você aplica uma PTF:

• ✔ APPLY roda
• ❌ batch começa a falhar

👉 O que você faz?

1. Ver SMPLOG
2. Ver ERRSYSMODS
3. Identificar PTF
4. Executar:

RESTORE SYSMOD(PTFxxxx)

💥 Sistema volta

---

🧠 Insight final (nível Bellacosa)

O SMP/E não é um instalador…
é um sistema de controle de estado do z/OS

---

☕🔥 Fechamento

Enquanto no mundo distribuído:

• você instala
• reza
• e torce

No mainframe:

• você recebe
• aplica
• aceita
• rastreia
• e volta atrás se precisar

---

💥 Frase final

“Seu COBOL roda há 30 anos não por sorte…
mas porque o SMP/E nunca deixou o caos entrar.”