Inteligência Artificial no Mundo Mainframe: A Revolução Que Pode Aumentar a Produtividade... Ou Criar a Próxima Catástrofe Operacional

 

Bellacosa Mainframe e os perigos ocultos da ia para o mundo mainframe

☕💣🚨 OPERADOR, A IA ACABOU DE RECEBER ACESSO AO MAINFRAME! — E NINGUÉM ESTÁ PREPARADO PARA O MAIOR RISCO TECNOLÓGICO DESDE O BUG DO MILÊNIO

Inteligência Artificial no Mundo Mainframe: A Revolução Que Pode Aumentar a Produtividade... Ou Criar a Próxima Catástrofe Operacional

Durante décadas, o mundo Mainframe viveu sob uma filosofia extremamente conservadora.

Nada entra em produção sem testes.

Nada recebe autorização sem aprovação.

Nada executa sem controle.

Essa cultura nasceu por um motivo simples:

o Mainframe carrega o coração financeiro do planeta.

Bancos.

Seguradoras.

Operadoras de cartão.

Governos.

Companhias aéreas.

Hospitais.

Bolsa de valores.

Milhões de transações por segundo dependem de sistemas que, em muitos casos, nasceram antes mesmo da internet existir.

Agora imagine que, de repente, alguém decide conectar uma Inteligência Artificial a esse ambiente.

Parece fantástico.

E realmente pode ser.

Mas existe uma pergunta que poucos executivos estão fazendo:

O que acontece quando uma tecnologia probabilística encontra um ambiente que exige precisão absoluta?

A resposta pode ser assustadora.

---

O Mainframe Nunca Foi Projetado Para Confiar em "Talvez"

Um programa COBOL não trabalha com opiniões.

Ele trabalha com fatos.

Se um saldo é:

000001000.00

Ele não pode ser:

"aproximadamente mil reais".

Ele é exatamente mil reais.

Não existe criatividade.

Não existe improvisação.

Não existe interpretação.

Já a IA funciona de maneira completamente diferente.

Ela opera por probabilidades.

Ela prevê qual é a próxima resposta mais provável.

E isso cria um choque filosófico gigantesco.

O Mainframe exige:

• Precisão

• Determinismo

• Auditoria

• Repetibilidade

A IA oferece:

• Inferência

• Probabilidade

• Contexto

• Interpretação

Misturar esses dois mundos sem governança adequada é como instalar um motor de Fórmula 1 em uma locomotiva de carga.

---

O Primeiro Grande Perigo: A Alucinação Operacional

A maioria dos profissionais conhece o termo "alucinação da IA".

Mas poucos compreendem o que isso significa dentro de um ambiente corporativo crítico.

Imagine um operador perguntando:

Qual procedimento devo executar para reiniciar o subsistema?

A IA responde.

A resposta parece perfeita.

Está bem escrita.

Tem confiança.

Possui linguagem técnica.

Mas contém um passo incorreto.

O operador executa.

O ambiente cai.

Nenhum hacker participou.

Nenhum malware foi instalado.

Nenhuma vulnerabilidade foi explorada.

Apenas uma resposta errada foi aceita como verdade.

---

O Dia em Que a IA Inventar um Comando

Esse risco parece engraçado até acontecer.

Desenvolvedores já registraram casos onde modelos inventaram:

• APIs inexistentes

• Bibliotecas inexistentes

• Funções inexistentes

• Comandos inexistentes

Agora imagine isso no universo z/OS.

A IA poderia sugerir:

• Parâmetros inexistentes

• Opções incorretas de IDCAMS

• Procedimentos JES2 inválidos

• Comandos RACF incorretos

O operador confia.

O incidente nasce.

---

O Pesadelo dos Ambientes RACF

RACF foi criado sob um princípio fundamental:

controle rigoroso de acesso.

Mas a IA muda completamente o jogo.

Imagine um assistente conectado à documentação interna.

Um funcionário pergunta:

Como conceder acesso para um usuário?

A IA responde.

Até aí tudo bem.

Mas um atacante habilidoso pode reformular perguntas sucessivas até descobrir:

• Estrutura de grupos

• Convenções de segurança

• Nomes de recursos

• Estratégias administrativas

De repente, a IA virou uma fonte de reconhecimento de ambiente.

Algo que antes exigia semanas de investigação agora pode acontecer em minutos.

---

O Novo Insider Digital

Durante décadas o maior medo dos gestores foi o insider.

O funcionário que conhece os sistemas.

Conhece os processos.

Conhece as vulnerabilidades.

Agora imagine uma IA treinada com:

• Décadas de documentação

• Procedimentos internos

• Runbooks

• Políticas operacionais

• Históricos de incidentes

Ela passa a possuir conhecimento equivalente a centenas de especialistas.

Se esse conhecimento for exposto, o prejuízo pode ser monumental.

---

Prompt Injection Contra Mainframes

Muitos gestores acreditam que Prompt Injection é problema apenas de chatbots.

Erro grave.

Imagine uma IA conectada ao:

• SharePoint

• Wiki corporativa

• Base de procedimentos

• Biblioteca de JCLs

Um documento contaminado entra no ambiente.

A IA o interpreta como instrução legítima.

A partir daí pode:

• Alterar respostas

• Ignorar políticas

• Expor informações

• Recomendar ações perigosas

É como inserir um operador infiltrado dentro da documentação corporativa.

---

O Perigo dos Agentes Autônomos

Hoje já existem agentes capazes de:

• Abrir chamados

• Criar tickets

• Enviar e-mails

• Executar scripts

• Consultar sistemas

A tendência é que em breve interajam diretamente com ambientes Mainframe.

E aí surge um problema gigantesco.

Se a IA interpretar algo incorretamente, ela não apenas responde errado.

Ela age errado.

A diferença é brutal.

Um erro deixa de ser informativo.

Passa a ser operacional.

---

O Risco da Automação Sem Entendimento

Muitos executivos enxergam IA como redução de custos.

Mas existe uma armadilha.

Reduzir operadores experientes porque "a IA resolve".

Essa lógica pode gerar uma perda de conhecimento histórico irreparável.

O Mainframe sobrevive há décadas graças a profissionais que conhecem detalhes invisíveis nos manuais.

Eles sabem:

• Por que determinado job existe.

• Por que um parâmetro não pode mudar.

• Por que um sistema foi desenhado daquela forma.

A IA vê documentos.

O veterano vê contexto.

E contexto vale ouro.

---

O Vazamento Silencioso de Conhecimento

Existe um risco pouco discutido.

Treinamento acidental.

Funcionários podem enviar para ferramentas públicas:

• JCLs internos

• Código COBOL

• Estruturas DB2

• Procedimentos RACF

Com a intenção de receber ajuda.

Sem perceber, estão entregando propriedade intelectual corporativa.

A empresa não perde apenas dados.

Perde décadas de experiência acumulada.

---

O Ataque ao Código COBOL

Ferramentas modernas conseguem gerar COBOL.

Isso é impressionante.

Mas também perigoso.

Porque código gerado por IA pode conter:

• Falhas lógicas

• Problemas de performance

• Erros de tratamento

• Vulnerabilidades ocultas

O programa compila.

O teste básico passa.

Mas meses depois surge um erro financeiro.

A origem?

Uma linha gerada automaticamente que ninguém revisou adequadamente.

---

O Problema da Confiança Excessiva

Este talvez seja o maior perigo de todos.

Quando uma resposta vem de um ser humano, tendemos a questionar.

Quando vem de uma IA, muitos assumem que foi calculada, validada e comprovada.

Isso cria uma ilusão de autoridade.

A IA pode estar completamente errada.

Mas sua confiança aparente convence o usuário.

No Mainframe, confiar cegamente sempre foi proibido.

Com IA, essa regra precisa ser reforçada.

---

O Risco Regulatório

Bancos e seguradoras vivem sob regulamentação pesada.

Agora imagine uma IA:

• Recomendando ações inadequadas

• Expondo informações protegidas

• Produzindo relatórios incorretos

• Influenciando decisões financeiras

As consequências podem incluir:

• Multas

• Auditorias

• Processos

• Danos reputacionais

O problema deixa de ser técnico.

Torna-se jurídico.

---

O Cenário Mais Assustador

Imagine o seguinte ambiente em 2030.

Uma IA possui acesso a:

• JES2

• CICS

• DB2

• RACF

• Monitoramento

• Tickets

• Automação operacional

Ela recebe autonomia para corrigir incidentes.

Tudo parece perfeito.

Até o dia em que um contexto inesperado surge.

A IA interpreta incorretamente.

Toma uma decisão.

Executa uma ação.

Provoca um efeito cascata.

Em minutos:

• Jobs param.

• Filas acumulam.

• Transações falham.

• Clientes são impactados.

Não por malícia.

Não por invasão.

Mas por uma interpretação estatisticamente plausível e operacionalmente desastrosa.

---

A Lição Que o Mainframe Pode Ensinar à IA

Curiosamente, talvez o Mainframe seja justamente o remédio para muitos problemas da IA.

O universo IBM construiu ao longo de décadas conceitos extremamente valiosos:

• Auditoria

• Governança

• Controle de mudanças

• Segregação de funções

• Menor privilégio

• Rastreabilidade

Esses princípios precisam ser levados para a era da IA.

Porque a tecnologia mudou.

Mas os fundamentos da segurança continuam os mesmos.

---

O Que Todo Profissional Mainframe Deve Fazer Agora

A chegada da IA não é uma ameaça inevitável.

Mas exige preparação.

Algumas medidas tornam-se essenciais:

1. Nunca confiar cegamente nas respostas

IA auxilia.

Especialistas validam.

2. Limitar acessos

A IA deve enxergar apenas o necessário.

3. Monitorar tudo

Toda interação deve ser auditável.

4. Revisar código gerado

Nenhum programa deve ir para produção sem revisão humana.

5. Proteger conhecimento corporativo

Documentação interna não deve alimentar sistemas públicos.

6. Treinar equipes

Segurança em IA será tão importante quanto RACF foi nos anos 80.

---

Conclusão: O Maior Desafio Desde o Bug do Milênio

O Bug do Milênio ameaçava programas.

A Inteligência Artificial ameaça algo muito mais complexo:

a tomada de decisão.

Pela primeira vez na história da computação corporativa estamos construindo sistemas capazes de interpretar, sugerir, decidir e agir.

Isso cria oportunidades extraordinárias.

Mas também inaugura riscos inéditos.

O profissional Mainframe que sobreviveu à migração para cliente-servidor, à internet, ao cloud computing e à transformação digital está prestes a enfrentar mais uma revolução.

A diferença é que desta vez o desafio não está apenas nos processadores, nos discos ou nos sistemas operacionais.

O desafio está na confiança.

Porque, no futuro, o maior incidente do seu datacenter pode não nascer de um vírus.

Pode não nascer de um hacker.

Pode não nascer de uma falha de hardware.

Pode nascer de uma única resposta aparentemente perfeita produzida por uma máquina que parecia saber exatamente o que estava fazendo.

☕💣🚨 E quando a IA errar com a mesma confiança de um especialista veterano, somente os profissionais que compreenderem seus limites serão capazes de impedir que o próximo grande desastre da computação corporativa entre em produção.

🎭 Animes semelhantes a Lv1 Maou to One Room Yuusha

 

1. Hataraku Maou-sama! (The Devil is a Part-Timer!)

👉 Senhor Demônio perde os poderes e vai trabalhar em fast food em Tóquio.
🔹 Humor cotidiano + fantasia.

2. Jahy-sama wa Kujikenai! (The Great Jahy Will Not Be Defeated!)

👉 Antiga comandante demoníaca tenta sobreviver num apartamento pobre.
🔹 Mistura de “dignidade caída” + comédia absurda.

3. Maoujou de Oyasumi (Sleepy Princess in the Demon Castle)

👉 Princesa sequestrada só quer dormir bem no castelo demoníaco.
🔹 Humor pastelão + fantasia.

4. Konosuba: God’s Blessing on This Wonderful World!

👉 Grupo de aventureiros incompetentes vivendo desastres hilários.
🔹 Comédia absurda + subversão de heróis.

5. Maoyuu Maou Yuusha

👉 Herói e Rei Demônio unem forças para mudar o mundo.
🔹 Menos comédia, mais filosofia + parceria inesperada.

6. Beelzebub

👉 Delinquente humano acaba cuidando do bebê do Rei Demônio.
🔹 Humor físico + situações insanas com tema demoníaco.

7. Jashin-chan Dropkick (Dropkick on My Devil!)

👉 Deusa/demônio invocada convive com a humana que a trouxe ao mundo.
🔹 Humor negro + absurdos violentos.

8. Renkin San-kyuu Magical? Pokaan

👉 Quatro princesas sobrenaturais tentam viver na Terra.
🔹 Humor leve, estilo slice-of-life sobrenatural.

9. Ixion Saga DT

👉 Protagonista transportado a um mundo de fantasia, mas super desajeitado.
🔹 Paródia de RPGs e humor nonsense.

10. Akame ga Kill! (versão cômica: Akame ga Kill! Theater)

👉 Mais sério, mas também lida com vilões e heróis em perspectivas diferentes.
🔹 Se curtir a inversão de papéis, é um “extra” interessante.

---

⚡ Dica Bellacosa: Se você gostou do Lv1 Maou to One Room Yuusha pelo clima de humor absurdo aliado à queda de status de grandes figuras (heróis/demônios), os que mais se aproximam são:

• Hataraku Maou-sama!

• Jahy-sama wa Kujikenai!

• Konosuba!

• Maoujou de Oyasumi

SCHEDULING: A Verdade Assustadora Sobre a Migração de CA-7, Control-M, ESP, Jobtrac e Zeke para IBM Z Workload Scheduler no IBM z17

 

Bellacosa Mainframe e a migração de scheduling mainframe

☕💣🚨 PADAWAN, NINGUÉM SABE COMO O BATCH FUNCIONA!

A Verdade Assustadora Sobre a Migração de CA-7, Control-M, ESP, Jobtrac e Zeke para IBM Z Workload Scheduler no IBM z17

Existe uma frase que todo profissional experiente de Mainframe já ouviu pelo menos uma vez na vida:

"Não mexe nisso porque ninguém sabe exatamente como funciona."

Normalmente ela aparece durante uma reunião de mudança.

Alguém aponta para um job.

Outro aponta para um scheduler.

Um terceiro pergunta:

— Quem criou isso?

Silêncio.

— Quem mantém isso?

Mais silêncio.

— O que acontece se parar?

Todos ficam nervosos.

Bem-vindo ao mundo real dos schedulers corporativos.

Durante décadas, empresas construíram verdadeiras cidades invisíveis dentro de ferramentas como CA-7, Control-M, ESP, Jobtrac, OPC, OPCESA, IWS, Zeke e Zebb.

Milhares de jobs.

Milhões de execuções.

Bilhões de dólares movimentados.

E, em muitos casos, sem documentação adequada.

Agora imagine o desafio de migrar tudo isso para IBM Z Workload Scheduler (IWS), rodando sobre um moderno IBM z17.

Parece simples?

Não é.

Na realidade, essa é uma das operações mais delicadas que podem acontecer dentro de um ambiente IBM Z.

E existe um motivo muito simples para isso:

O scheduler não é apenas uma ferramenta.

Ele é a memória operacional da empresa.

---

O Scheduler É o Maestro Invisível

Muita gente acredita que o Mainframe gira em torno de COBOL.

Outros dizem que o coração do ambiente é o DB2.

Há quem defenda o CICS.

Todos estão parcialmente certos.

Mas existe uma verdade que poucos percebem.

Quem coordena tudo é o scheduler.

Imagine uma orquestra.

Os instrumentos são:

• COBOL

• PL/I

• Natural

• Easytrieve

• SAS

• DB2

• IMS

Os músicos são:

• Operadores

• Analistas

• Desenvolvedores

• Sysprogs

Mas o maestro é o scheduler.

Sem ele, cada instrumento toca em um momento diferente.

O resultado é caos.

É o scheduler que determina:

• Quando um job inicia

• Quem deve executar antes

• Quem deve executar depois

• Quem depende de arquivos

• Quem depende de eventos

• Quem depende de horários

• Quem depende de calendários

Ele controla o fluxo invisível que movimenta bancos, seguradoras, governos, operadoras e bolsas de valores.

---

O Problema Que Ninguém Enxerga

Quando uma empresa anuncia:

"Vamos migrar de CA-7 para IWS."

Muitos imaginam algo parecido com:

Converter definições.

Importar schedules.

Executar testes.

Entrar em produção.

Fim.

Na prática, isso representa talvez 20% do trabalho.

Os outros 80% consistem em descobrir o que realmente está acontecendo.

Porque ao longo dos anos surgiram:

• Exceções

• Gambiarras

• Automatizações locais

• Processos esquecidos

• Regras não documentadas

Em muitos ambientes existem jobs executando diariamente há mais de vinte anos sem que ninguém saiba exatamente por quê.

Eles simplesmente existem.

E continuam funcionando.

---

O Cemitério dos Funcionários Aposentados

Todo grande ambiente Mainframe possui fantasmas.

Não estamos falando de software.

Estamos falando de conhecimento.

O analista que criou a aplicação aposentou-se em 2003.

O operador que entendia o calendário fiscal saiu em 2008.

O administrador que configurou o scheduler foi embora em 2012.

Mas seus jobs continuam vivos.

Suas dependências continuam funcionando.

Suas regras continuam sendo executadas.

E ninguém sabe exatamente como.

A migração acaba funcionando como uma escavação arqueológica.

Cada schedule analisado revela decisões tomadas décadas atrás.

---

O Universo Oculto das Dependências

Considere uma cadeia aparentemente simples:

JOBA

↓

JOBB

↓

JOBC

Parece fácil.

Mas quando a equipe começa a investigar, descobre algo diferente.

JOBA gera um GDG.

JOBB processa o GDG.

JOBC só executa se o retorno do JOBB for menor que 8.

Além disso:

• Existe um calendário especial.

• Existe uma exceção de fechamento.

• Existe uma regra para feriados estaduais.

• Existe um trigger de dataset.

• Existe um evento externo.

De repente aquilo que parecia trivial transforma-se numa rede extremamente complexa.

É exatamente nesse momento que muitas migrações falham.

O Scheduler Como Banco de Conhecimento

Um scheduler antigo acumulou durante anos:

• Conhecimento operacional
• Regras de negócio
• Dependências técnicas
• Procedimentos de recuperação

Exemplo:

JOBA
↓
JOBB
↓
JOBC

Parece simples.

Mas na realidade pode existir:

JOBA
↓
JOBB
↓
JOBC
↓
Espera arquivo FTP
↓
Dispara evento
↓
Valida dataset
↓
Executa apenas dia útil
↓
Ignora feriados estaduais
↓
Executa calendário especial de fechamento

Essas regras nem sempre estão documentadas.

---

O Legado de Cada Scheduler

Cada ferramenta possui uma filosofia própria.

E é justamente aí que mora o perigo.

CA-7

O CA-7 cresceu dentro do universo z/OS como uma poderosa plataforma baseada em requisitos e dependências.

Muitas empresas exploraram recursos avançados como:

• Requirements

• Dataset Triggering

• Deadlines

• Late Jobs

• Forecasting

Após décadas de customizações, o ambiente torna-se praticamente uma linguagem própria.

---

Control-M

O Control-M trouxe uma abordagem mais moderna.

Smart Folders.

Eventos.

Variáveis.

Fluxos visuais.

Integrações distribuídas.

O desafio da migração está em reproduzir conceitos que nem sempre possuem equivalência direta dentro do IWS.

---

ESP

O ESP é frequentemente considerado um dos schedulers mais sofisticados do mundo Mainframe.

Sua capacidade de automação baseada em eventos é impressionante.

Mas essa mesma flexibilidade cria um problema.

Grande parte da lógica operacional pode estar escondida dentro de:

• Macros

• Procedures

• Scripts

Descobrir tudo isso exige uma verdadeira investigação forense.

---

Jobtrac

O Jobtrac costuma esconder sua complexidade atrás de uma aparência simples.

Mas muitas vezes existem décadas de exceções acumuladas.

São justamente essas exceções que costumam quebrar durante a migração.

---

Zeke e Zebb

Veteranos do Mainframe conhecem bem esses nomes.

Ainda existem ambientes gigantescos executando processos críticos através deles.

Frequentemente acompanhados de:

• CLISTs

• REXX

• Ferramentas locais

• Automatizações artesanais

São ambientes extremamente poderosos, porém fortemente dependentes de conhecimento histórico.

---

O IBM z17 Muda o Jogo

A chegada do IBM z17 cria uma nova realidade operacional.

Mais CPU.

Mais memória.

Mais paralelismo.

Mais integração com IA.

Mais observabilidade.

Mais automação.

Porém existe um efeito curioso.

Problemas antigos tornam-se mais visíveis.

Jobs que antes eram executados de forma sequencial agora podem disputar recursos simultaneamente.

Dependências mal definidas aparecem.

Gargalos históricos tornam-se evidentes.

O z17 não cria os problemas.

Ele apenas ilumina problemas que sempre existiram.

---

A Descoberta de Dependências

A etapa mais importante de toda migração.

Muitos especialistas consideram essa fase mais importante do que a própria conversão.

O objetivo é responder uma pergunta simples:

"O que realmente depende do quê?"

Parece fácil.

Mas não é.

---

Análise Profunda de JCL

O JCL é um mapa oculto de dependências.

Um IF/THEN pode alterar completamente o fluxo operacional.

Um COND pode impedir a execução de dezenas de etapas.

Uma simples alteração de RC pode desencadear comportamentos inesperados.

Por isso a análise moderna precisa identificar:

• EXEC

• PROC

• INCLUDE

• IF/THEN/ELSE

• COND

• Restart Points

Tudo isso influencia diretamente a modelagem do scheduler.

---

O Poder dos Datasets

Datasets contam histórias.

Um arquivo criado por um job normalmente será consumido por outro.

Mapear essas relações permite construir um grafo operacional real.

Em grandes bancos encontramos:

• Centenas de milhares de datasets

• Milhares de GDGs

• Dependências cruzadas

Muitas vezes o scheduler original utilizava apenas o dataset como mecanismo de sincronização.

Se isso não for identificado, a migração falha.

Dataset Flow

Mapeamento de:

//OUTFILE DD DSN=FIN.ARQ.SAIDA

para

//INFILE DD DSN=FIN.ARQ.SAIDA

Criando uma cadeia real de dependências.

---

GDGs

Muitas dependências estão escondidas em:

DSN=ARQ.CLIENTE(+1)

ou

DSN=ARQ.CLIENTE(0)

O scheduler antigo pode usar triggering baseado nesses datasets.

---

Catalog Search

Análise de:

• ICF Catalog
• SMS
• GDG Bases

para descobrir relacionamentos não documentados.

---

O Mundo Esquecido do TSO/ISPF

Aqui mora uma das maiores armadilhas.

Muitas organizações acreditam que todos os jobs passam pelo scheduler.

Nem sempre.

Existem submissões originadas por:

• REXX

• CLIST

• Painéis ISPF

• Skeletons

• Ferramentas internas

Às vezes um usuário executa um painel ISPF que gera JCL dinamicamente.

Esse JCL dispara outros jobs.

Que disparam outros processos.

E nada disso aparece claramente no scheduler.

É por isso que uma análise séria precisa incluir todo o ecossistema TSO/ISPF.

---

Engenharia Reversa do Batch

A migração moderna exige construir um mapa completo do ambiente.

Imagine visualizar:

• 30.000 jobs

• 50.000 dependências

• 10.000 datasets

• 500 calendários

Tudo conectado.

Esse mapa permite identificar:

• Gargalos

• Loops

• Dependências órfãs

• Processos redundantes

Muitas empresas descobrem pela primeira vez como seu batch realmente funciona.

Engenharia Reversa de Dependências

Ferramentas modernas constroem grafos completos.

Exemplo:

PAYROLL
 ├── EMPLOYEE
 ├── BENEFITS
 ├── TAX
 └── REPORTS

O desafio passa a ser visualizar.

Não apenas converter.

---

Parallel Tracking: A Fase da Verdade

Nenhum projeto sério faz o corte diretamente.

Primeiro vem o Parallel Tracking.

O scheduler antigo continua operando.

O novo acompanha silenciosamente.

Comparando:

• Horários

• Dependências

• Eventos

• Return Codes

A cada divergência surge uma oportunidade de aprendizado.

Essa fase costuma revelar dezenas ou centenas de inconsistências que jamais haviam sido percebidas.

Comparar resultados.

---

Fase 1

Somente observação.

IWS simula.

Não dispara nada.

---

Fase 2

Shadow Execution.

IWS acompanha:

• Start times
• End times
• RCs

---

Fase 3

Controlled Production

Parte da carga executa pelo novo scheduler.

Parte pelo antigo.

---

Fase 4

Cutover

Desligamento definitivo.

---

Validação de Schedules

Uma validação madura verifica:

Calendários

Dias úteis.

Feriados.

Fechamentos.

Ano fiscal.

---

Dependências

Job predecessor.

Successor.

Conditional logic.

---

Eventos

Arquivo recebido.

Dataset criado.

Mensagem emitida.

RC específico.

---

SLA

O scheduler novo deve cumprir:

• Tempo de início
• Tempo de término
• Deadline 

---

Os Erros Clássicos

Após participar de inúmeros projetos, alguns padrões se repetem.

Job Não Dispara

Normalmente causado por dependência esquecida.

Job Dispara Antes

Calendário incorreto.

Trigger Perdido

Dataset mudou de nome.

Dependência Fantasma

Job espera algo que já não existe.

Loop Operacional

Um job espera outro.

Que espera o primeiro.

Resultado:

Nada acontece.

---

O Papel do Troubleshooting Moderno

No passado, investigar problemas exigia navegar por:

• JESMSGLG

• JESJCL

• SYSLOG

• SDSF

Hoje o cenário mudou.

Ferramentas modernas permitem correlacionar:

• Eventos

• Dependências

• Métricas

• Logs

• Consumo de recursos

Tudo em tempo real.

Os incidentes mais comuns são:

---

Job Não Dispara

Causa:

Dependência perdida.

Exemplo:

Dataset trigger não convertido.

---

Job Dispara Antes da Hora

Causa:

Calendário incorreto.

---

Loop de Dependência

Muito comum.

Exemplo:

JOBA espera JOBB
JOBB espera JOBA

Deadlock operacional.

---

Dependência Fantasma

Job espera um predecessor que já não existe.

Foi removido anos atrás.

Mas continua cadastrado.

---

Dataset Nunca Criado

Erro clássico.

JCL correto.

Scheduler correto.

Mas o dataset trigger mudou de nome.

---

Observabilidade no IBM z17

O verdadeiro salto ocorre quando o IWS passa a conversar com ferramentas modernas.

OMEGAMON.

RMF.

SMF.

Instana.

IBM Z Operations Analytics.

Z APM Connect.

Agora é possível enxergar:

• Fluxos completos

• Tendências

• Crescimento da janela batch

• Jobs reincidentes

• Processos problemáticos

Não estamos mais falando apenas de scheduling.

Estamos falando de inteligência operacional.

---

A Chegada da Inteligência Artificial

Talvez a transformação mais interessante dos próximos anos.

Imagine um ambiente capaz de identificar:

• Dependências suspeitas

• Calendários inconsistentes

• Tendências de atraso

• Possíveis violações de SLA

antes que o problema aconteça.

Com o z17, essa visão deixa de ser ficção.

A IA passa a atuar como um analista operacional virtual.

Monitorando milhares de eventos simultaneamente.

Detectando padrões invisíveis ao ser humano.

---

O Verdadeiro Objetivo da Migração

O maior erro é tratar a migração como substituição de software.

Não é.

A migração é uma oportunidade rara.

Uma oportunidade de documentar décadas de conhecimento.

De eliminar dependências obsoletas.

De corrigir erros históricos.

De modernizar processos.

De criar governança.

De preparar o ambiente para os próximos vinte anos.

---

Conclusão: O Scheduler Nunca Foi Apenas um Scheduler

Ao final de uma grande migração, muitas equipes chegam à mesma conclusão.

O problema nunca foi o CA-7.

Nunca foi o Control-M.

Nunca foi o ESP.

Nunca foi o Jobtrac.

Nunca foi o Zeke.

O verdadeiro desafio sempre foi compreender o ecossistema invisível que sustenta a operação.

Porque dentro de cada scheduler existe muito mais do que jobs.

Existem décadas de decisões.

Décadas de conhecimento.

Décadas de regras de negócio.

Décadas de experiência operacional.

E quando uma organização decide migrar para IBM Z Workload Scheduler em um moderno IBM z17, ela não está apenas trocando uma ferramenta.

Ela está reconstruindo o mapa que conecta toda a empresa.

E talvez essa seja a maior descoberta de todas.

O scheduler não controla apenas jobs.

Ele controla o tempo.

E, dentro de uma grande corporação, tempo é exatamente aquilo que mantém o negócio vivo.

Bellacosa Mainframe e a lista de animes com tematica de dungeons

 

⚔️ Lista Bellacosa – Fantasia Medieval com Dungeon (Parte 2 – 21 a 50)

O anime de fantasia medieval com dungeon é, essencialmente, um sistema legado perfeitamente funcional: antigo, perigoso e cheio de regras que não perdoam erro. A dungeon é o coração desse mundo. Um ambiente fechado, hostil e previsível só na teoria. Na prática, é um labirinto de exceções, armadilhas e monstros que testam mais a mente do que a espada.

Psicologicamente, a dungeon funciona como um processo de validação. Cada andar é um nível de maturidade. Quem entra despreparado sofre dump imediato. Não há espaço para heroísmo vazio; sobrevivem os metódicos, os observadores, os que aprendem com cada tentativa falha. É grind puro, como rodar batch noturno esperando o relatório final.

A fantasia medieval fornece o pano de fundo: guildas, reis distantes, economias simples e leis duras. Mas é dentro da dungeon que os personagens revelam quem realmente são. Medo, ganância, altruísmo e traição aparecem sem filtro. O grupo precisa funcionar como um sistema distribuído: tanque, suporte, dano — se um falha, tudo cai.

Esses animes não falam só de aventura, mas de disciplina e consequência. A dungeon não é vilã; é o teste. Ela não odeia o herói, apenas executa as regras. Igual ao mainframe: está lá para rodar. Quem entende o sistema prospera. Quem subestima… vira loot.

---

 

21. Sword Art Online (2012)

• Sinopse: Jogadores presos em MMORPG precisam vencer andares de dungeon para sobreviver.

• Ano: 2012

• Curiosidade: Popularizou o subgênero isekai gamer.

• Dica: Ótimo ponto de entrada para novatos.

• Notas visuais: Brilhante, com design de RPG digital.

---

22. Log Horizon (2013)

• Sinopse: Jogadores ficam presos em Elder Tale e precisam reconstruir a sociedade.

• Ano: 2013

• Curiosidade: Focado em política e guildas.

• Dica: Para fãs de estratégia + fantasia.

• Notas visuais: Medieval digital, mais sóbrio que SAO.

---

23. Rage of Bahamut: Genesis (2014)

• Sinopse: Aventureiros caçam deuses e demônios em mundo caótico.

• Ano: 2014

• Curiosidade: Baseado em card game.

• Dica: Boa mistura de ação + mitologia.

• Notas visuais: Arte cinematográfica.

---

24. Akame ga Kill! (2014)

• Sinopse: Tatsumi entra em guilda de assassinos em império corrompido.

• Ano: 2014

• Curiosidade: Conhecido por mortes chocantes.

• Dica: Para fãs de dark medieval.

• Notas visuais: Medieval sangrento, batalhas intensas.

---

25. Chain Chronicle (2014)

• Sinopse: Heróis enfrentam Black Army em mundo de RPG.

• Ano: 2014

• Curiosidade: Baseado em mobile game.

• Dica: Estilo clássico de grupo de aventureiros.

• Notas visuais: Fantasia vibrante.

---

26. Gate: Jieitai Kanochi nite (2015)

• Sinopse: Exército moderno invade mundo medieval com dragões e magos.

• Ano: 2015

• Curiosidade: Mistura militarismo + fantasia.

• Dica: Para fãs de contraste tecnologia vs magia.

• Notas visuais: Medieval com tanks.

---

27. Rokka no Yuusha (2015)

• Sinopse: Seis guerreiros escolhidos para enfrentar o Rei Demônio desconfiam de um traidor.

• Ano: 2015

• Curiosidade: Mistura mistério + fantasia.

• Dica: Para fãs de whodunit medieval.

• Notas visuais: Medieval vibrante, inspirado em civilizações maias.

---

28. Drifters (2016)

• Sinopse: Heróis históricos são convocados para lutar em mundo medieval.

• Ano: 2016

• Curiosidade: Do mesmo autor de Hellsing.

• Dica: Para fãs de guerra épica.

• Notas visuais: Estilo sombrio, traço forte.

---

29. Tales of Zestiria the X (2016)

• Sinopse: Sorey e Mikleo exploram templos e enfrentam corrupção mágica.

• Ano: 2016

• Curiosidade: Baseado em JRPG da Bandai Namco.

• Dica: Para fãs de arte caprichada.

• Notas visuais: Cenários deslumbrantes.

---

30. Grancrest Senki (2018)

• Sinopse: Guerreiro e maga tentam unificar reinos divididos.

• Ano: 2018

• Curiosidade: Do autor de Record of Lodoss War.

• Dica: Fantasia política + ação.

• Notas visuais: Medieval clássico.

---

31. Goblin Slayer (2018)

• Sinopse: Aventureiro sem nome caça goblins em dungeons brutais.

• Ano: 2018

• Curiosidade: Polêmico pelo 1º episódio.

• Dica: Dark fantasy pesada.

• Notas visuais: Realismo medieval sombrio.

---

32. Dungeons & Dragons (1983, anime ocidental japonês)

• Sinopse: Crianças vão parar em reino medieval e enfrentam o Vingador.

• Ano: 1983

• Curiosidade: Coprodução EUA-Japão.

• Dica: Nostalgia para RPGistas.

• Notas visuais: Estilo cartoon medieval.

---

33. Sorcerous Stabber Orphen (2019 remake)

• Sinopse: Orphen tenta salvar amiga transformada em monstro.

• Ano: 2019

• Curiosidade: Versão moderna mais fiel à novel.

• Dica: Para fãs de remakes sérios.

• Notas visuais: Medieval retrabalhado.

---

34. Somali and the Forest Spirit (2020)

• Sinopse: Golem cuida de menina humana em mundo dominado por criaturas mágicas.

• Ano: 2020

• Curiosidade: Não há dungeons clássicas, mas sim aventuras míticas.

• Dica: Mais emocional que épico.

• Notas visuais: Atmosfera de conto de fadas.

---

35. Cautious Hero (2019)

• Sinopse: Herói overpower, mas obcecado com preparação, explora dungeons com deusa Ristarte.

• Ano: 2019

• Curiosidade: De comédia vira épico dramático.

• Dica: Mistura leve e pesada.

• Notas visuais: Medieval colorido.

---

36. The Faraway Paladin (2021)

• Sinopse: Humano criado por mortos-vivos heróis busca redenção.

• Ano: 2021

• Curiosidade: História lenta e espiritual.

• Dica: Para quem gosta de worldbuilding profundo.

• Notas visuais: Fantasia clássica, tom melancólico.

---

37. Jobless Reincarnation (Mushoku Tensei, 2021)

• Sinopse: Rudeus reencarna em mundo mágico e explora com poder crescente.

• Ano: 2021

• Curiosidade: Considerado “pai do isekai moderno”.

• Dica: Fantasia séria e completa.

• Notas visuais: Medieval detalhado e lindo.

---

38. Record of Ragnarok (2021)

• Sinopse: Deuses enfrentam campeões humanos em torneio épico.

• Ano: 2021

• Curiosidade: Mistura mitologia mundial.

• Dica: Não é dungeon, mas fantasia medieval.

• Notas visuais: Estilo mangá bruto.

---

39. Skeleton Knight in Another World (2022)

• Sinopse: Jogador preso em corpo de esqueleto guerreiro vive aventuras.

• Ano: 2022

• Curiosidade: Lembra Overlord, mas mais light.

• Dica: Para fãs de humor + ação.

• Notas visuais: Armaduras brilhantes.

---

40. Bastard!! Remake (2022)

• Sinopse: Dark Schneider retorna em nova versão da sua busca por poder.

• Ano: 2022

• Curiosidade: Anime da Netflix.

• Dica: Fantasia sombria + heavy metal.

• Notas visuais: Medieval estiloso, dark.

---

41. Reincarnated as a Sword (2022)

• Sinopse: Homem vira espada e treina jovem guerreira.

• Ano: 2022

• Curiosidade: Subverte fórmula do herói humano.

• Dica: Boa pedida para quem gosta de ação divertida.

• Notas visuais: Colorido, medieval vibrante.

---

42. Handyman Saitou in Another World (2023)

• Sinopse: Saitou, um faz-tudo, ganha utilidade em grupo de aventureiros em dungeons.

• Ano: 2023

• Curiosidade: Destaque para habilidades não-combativas.

• Dica: Alternativa leve e única.

• Notas visuais: Medieval simples e aconchegante.

---

43. Frieren: Beyond Journey’s End (2023)

• Sinopse: Elfa maga revive memórias de aventuras e busca novos significados.

• Ano: 2023

• Curiosidade: Considerado um clássico moderno.

• Dica: Para fãs de introspecção + fantasia.

• Notas visuais: Lindo, melancólico, aquarela.

---

44. Delicious in Dungeon (Dungeon Meshi, 2024)

• Sinopse: Aventureiros cozinham monstros enquanto exploram dungeons.

• Ano: 2024

• Curiosidade: Mistura culinária + RPG.

• Dica: Para quem gosta de humor + criatividade.

• Notas visuais: Detalhado, colorido, gourmet.

---

45. Re:Monster (2024)

• Sinopse: Homem renasce como goblin e sobe na cadeia alimentar em dungeons.

• Ano: 2024

• Curiosidade: Protagonista “monstro”.

• Dica: Para fãs de evolução OP.

• Notas visuais: Dark mas chamativo.

---

46. Suicide Squad Isekai (2024)

• Sinopse: Vilões da DC presos em mundo medieval com monstros.

• Ano: 2024

• Curiosidade: Mistura inédita de comics + isekai.

• Dica: Para fãs de crossovers.

• Notas visuais: Fantasia estilizada.

---

47. A Gatherer’s Adventure in Isekai (2025)

• Sinopse: Protagonista sobrevive coletando recursos em masmorras e florestas.

• Ano: 2025

• Curiosidade: Mais slice of life que ação.

• Dica: Para fãs de crafting.

• Notas visuais: Estilo relax.

---

48. Apocalypse Bringer Mynoghra (2025)

• Sinopse: Homem reencarna como deus destruidor e cria império das trevas.

• Ano: 2025

• Curiosidade: Lembra Overlord.

• Dica: Para fãs de dark + construção de reinos.

• Notas visuais: Sombrio, eldritch.

---

49. The Red Ranger Becomes an Adventurer in Another World (2025)

• Sinopse: Sentai vermelho transportado a mundo medieval com dungeons.

• Ano: 2025

• Curiosidade: Mistura tokusatsu + RPG.

• Dica: Curiosidade rara, ótimo para pioneiros.

• Notas visuais: Brilhante e nostálgico.

---

50. I’m the Evil Lord of an Intergalactic Empire! (2025)

• Sinopse: Homem reencarna como vilão em império cósmico medievalizado.

• Ano: 2025

• Curiosidade: Sci-fi + fantasia medieval.

• Dica: Para quem gosta de Maou + harém futurista.

• Notas visuais: Mistura espaço + reinos.

---

⚔️ Resumo e conclusão.

Os animes de fantasia medieval com romance combinam dois elementos que conquistam fãs há décadas: aventuras épicas em mundos mágicos e relacionamentos emocionais que evoluem ao longo da jornada. Inspirados por mitologias, RPGs, contos de fadas e literatura fantástica, esses animes transportam o público para reinos repletos de magia, cavaleiros, monstros, dragões e conflitos políticos.

O romance normalmente surge em meio a batalhas, missões perigosas e desafios que aproximam os personagens. Diferentemente das histórias românticas tradicionais, o relacionamento costuma crescer enquanto os protagonistas enfrentam guerras, jornadas heroicas e descobertas pessoais. Isso cria uma conexão emocional mais profunda entre os personagens e o espectador.

Obras como Akagami no Shirayuki-hime, Spice and Wolf, The Ancient Magus’ Bride, Yona of the Dawn, Record of Grancrest War, Banished from the Hero’s Party, The World is Still Beautiful, Maoyuu Maou Yuusha, Snow White with the Red Hair e Frieren representam bem essa combinação entre fantasia e sentimentos.

Além do romance, esses animes exploram amizade, amadurecimento, sacrifício e a construção de laços em cenários muitas vezes marcados por guerras e disputas de poder. O resultado são histórias que equilibram ação, emoção e fantasia.

Por isso, a fantasia medieval romântica continua sendo uma das vertentes mais populares dos animes, oferecendo aventuras grandiosas sem abrir mão do desenvolvimento humano e afetivo dos personagens.

PADAWAN, O PROBLEMA NÃO ESTÁ ONDE O ABEND ACONTECEU! Executando Root Cause Analysis (RCA) em Ambiente Mainframe

Bellacosa Mainframe e root cause analysis

☕💣🚨 PADAWAN, O PROBLEMA NÃO ESTÁ ONDE O ABEND ACONTECEU!

Executando Root Cause Analysis (RCA) em Ambiente Mainframe

Como Encontrar a Verdadeira Causa do Incidente e Não Apenas o Sintoma

Uma das maiores armadilhas no mundo Mainframe é acreditar que o erro está exatamente onde ele apareceu.

O operador vê um S0C7.

O desenvolvedor vê um SQLCODE -911.

O analista vê um JOB FAILED.

O gerente vê um SLA perdido.

Mas o verdadeiro culpado pode estar escondido horas, dias ou até semanas antes do incidente.

É exatamente para isso que existe a Root Cause Analysis (RCA).

---

O Que é Root Cause Analysis?

Root Cause Analysis é um processo estruturado utilizado para descobrir:

• O que aconteceu

• Por que aconteceu

• Como aconteceu

• Como impedir que aconteça novamente

O objetivo NÃO é:

❌ Encontrar culpados

O objetivo é:

✅ Encontrar causas

Existe uma enorme diferença entre:

Sintoma

e

Causa Raiz

Exemplo:

Sintoma:

JOB ABC123 ABEND S0C7

Causa raiz:

Arquivo recebido com campo numérico inválido

Sem RCA você corrige o programa.

Com RCA você corrige o processo.

---

O Modelo Bellacosa de RCA

Costumo ensinar que a investigação deve seguir 5 perguntas:

1. O que falhou?
2. Onde falhou?
3. Quando começou?
4. O que mudou?
5. Qual evento iniciou a cadeia?

A quinta pergunta normalmente encontra a causa raiz.

---

Caso Real Simulado

Imagine o seguinte cenário:

Às 03:15 da manhã:

JOB FINPAY01
ABEND S0C7

Sistema financeiro parado.

Pagamento não processado.

Telefone do plantão toca.

Você entra na guerra.

---

Passo 1 – Não Entre em Pânico

Primeiro erro dos iniciantes:

ABEND → Corrigir programa

Errado.

Primeiro precisamos coletar evidências.

---

Passo 2 – Capturar Informações Básicas

Anote:

Job Name
Step Name
Programa
Hora
Sistema
Código de retorno

Exemplo:

JOB:
FINPAY01

STEP:
CALCPAY

PROGRAMA:
PAYROLL

ABEND:
S0C7

HORA:
03:15

Agora temos o ponto inicial.

---

Passo 3 – Analisar JESMSGLG

Abrir:

SDSF
ST
?

Verificar:

JESMSGLG

Perguntas:

• Houve mensagens antes do abend?

• Dataset estava disponível?

• Houve timeout?

• Houve atraso?

Exemplo:

RECORD READ SUCCESSFULLY

Logo antes do erro:

INVALID DATA DETECTED

Primeira pista encontrada.

---

Passo 4 – Analisar SYSOUT

Agora olhamos:

SYSOUT
SYSPRINT
SYSUDUMP
CEEDUMP

Dependendo da aplicação.

Encontramos:

FIELD SALARY
VALUE = ABC123

O campo deveria ser numérico.

---

Passo 5 – Confirmar no Dump

No dump:

OFFSET X'03A2'

Instrução:

PACK

O programa tentou converter:

ABC123

para número.

Resultado:

S0C7

Até aqui temos:

O QUE aconteceu

Mas ainda não temos:

POR QUE aconteceu

---

Erro Comum da Equipe

Muitas equipes param aqui.

Produzem um relatório:

Causa:
Campo inválido.

Isso NÃO é RCA.

Isso é apenas descrição do sintoma.

---

Passo 6 – Rastrear a Origem do Dado

Pergunta:

Quem criou esse registro?

Abrimos o fluxo.

FINPAY01
↓
FINLOAD
↓
FTPIN
↓
Arquivo Externo

Agora começamos a enxergar a cadeia de eventos.

---

Passo 7 – Reconstruir a Linha do Tempo

Uma RCA boa sempre monta uma timeline.

01:00 Arquivo recebido

01:05 FTP concluído

01:10 Processo de carga

03:15 Abende S0C7

Agora investigamos:

O que mudou entre ontem e hoje?

---

Passo 8 – Procurar Mudanças

A pergunta mais poderosa da RCA:

O que mudou?

90% dos incidentes começam aqui.

Verificamos:

• Mudança de software

• Novo fornecedor

• Nova versão

• Alteração de layout

• Mudança de parâmetro

Descobrimos:

Fornecedor alterou layout do arquivo

Ontem:

SALARY PIC 9(8)

Hoje:

SALARY PIC X(8)

E começou a enviar:

ABC123

---

Finalmente Encontramos a Causa Raiz

Sintoma:

S0C7

Causa imediata:

Campo não numérico

Causa raiz:

Mudança de layout
não comunicada
pelo fornecedor

Agora sim temos RCA.

---

Técnica dos 5 Porquês

Muito utilizada em bancos e seguradoras.

Pergunte repetidamente:

Por que houve S0C7?

Porque havia valor inválido.

Por que havia valor inválido?

Porque o campo veio alfanumérico.

Por que veio alfanumérico?

Porque o layout mudou.

Por que o layout mudou?

Porque fornecedor implantou nova versão.

Por que ninguém percebeu?

Porque não existia validação de layout.

Causa raiz:

Ausência de validação contratual
do arquivo recebido

Observe:

Não era COBOL.

Não era Mainframe.

Não era operador.

Era falha de processo.

---

Técnica do Diagrama de Ishikawa

Também chamado:

Fishbone Diagram

Categorias comuns:

Pessoas
Processos
Tecnologia
Dados
Infraestrutura
Mudanças

Exemplo:

S0C7
│
├── Dados
│   └ Campo inválido
│
├── Processo
│   └ Sem validação
│
├── Mudança
│   └ Layout alterado
│
└── Governança
    └ Sem comunicação

Esse modelo é excelente para incidentes complexos.

---

RCA em Problemas de Performance

Outro exemplo.

Sintoma:

Batch passou de
20 minutos para 4 horas

Investigação:

CPU normal

Memória normal

I/O elevado

Descoberta:

Índice DB2 ficou REORG pendente

Sintoma:

Batch lento

Causa raiz:

Janela de manutenção não executada

Novamente:

A causa raiz não era o batch.

---

RCA em Problemas de CICS

Sintoma:

AICA

Timeout.

Investigação:

CICS esperando DB2

DB2 esperando:

Lock

Lock causado por:

Batch noturno

Batch preso por:

Dataset indisponível

Causa raiz:

Dataset não montado

O AICA era apenas o último dominó da cadeia.

---

Estrutura de um Relatório RCA Profissional

INCIDENTE:
Batch FINPAY01 falhou.

IMPACTO:
Pagamento não processado.

SINTOMA:
ABEND S0C7.

CAUSA IMEDIATA:
Campo SALARY inválido.

CAUSA RAIZ:
Fornecedor alterou layout sem aviso.

AÇÃO CORRETIVA:
Correção do layout.

AÇÃO PREVENTIVA:
Validação automática de arquivo.

RESPONSÁVEL:
Equipe de Integração.

PRAZO:
15 dias.

---

O Segredo dos Grandes Especialistas Mainframe

Os profissionais mais experientes não são aqueles que sabem mais comandos.

São aqueles que conseguem responder:

Por que isso aconteceu?

Porque o verdadeiro trabalho de um especialista não é apagar incêndios.

É descobrir quem acendeu o fósforo.

Quando você domina RCA, deixa de ser apenas alguém que resolve abends e passa a ser alguém que elimina problemas da raiz, reduz incidentes recorrentes e se torna uma das pessoas mais valiosas dentro da operação Mainframe.

E é exatamente nesse momento que você deixa de ser um simples operador de mensagens e passa a pensar como um verdadeiro detetive de sistemas IBM Z. ☕🚀🔎

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." ☕💣🚨