Bellacosa Mainframe a arte da guerra contra o caos conheça o RCA

☕🔥💣 O SYSprog PADAWAN E A ARTE DA GUERRA CONTRA O CAOS

Root Cause Analysis no IBM Mainframe: Por Que Reiniciar o CICS Não Resolve Seus Problemas

Existe uma frase muito comum nos corredores dos data centers:

"Reinicia que volta."

Durante décadas ela funcionou.

O CICS travou?

Reinicia.

O batch falhou?

Roda de novo.

O MQ congestionou?

Dá STOP e START.

O JES2 ficou estranho?

Cancela alguns jobs.

O storage explodiu?

Aumenta a região.

O problema é que essa mentalidade criou gerações de profissionais especialistas em apagar incêndios, mas não necessariamente especialistas em eliminar incêndios.

E existe uma diferença gigantesca entre as duas coisas.

O verdadeiro profissional de Mainframe moderno não é aquele que resolve o incidente mais rápido.

É aquele que garante que o incidente nunca mais aconteça.

É aí que entra uma das disciplinas mais importantes da engenharia moderna:

Root Cause Analysis (RCA)

Ou, em português:

Análise de Causa Raiz

Uma habilidade que separa o operador comum do engenheiro de confiabilidade.

---

O INCIDENTE NÃO É O PROBLEMA

Este é talvez o conceito mais importante de todo o artigo.

Quando um sistema cai, aquilo que você vê não é o problema.

É apenas a consequência visível.

Imagine uma transação CICS que começa a responder lentamente.

O usuário reclama.

O suporte abre um chamado.

O operador percebe aumento de CPU.

O time de infraestrutura aumenta recursos.

Tudo parece resolvido.

Mas alguns dias depois o problema volta.

Por quê?

Porque ninguém investigou a causa raiz.

A lentidão era apenas um sintoma.

O problema verdadeiro talvez fosse:

• SQL ineficiente

• Índice DB2 corrompido

• Loop em programa COBOL

• Fila MQ congestionada

• Deadlock de recursos

• Automação mal configurada

Resolver o sintoma gera alívio.

Resolver a causa gera evolução.

---

O MAIOR PECADO DA TI MODERNA

A Harvard Business Review publicou um estudo mostrando que a maioria dos executivos acredita que suas organizações são ruins em diagnosticar problemas.

Isso não surpreende.

A cultura corporativa moderna recompensa velocidade.

Poucas vezes recompensa investigação.

A pressão é sempre:

"Volta o sistema agora."

Raramente alguém pergunta:

"Por que ele caiu?"

E menos ainda:

"Como impedimos que isso aconteça novamente?"

---

O DETETIVE DIGITAL

Um bom profissional de RCA pensa como um investigador.

Quando ocorre uma falha ele não procura imediatamente uma solução.

Primeiro procura evidências.

Ele coleta:

• SYSLOG

• JESMSGLG

• SMF

• RMF

• Dumps

• Traces

• Mensagens CICS

• Logs DB2

• Eventos MQ

• Métricas OMEGAMON

Cada informação conta parte da história.

Nenhum log isolado revela a verdade completa.

O segredo está na correlação.

---

O CASO DO BATCH QUE ATRASAVA TODA SEXTA-FEIRA

Vamos analisar um exemplo realista.

Toda sexta-feira o processamento noturno atrasava duas horas.

A primeira reação foi aumentar os initiators JES2.

Funcionou por algumas semanas.

Depois o atraso voltou.

Nova tentativa:

Mais CPU.

Mais memória.

Mais canais.

Nada resolveu.

Quando uma análise de causa raiz foi finalmente realizada, descobriu-se que um programa COBOL executava uma consulta DB2 sem índice adequado.

Toda sexta-feira havia crescimento no volume de dados.

A consulta que normalmente levava segundos passava a consumir minutos.

Um único SQL provocava efeito cascata em dezenas de jobs dependentes.

A verdadeira solução não foi comprar hardware.

Foi corrigir um SQL.

---

O MÉTODO DOS CINCO PORQUÊS

Uma técnica clássica de RCA é conhecida como:

Five Whys

Cinco Porquês.

Exemplo:

Problema:

Batch falhou.

Por quê?

Dataset estava bloqueado.

Por quê?

Outro job mantinha ENQ.

Por quê?

Entrou em loop.

Por quê?

SQL aguardava retries.

Por quê?

Índice DB2 estava inconsistente.

Agora temos a causa raiz.

Observe que a resposta verdadeira apareceu apenas após várias camadas de investigação.

---

O INIMIGO INVISÍVEL CHAMADO CULTURA

Muitas vezes a causa raiz não está no software.

Nem no hardware.

Nem na rede.

Está nas pessoas.

Considere o seguinte cenário.

Um deploy derruba produção.

A primeira conclusão costuma ser:

"O desenvolvedor errou."

Mas uma análise profunda pode revelar:

• Prazo impossível

• Falta de testes

• Ausência de homologação

• Pressão da gestão

• Processo de aprovação falho

O erro humano foi apenas o último elo da corrente.

A verdadeira falha estava no sistema organizacional.

---

O MODELO DE CONGRUÊNCIA

Uma abordagem extremamente interessante utilizada em liderança organizacional é o Modelo de Congruência.

Ele analisa cinco dimensões:

Trabalho

O que precisa ser feito?

Dependências

Quem depende de quem?

Capacidades

As pessoas possuem conhecimento suficiente?

Estrutura

A organização facilita ou dificulta o trabalho?

Cultura

Os comportamentos desejados são incentivados?

No Mainframe isso é extremamente aplicável.

Não adianta investir milhões em Z17 se:

• a equipe não recebe treinamento

• a documentação está desatualizada

• os processos são confusos

• ninguém entende as integrações

---

O MAINFRAME MODERNO É UM ECOSSISTEMA

Nos anos 80 era relativamente fácil identificar falhas.

Hoje um único fluxo pode envolver:

• COBOL

• CICS

• DB2

• MQ

• APIs REST

• Kafka

• Cloud

• Linux on Z

• Zowe

• DevOps

A causa raiz pode estar em qualquer lugar.

Ou em vários lugares simultaneamente.

Por isso a investigação precisa ser sistêmica.

---

A ARMADILHA DO "SEMPRE FOI ASSIM"

Uma das causas mais perigosas de incidentes recorrentes é a complacência.

Frases famosas:

"Isso acontece às vezes."

"Sempre fizemos assim."

"Nunca deu problema."

São frases que deveriam acender alertas imediatos.

Porque normalmente escondem riscos acumulados durante anos.

---

COMO REALIZAR UM RCA NO MAINFRAME

Passo 1 — Definir o Problema

Não investigue algo genérico.

Errado:

"O sistema está ruim."

Correto:

"O CICS CICSPRD apresentou aumento de resposta de 0,3 para 8 segundos entre 14h e 15h."

Problemas bem definidos geram investigações eficientes.

---

Passo 2 — Coletar Evidências

Reúna:

• logs

• métricas

• dumps

• relatórios

• eventos

Sem dados você possui apenas opiniões.

---

Passo 3 — Construir a Linha do Tempo

Pergunte:

O que aconteceu primeiro?

O que aconteceu depois?

Qual evento precedeu a falha?

Muitas causas aparecem quando organizamos os fatos cronologicamente.

---

Passo 4 — Correlacionar Eventos

Um erro aparentemente isolado pode estar conectado a dezenas de outros eventos.

O desafio é encontrar essas relações.

---

Passo 5 — Aplicar os Cinco Porquês

Continue perguntando:

Por quê?

Até chegar à origem.

---

Passo 6 — Validar a Hipótese

A hipótese precisa ser comprovada.

Não basta parecer correta.

Ela deve explicar:

• o incidente

• os sintomas

• a recorrência

---

Passo 7 — Criar Plano de Ação

A correção deve:

• eliminar a causa

• reduzir riscos

• ser mensurável

---

FERRAMENTAS ESSENCIAIS PARA RCA NO Z/OS

RMF

Identifica gargalos de performance.

SMF

Registra praticamente tudo que acontece.

IPCS

Análise de dumps.

OMEGAMON

Observabilidade avançada.

SDSF

Investigação operacional.

NetView

Correlação de eventos.

System Automation

Automação e recuperação.

JES2

Análise de filas, execução e spool.

---

O FUTURO: AIOPS E RCA AUTOMATIZADO

Estamos entrando em uma era fascinante.

Ferramentas modernas conseguem:

• detectar anomalias

• prever falhas

• correlacionar eventos

• sugerir causas prováveis

AIOps não substitui o analista.

Mas amplifica sua capacidade.

O profissional moderno utilizará IA para acelerar investigações complexas.

---

ONDE A MAIORIA DAS EMPRESAS ERRA

As falhas mais comuns são:

Falta de documentação

Sem histórico não existe aprendizado.

Ausência de postmortem

O incidente é resolvido e esquecido.

Busca por culpados

Pessoas escondem erros quando temem punição.

Falta de métricas

Sem observabilidade não existe RCA.

Correções paliativas

Workarounds substituem soluções definitivas.

---

COMO EVOLUIR SUA ORGANIZAÇÃO

Empresas maduras desenvolvem cultura de aprendizado.

Após cada incidente perguntam:

• O que aconteceu?

• Por que aconteceu?

• Como detectamos?

• Como evitaremos recorrência?

• O que aprendemos?

Essa simples mudança transforma organizações.

---

O SYSprog PADAWAN E O MESTRE

O Padawan reinicia.

O Mestre investiga.

O Padawan fecha chamados.

O Mestre elimina problemas.

O Padawan trata sintomas.

O Mestre trata causas.

O Padawan celebra quando o sistema volta.

O Mestre celebra quando o sistema não cai novamente.

Essa é a verdadeira evolução profissional.

---

CONCLUSÃO

Root Cause Analysis não é apenas uma metodologia.

É uma filosofia.

É a diferença entre sobreviver e evoluir.

No mundo do IBM Z17, DevOps, observabilidade, automação e inteligência artificial, a capacidade de descobrir a causa raiz tornou-se uma das habilidades mais valiosas da engenharia moderna.

Porque reiniciar um sistema pode resolver um incidente.

Mas apenas entender a causa raiz pode impedir que ele volte.

E é exatamente isso que separa um operador de console de um arquiteto da estabilidade.

No final das contas, o verdadeiro inimigo nunca foi o abend.

Nunca foi o dump.

Nunca foi o job cancelado.

O verdadeiro inimigo sempre foi aquilo que ninguém investigou.

 

Bellacosa Mainframe e root cause analysis em Mainframe

---

☕🔥💣 “O SYSprog PADAWAN E A ARTE DA GUERRA CONTRA O CAOS” — ROOT CAUSE ANALYSIS NO MAINFRAME Z17, DEVOPS, CICS, JES2 E A CAÇADA À CAUSA RAIZ

Quando o operador para de apagar incêndios e começa a eliminar demônios do datacenter

Existe um momento na vida de todo Sysprog Padawan em que ele percebe uma verdade brutal do universo corporativo:

“Reiniciar o JOB não resolveu o problema…”

Apenas escondeu o cadáver.

E é exatamente nesse momento que nasce a verdadeira disciplina do guerreiro IBM Z:
a arte da Root Cause Analysis — ou simplesmente RCA.

No universo do mainframe moderno, onde bilhões de transações passam por CICS, DB2, MQ, IMS e JES2, problemas não aparecem do nada.

Todo ABEND possui uma origem.

Todo LOOP tem um motivo.

Todo dataset corrompido conta uma história.

E todo operador experiente sabe:

“O sintoma mente. A causa raiz não.”

Hoje vamos mergulhar profundamente no universo da RCA no estilo Bellacosa Mainframe, explorando:

• história,

• filosofia,

• métodos,

• guerra operacional,

• automação,

• observabilidade,

• DevOps,

• IA operacional,

• e sobrevivência psicológica em ambientes z/OS críticos.

Prepare o café.
Abra o SDSF.
E mantenha o dump por perto.

Porque o LOBO da causa raiz está observando.

---

☕ O QUE É ROOT CAUSE ANALYSIS?

Root Cause Analysis é a ciência de descobrir a verdadeira origem de um problema.

Não o sintoma.
Não o efeito.
Não o caos superficial.

Mas sim:
o gatilho original que iniciou a cascata da destruição.

Na definição da IBM:

“RCA é o processo de identificar a raiz de um problema para evitar sua recorrência.”

O detalhe importante aqui é:

EVITAR RECORRÊNCIA.

Porque qualquer novato consegue:

• cancelar TASK,

• reiniciar STC,

• reciclar CICS,

• dar IPL no desespero.

Mas poucos conseguem impedir o problema de voltar.

---

☕ A DIFERENÇA ENTRE OPERADOR E ENGENHEIRO

Operador reativo:

“Voltou a funcionar? Ótimo.”

Engenheiro RCA:

“Por que parou?”

Essa diferença separa:

• operadores comuns,

• Sysprogs lendários.

---

☕ A ORIGEM HISTÓRICA DA RCA

A RCA não nasceu na TI.

Ela surgiu em ambientes extremos.

Segunda Guerra Mundial

Engenheiros militares precisavam descobrir:

• por que aviões caíam,

• por que motores explodiam,

• por que radares falhavam.

Não havia espaço para tentativa e erro.

A falha matava pessoas.

A filosofia então evoluiu para:

• engenharia industrial,

• indústria nuclear,

• aviação,

• automóveis,

• telecom,

• e finalmente TI corporativa.

---

☕ TOYOTA E O MÉTODO DOS 5 WHYs

Nos anos 1950, Taiichi Ohno criou o famoso:

“5 Porquês”

A lógica era simples:

Continue perguntando “por quê?” até encontrar a verdade.

---

☕ EXEMPLO MAINFRAME REALÍSTICO

Problema:

JOB noturno ABEND S0C7.

---

Por quê?

Campo numérico inválido.

---

Por quê?

Arquivo veio com caracteres errados.

---

Por quê?

Conversão ASCII/EBCDIC falhou.

---

Por quê?

Novo middleware FTP alterou encoding.

---

Por quê?

Mudança entrou sem homologação.

---

CAUSA RAIZ:

Processo DevOps inadequado.

Perceba:
o COBOL não era o vilão.

O problema estava na governança.

---

☕ O MAIOR ERRO DOS PADAWANS

Todo Sysprog iniciante acredita em sintomas.

Mas sintomas enganam.

Exemplo clássico:

Sintoma:

CPU alta.

O Padawan pensa:

“Precisamos de mais processador.”

O mestre RCA responde:

“Não.
Precisamos descobrir QUEM está consumindo CPU.”

Pode ser:

• loop COBOL,

• SQL ruim,

• runaway task,

• lock contention,

• buffer inadequado,

• storage leak,

• automação defeituosa.

A CPU alta é apenas o grito do sistema.

---

☕ OS 3 TIPOS DE CAUSAS

A IBM divide RCA em três dimensões.

---

1. CAUSAS FÍSICAS

Hardware.
Infraestrutura.
Equipamentos.

Exemplos:

• DASD defeituoso

• canal FICON instável

• controladora falhando

• memória ECC corrompida

• falha elétrica

---

☕ EXEMPLO Z/OS

O JES2 começa a apresentar I/O ERROR.

Batch falha aleatoriamente.

Após investigação:

Causa raiz:

microfissura em controladora storage.

---

2. CAUSAS HUMANAS

O terror invisível do datacenter.

Exemplos:

• operador cancelando STC errada,

• PROC alterada incorretamente,

• DELETE DATASET acidental,

• parâmetro inválido,

• JCL truncado.

---

☕ O CLÁSSICO ERRO DO PADAWAN

//STEP01 EXEC PGM=IEFBR14
//DD1 DD DSN=PROD.CLIENTES,
// DISP=(OLD,DELETE,DELETE)

Parabéns.

Você acabou de invocar o demônio ancestral do DELETE em produção.

---

3. CAUSAS ORGANIZACIONAIS

As mais perigosas.

Porque sobrevivem por anos.

Exemplos:

• ausência de documentação,

• treinamento ruim,

• processo inexistente,

• automação incompleta,

• cultura tóxica,

• deploy sem governança.

---

☕ A VERDADE SOMBRIA

Grandes falhas raramente acontecem por um único motivo.

Elas acontecem porque:

múltiplas pequenas falhas se alinham.

Igual peças de dominó.

---

☕ O CICLO DA DESTRUIÇÃO OPERACIONAL

1. Pequena falha ignorada

2. Monitoramento ruim

3. Automação incompleta

4. Time cansado

5. Mudança mal testada

6. Alertas ignorados

7. Deploy na sexta-feira

8. Caos absoluto

---

☕ O PROCESSO COMPLETO DE RCA

Agora entramos na disciplina guerreira.

---

ETAPA 1 — IDENTIFICAR O PROBLEMA

Definição ruim:

“O sistema caiu.”

Definição profissional:

“O CICS PAY01 apresentou degradação progressiva após aumento de lock contention DB2 causado por crescimento anômalo de filas MQ.”

Agora sim existe material técnico.

---

☕ ETAPA 2 — MONTAR O TIME RCA

Você precisa reunir:

• operadores,

• Sysprogs,

• DBAs,

• DevOps,

• segurança,

• storage,

• redes,

• automação.

Porque falhas modernas são híbridas.

---

☕ ETAPA 3 — COLETA DE DADOS

Aqui começa a arqueologia digital.

Ferramentas clássicas:

• SDSF

• RMF

• SMF

• IPCS

• NetView

• OMEGAMON

• SYSLOG

• dumps

• traces

• logs MQ

• logs DB2

---

☕ O PODER DOS LOGS

Logs são fósseis digitais.

Eles contam a história da tragédia.

O problema é:

Padawans não leem logs.

Eles olham apenas:

• RC=12

• ABEND=S806

• IEC141I

E entram em pânico.

---

☕ ETAPA 4 — BRAINSTORM DAS CAUSAS

Aqui existe uma regra sagrada:

NÃO ASSUMA NADA.

O maior inimigo da RCA é:

“Já sei o que aconteceu.”

Porque normalmente você NÃO sabe.

---

☕ ETAPA 5 — DETERMINAR A CAUSA RAIZ

Agora elimina-se hipótese por hipótese.

Até restar:

• evidência,

• causalidade,

• sequência lógica.

---

☕ ETAPA 6 — IMPLEMENTAR A SOLUÇÃO

Agora nasce a verdadeira engenharia.

Não basta corrigir.

É preciso:

• automatizar,

• prevenir,

• monitorar,

• alertar,

• documentar.

---

☕ MÉTODOS RCA MAIS IMPORTANTES

---

☕ 5 WHYs

Simples.
Poderoso.
Mortal.

Excelente para:

• incidentes operacionais,

• falhas batch,

• troubleshooting rápido.

---

☕ FMEA

Failure Mode and Effects Analysis.

Muito usado em:

• bancos,

• aviação,

• missão crítica.

Objetivo:

Prever COMO o sistema pode falhar antes do desastre.

---

☕ ISHIKAWA (FISHBONE)

O famoso diagrama espinha de peixe.

Divide problemas em categorias:

• pessoas,

• máquinas,

• processos,

• ambiente,

• software,

• gestão.

Excelente para war rooms.

---

☕ PARETO

80% dos problemas vêm de 20% das causas.

Exemplo real:

• 70% dos ABENDs vêm de input inválido.

• 15% vêm de espaço.

• 10% vêm de lock.

• 5% diversos.

Ataque os 20%.
Ganhe estabilidade absurda.

---

☕ RCA EM DEVOPS

No DevOps moderno:

TODO INCIDENTE GERA POSTMORTEM.

Mas aqui existe uma mudança filosófica gigantesca.

---

☕ BLAMELESS POSTMORTEM

Google popularizou:

“Postmortem sem caça às bruxas.”

Objetivo:

Não destruir pessoas.
Mas aprender.

Porque sistemas falham.
Humanos erram.
Processos quebram.

A maturidade está em aprender rápido.

---

☕ RCA NO MAINFRAME MODERNO

O IBM Z atual é extremamente avançado.

Hoje temos:

• observabilidade,

• IA operacional,

• automação,

• analytics,

• machine learning.

Ferramentas modernas:

• IBM Instana

• OMEGAMON

• System Automation

• NetView

• z/OSMF

• SMF Analytics

---

☕ EXEMPLO REAL — O APOCALIPSE DO PIX

Imagine:

Sexta-feira.
18:05.
PIX nacional congestionado.

Sintomas:

• CICS lento

• MQ crescendo

• DB2 travando

• CPU disparando

Padawans entram em desespero.

---

☕ INVESTIGAÇÃO

A RCA descobre:

Deploy DevOps alterou frequência de COMMIT.

Resultado:

• lock contention,

• timeout,

• crescimento de filas,

• efeito cascata.

---

☕ CAUSA RAIZ

Mudança sem teste de carga.

---

☕ SOLUÇÃO

• rollback,

• observabilidade,

• testes automáticos,

• limites MQ,

• monitoramento preditivo.

Agora o sistema ficou MAIS FORTE que antes.

Esse é o verdadeiro objetivo da RCA.

---

☕ A ERA DA IA OPERACIONAL

Hoje AIOps tenta prever:

• anomalias,

• falhas,

• gargalos,

• tendências,

• causas prováveis.

O futuro do Sysprog não é apenas reagir.

Será:

prever o desastre antes dele nascer.

---

☕ O VERDADEIRO NÍVEL MESTRE

O Sysprog lendário não luta contra incêndios.

Ele elimina as condições que permitem incêndios.

---

☕ LIÇÕES FINAIS PARA O SYSprog PADAWAN

Nunca confie no primeiro sintoma.

Nunca assuma a primeira hipótese.

Nunca ignore pequenos alertas.

Nunca faça deploy sexta-feira.

Nunca delete dataset sem olhar duas vezes.

Nunca subestime logs.

Nunca trate apenas o efeito.

---

☕ CONCLUSÃO

Root Cause Analysis não é apenas metodologia.

É mentalidade.

É disciplina.

É engenharia real.

No mundo IBM Z moderno, onde bilhões dependem da estabilidade do sistema, RCA separa:

• operadores comuns,

• arquitetos da confiabilidade.

Quando você aprende RCA:

você deixa de ser alguém que “reinicia sistemas”.

E se torna alguém que entende o funcionamento profundo do caos.

E no momento em que você compreende o caos…

você começa a dominar o datacenter.

☕🔥💣

Bellacosa Mainframe apresenta um checklist de RCA para sysprog junior

☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN

Como Evoluir de Apagador de Incêndios para Caçador de Causas Raiz

A maioria dos Sysprogs juniores aprende primeiro a resolver incidentes.

Poucos aprendem a impedir que eles aconteçam novamente.

O objetivo deste checklist é desenvolver a mentalidade de investigação que transforma um operador técnico em um verdadeiro engenheiro de confiabilidade.

---

🔍 NÍVEL 1 — FUNDAMENTOS DO INVESTIGADOR

Conhecer a arquitetura do ambiente

☐ Entender o fluxo completo da aplicação

☐ Conhecer as LPARs existentes

☐ Entender Sysplex

☐ Conhecer JES2/JES3

☐ Entender CICS

☐ Entender DB2

☐ Entender MQ

☐ Conhecer Storage Management

☐ Entender WLM

☐ Conhecer SDSF profundamente

Objetivo

Parar de enxergar componentes isolados e começar a enxergar o ecossistema.

---

📋 NÍVEL 2 — COLETA DE EVIDÊNCIAS

Antes de agir:

☐ Registrar horário exato do incidente

☐ Identificar quem reportou

☐ Verificar impacto

☐ Capturar mensagens de erro

☐ Salvar logs

☐ Salvar SYSLOG

☐ Salvar JESMSGLG

☐ Salvar JESJCL

☐ Salvar JESYSMSG

☐ Registrar alterações recentes

☐ Verificar deploys recentes

Regra de ouro

Nunca altere o ambiente antes de coletar evidências.

---

🔥 NÍVEL 3 — ANÁLISE JES2

☐ Verificar initiators

☐ Verificar classes

☐ Verificar backlog

☐ Verificar spool

☐ Verificar HOLDs

☐ Verificar jobs looping

☐ Verificar jobs aguardando recursos

☐ Verificar ENQ contention

☐ Verificar mensagens $HASP

Pergunta obrigatória

O problema começou no JES2 ou chegou até ele?

---

💾 NÍVEL 4 — STORAGE E MEMÓRIA

☐ Verificar CSA

☐ Verificar ECSA

☐ Verificar SQA

☐ Verificar ESQA

☐ Verificar Private Area

☐ Procurar storage leaks

☐ Analisar crescimento anormal

☐ Verificar mensagens IEA e IEF

☐ Consultar RMF

Atenção

Muitos "problemas de sistema" são apenas vazamentos de memória.

---

⚡ NÍVEL 5 — PERFORMANCE

☐ Verificar CPU

☐ Verificar I/O

☐ Verificar Paging

☐ Verificar DASD

☐ Verificar Coupling Facility

☐ Verificar WLM

☐ Verificar gargalos

☐ Comparar com baseline

☐ Analisar tendências

Objetivo

Entender se a degradação é sintoma ou causa.

---

🖥️ NÍVEL 6 — RCA EM CICS

☐ Verificar transações lentas

☐ Verificar tasks pendentes

☐ Verificar Short On Storage

☐ Verificar TD Queues

☐ Verificar TS Queues

☐ Verificar DB2 Attach

☐ Verificar MQ Attach

☐ Verificar abends

☐ Verificar dumps

☐ Analisar traces

Nunca conclua

"CICS está lento"

sem descobrir:

"POR QUE está lento?"

---

🗄️ NÍVEL 7 — RCA EM DB2

☐ Verificar deadlocks

☐ Verificar lock escalation

☐ Verificar SQLCODEs

☐ Verificar buffer pools

☐ Verificar índices

☐ Procurar full table scan

☐ Verificar RUNSTATS

☐ Verificar REORG pendente

☐ Verificar crescimento de tabelas

Regra

Muitos problemas de CICS são, na verdade, problemas de DB2.

---

📬 NÍVEL 8 — RCA EM MQ

☐ Verificar Queue Depth

☐ Verificar canais

☐ Verificar backlog

☐ Verificar consumidores

☐ Verificar produtores

☐ Verificar DLQ

☐ Verificar mensagens presas

☐ Verificar timeouts

Lembre-se

Fila cheia normalmente é consequência.

Raramente é a causa raiz.

---

📊 NÍVEL 9 — OBSERVABILIDADE

☐ Utilizar OMEGAMON

☐ Utilizar RMF

☐ Utilizar SMF

☐ Utilizar NetView

☐ Utilizar Sysview

☐ Criar dashboards

☐ Definir baseline

☐ Identificar anomalias

☐ Correlacionar eventos

Meta

Parar de reagir.

Começar a prever.

---

🔎 NÍVEL 10 — TÉCNICAS DE INVESTIGAÇÃO

Five Whys

☐ Aplicar os 5 Porquês

---

Timeline Analysis

☐ Construir linha do tempo

---

Event Correlation

☐ Correlacionar eventos

---

Impact Analysis

☐ Medir impacto real

---

Trend Analysis

☐ Procurar recorrência

---

🤖 NÍVEL 11 — AUTOMAÇÃO E PREVENÇÃO

☐ Automatizar alertas

☐ Automatizar coleta de evidências

☐ Automatizar correções simples

☐ Criar scripts REXX

☐ Criar procedimentos de recuperação

☐ Integrar com SA z/OS

☐ Integrar com NetView

☐ Criar runbooks

Objetivo

Não resolver mais rápido.

Resolver menos vezes.

---

📚 NÍVEL 12 — CONHECIMENTO HISTÓRICO

☐ Manter base de incidentes

☐ Documentar RCA

☐ Criar Wiki interna

☐ Registrar lições aprendidas

☐ Catalogar soluções

☐ Criar biblioteca de dumps

☐ Registrar padrões recorrentes

Ouro do Sysprog

Experiência documentada vale mais que memória.

---

🧠 NÍVEL 13 — MENTALIDADE DE MESTRE

Antes de qualquer ação pergunte:

☐ O que aconteceu?

☐ Quando aconteceu?

☐ Quem foi impactado?

☐ O que mudou?

☐ Isso já aconteceu antes?

☐ O que os logs mostram?

☐ O que os dados mostram?

☐ Estou tratando sintoma ou causa?

☐ Como impedir recorrência?

☐ O que aprendi hoje?

---

🏆 CHECKLIST FINAL DO SYSprog MESTRE

Quando um incidente ocorrer:

❌ Não reinicie imediatamente

❌ Não assuma conclusões

❌ Não culpe usuários

❌ Não culpe desenvolvedores

❌ Não culpe infraestrutura

✅ Colete evidências

✅ Analise dados

✅ Correlacione eventos

✅ Pergunte "por quê?"

✅ Encontre a causa raiz

✅ Elimine a recorrência

✅ Documente a descoberta

✅ Compartilhe conhecimento

---

☕ Regra Suprema do Bellacosa Mainframe

"O Padawan reinicia o CICS.

O Sysprog investiga o dump.

O Mestre encontra a causa raiz.

O Arquiteto faz o problema desaparecer para sempre." 🚀💣🔥

 

 

📜 Linha do Tempo – BUNCH, Sete Anões e a IBM (1950–1980)

🧠 Anos 1950 – Os “deuses antigos”

Antes mesmo do termo BUNCH existir:

• UNIVAC reina absoluta
  ✔ Primeiro computador comercial
  ✔ Fama de “computador que prevê eleições”
  ❌ Péssima estratégia comercial
  💬 Engenheiros brilhantes, vendedores fracos

• IBM ainda era vista como “empresa de máquinas de escrever caras”.

👉 Plot twist histórico: a IBM aprende rápido… rápido demais.

---

🚀 1960–1963 – A guerra começa

• IBM 1401 explode em vendas

• Burroughs conquista bancos

• CDC, com Seymour Cray, começa a assustar a IBM em performance científica

💬 Bastidor:

A IBM tinha medo real da CDC. Cray era visto como “o gênio imprevisível”.

---

💣 1964 – O Big Bang: IBM System/360

📅 Abril de 1964

• IBM lança o System/360

• Uma arquitetura, vários modelos

• Compatibilidade inédita

💰 Investimento colossal (bilhões, em valores atuais)

🔥 Reação do mercado:

• O BUNCH entra em pânico

• Clientes congelam compras esperando o 360

💬 Fofoquinha:

“A IBM apostou a empresa inteira. Se desse errado, teria acabado ali.”

---

😬 1965–1968 – O BUNCH tenta reagir

🏦 Burroughs

• Arquitetura orientada a pilha

• Segurança forte

• Bancos AMAVAM

💬 Problema:

Incompatível demais com o resto do mercado.

---

🧪 Control Data Corporation (CDC)

• CDC 6600 = computador mais rápido do mundo

• Seymour Cray vira lenda viva

💬 Easter egg:

A IBM tentou atrasar clientes da CDC com anúncios de máquinas que nem existiam ainda.

(Sim, isso gerou processos antitruste.)

---

🧾 Honeywell

• Forte em governo e defesa

• Compra a divisão da GE depois

💬 Bastidor:

Honeywell herdou mais problemas do que clientes.

---

🧹 1969–1971 – Os anões começam a cair

❌ GE sai do mercado (1970)

• Perdas gigantes

• Vende tudo para a Honeywell

❌ RCA abandona mainframes

• Arquiteturas caras

• Poucos clientes

• Estratégia confusa

💬 Frase clássica atribuída a executivos:

“Entramos tarde demais e caros demais.”

---

⚖️ Anos 1970 – A IBM quase cai pelo próprio peso

• Governo dos EUA abre processo antitruste contra a IBM

• Acusação: monopólio, vendas casadas, pressão sobre clientes

💬 Curiosidade:

O processo durou mais de 10 anos e moldou a forma como software passou a ser vendido separadamente.

📌 Resultado indireto:

• Nascimento da indústria moderna de software independente

---

🧊 Final dos anos 70 – O mundo encolhe

• BUNCH perde força

• CDC se fragmenta

• Burroughs se funde com a Sperry (vira Unisys)

• IBM continua dominante, mas mais vigiada

💬 Moral da história:

A IBM venceu… mas teve que aprender a jogar “menos sujo”.

---

🧠 Easter Eggs Bellacosa Edition

• Muitos conceitos de segurança bancária, transações ACID e processamento em lote nasceram fora da IBM

• A fama de “mainframe = IBM” é mais marketing do que realidade histórica

• Sem o BUNCH, a IBM talvez nunca tivesse inovado tão agressivamente

---

🏁 Conclusão ácida (e honesta)

O BUNCH não perdeu por incompetência técnica, perdeu por:

• Fragmentação

• Falta de padrão

• Incapacidade de criar ecossistema

A IBM venceu porque entendeu cedo algo que o Vale do Silício só aprendeu décadas depois:

quem controla o padrão, controla o mercado

 

Para saber mais

Bunch e os 7 anões

https://eljefemidnightlunch.blogspot.com/2024/09/bunch-e-os-sete-anoes.html

O mundo do Mainframe nos anos cinquenta do século passado

Bellacosa Mainframe e os titas do processamento de dados

☕ Um Café no Bellacosa Mainframe

Os Titãs do Processamento

Quando um Programador COBOL Descobre que Antes da IBM Existia uma Guerra de Gigantes — e que Quase Todos Foram Esquecidos pela História

"Nenhum império nasce sozinho. Antes de existir um rei, existiram dezenas de cavaleiros abrindo caminho."

---

Introdução

Quando alguém fala em mainframe, praticamente toda pessoa imagina imediatamente um enorme computador azul com o logotipo da IBM.

É compreensível.

Durante mais de quarenta anos a IBM tornou-se praticamente sinônimo de computação corporativa.

Mas existe uma história muito mais fascinante.

Muito antes de o IBM System/360 revolucionar o mercado em 1964, dezenas de empresas disputavam ferozmente quem construiria o cérebro eletrônico do futuro.

Algumas nasceram produzindo calculadoras mecânicas.

Outras fabricavam radares durante a Segunda Guerra Mundial.

Algumas vieram da telefonia.

Outras da indústria militar.

Muitas desapareceram.

Algumas foram compradas.

Pouquíssimas sobreviveram.

Entre 1940 e 1990 aconteceu aquilo que muitos historiadores chamam de A Guerra dos Mainframes.

Foi uma época onde praticamente cada fabricante possuía sua própria arquitetura, linguagem, periféricos, sistema operacional e filosofia de desenvolvimento.

Era um verdadeiro universo paralelo.

Hoje vamos prestar homenagem aos gigantes que construíram a informática moderna.

Pegue seu café.

Vamos viajar quase cinquenta anos no tempo.

---

A Era dos Pioneiros (1940-1955)

Antes mesmo da palavra computador existir da forma que conhecemos, grandes empresas já investiam milhões em máquinas capazes de resolver cálculos militares.

O cenário era dominado por necessidades extremamente específicas:

• Guerra

• Balística

• Criptografia

• Estatística

• Censos

• Engenharia

Os computadores ocupavam salas inteiras.

Consumiam quilowatts.

Possuíam milhares de válvulas.

Falhavam diariamente.

Mesmo assim eram considerados milagres tecnológicos.

---

IBM

O Gigante que já Nasceu Grande

Fundação: 1911

Origem: CTR (Computing Tabulating Recording Company)

Especialidade inicial:

• Cartões perfurados

• Máquinas Hollerith

• Relógios de ponto

• Equipamentos administrativos

Durante décadas a IBM dominou completamente o processamento por cartões.

Quando os computadores eletrônicos apareceram ela já possuía milhares de clientes.

Essa vantagem seria praticamente impossível de superar.

Modelo histórico

IBM 701

Ano:

1952

Conhecido como:

Defense Calculator

Foi o primeiro computador científico comercial da IBM.

---

Remington Rand

Pouca gente lembra dela.

Mas foi a empresa responsável por comercializar um dos computadores mais famosos da história.

Modelo

UNIVAC I

Ano:

1951

Curiosidade:

Foi o primeiro computador comercial vendido nos Estados Unidos.

O UNIVAC ficou mundialmente famoso por prever corretamente o resultado das eleições americanas de 1952.

A televisão ficou em choque.

Foi o momento em que o público percebeu que computadores poderiam "pensar".

---

Burroughs

Para muitos programadores COBOL veteranos, falar Burroughs ainda desperta nostalgia.

A empresa apostava em arquiteturas completamente diferentes.

Enquanto quase todo mundo pensava em registradores, a Burroughs acreditava em máquinas orientadas por pilha (stack machines).

Décadas depois esse conceito voltaria a aparecer nas máquinas virtuais Java.

Modelo clássico

Burroughs B5000

1961

Foi um dos computadores mais elegantes já projetados.

Era praticamente feito para linguagens de alto nível.

Muitos historiadores afirmam que seu projeto estava décadas à frente do tempo.

---

Easter Egg

A arquitetura da Burroughs lembra bastante o funcionamento interno da JVM.

Sim.

Muito antes do Java existir.

---

RCA

A Radio Corporation of America também entrou na disputa.

Ela possuía enorme experiência em eletrônica.

Produziu computadores voltados principalmente para governo.

Modelo famoso:

RCA Spectra 70

1965

Seu objetivo era competir diretamente com o System/360.

Não conseguiu.

---

Honeywell

Originalmente conhecida por equipamentos industriais.

Entrou forte no mercado de computadores corporativos.

Modelo famoso

Honeywell 200

1963

Uma curiosidade incrível.

Ele foi projetado para executar programas do IBM 1401 com poucas modificações.

Era praticamente um "compatível IBM".

Na época isso foi revolucionário.

---

Control Data Corporation (CDC)

Se existiu um gênio absoluto da engenharia de computadores, seu nome era:

Seymour Cray.

Antes dos supercomputadores Cray, ele trabalhava na CDC.

Modelo famoso

CDC 6600

1964

Considerado por muitos o primeiro supercomputador verdadeiro.

Era mais rápido que praticamente qualquer concorrente.

---

NCR

National Cash Register.

Começou fabricando caixas registradoras.

Depois migrou para sistemas bancários.

Modelo famoso

NCR Century

1976

Muito utilizado em bancos.

---

General Electric

Pouca gente lembra, mas a GE também produziu grandes computadores.

Modelo

GE-600

1965

Influenciou diretamente o desenvolvimento do MULTICS.

Sem MULTICS talvez nunca existisse o UNIX.

---

Digital Equipment Corporation (DEC)

Embora fosse conhecida pelos minicomputadores, merece enorme respeito.

O PDP-8 democratizou a computação.

Depois veio o VAX.

Modelo famoso

VAX-11/780

1977

Era tão poderoso que muitas empresas deixaram de comprar mainframes médios.

---

Sperry

Resultado da fusão da Sperry Rand.

Modelo famoso

UNIVAC 1100

Década de 1970

Muito utilizado por governos.

---

Fujitsu

Enquanto o Ocidente brigava entre IBM e Burroughs, o Japão crescia silenciosamente.

Modelo famoso

FACOM M-190

1974

Os japoneses investiram pesadamente em compatibilidade IBM.

---

Hitachi

Outro gigante japonês.

Modelo famoso

HITAC M Series

Década de 1970

Grande presença em bancos asiáticos.

---

NEC

Modelo famoso

ACOS Series

1974

Ainda hoje existem versões modernas.

---

Siemens

Alemanha.

Modelo famoso

BS2000

Década de 1970

Muito utilizado na Europa.

---

Bull

Orgulho francês.

Modelo famoso

GCOS

Década de 1970

A Bull sobreviveu durante décadas oferecendo alternativas europeias.

---

ICL

Reino Unido.

Modelo famoso

ICL 2900

1974

Representava a tentativa britânica de manter independência tecnológica.

---

Olivetti

Conhecida pelas máquinas de escrever.

Também entrou na corrida.

Modelo

Elea 9003

1959

Projeto extremamente elegante.

---

Wang Laboratories

Muito forte em processamento de textos.

Modelo

VS Series

Década de 1980

---

Prime Computer

Muito utilizada em universidades.

Modelo

Prime 750

1979

---

A Revolução que Mudou Tudo

Em 1964 a IBM lançou algo que redefiniu completamente a indústria.

IBM System/360

Não era apenas um computador.

Era uma família inteira.

Pela primeira vez um programa escrito em um modelo podia funcionar em outro.

Hoje isso parece óbvio.

Na época era praticamente ficção científica.

O investimento foi colossal.

Mais de cinco bilhões de dólares da época.

Foi uma das maiores apostas industriais do século XX.

---

O Nascimento da Compatibilidade

Depois do sucesso do System/360, praticamente todas as empresas começaram a copiar a estratégia da IBM.

Compatibilidade virou sobrevivência.

Foi nesse momento que surgiram fabricantes conhecidos como:

Plug Compatible Manufacturers (PCMs)

Entre eles:

• Amdahl

• Hitachi

• Fujitsu

• National Advanced Systems

Essas empresas fabricavam computadores capazes de executar software IBM.

Era como vender peças compatíveis para um automóvel extremamente popular.

---

Os Grandes Modelos que Marcaram Época

Ano	Modelo	Fabricante
1951	UNIVAC I	Remington Rand
1952	IBM 701	IBM
1959	Elea 9003	Olivetti
1961	B5000	Burroughs
1963	Honeywell 200	Honeywell
1964	CDC 6600	CDC
1964	System/360	IBM
1965	Spectra 70	RCA
1965	GE-600	General Electric
1974	ICL 2900	ICL
1974	FACOM M-190	Fujitsu
1974	ACOS	NEC
1977	VAX 11/780	DEC
1980	IBM 3081	IBM
1985	IBM 3090	IBM
1990	IBM ES/9000	IBM

---

Curiosidades

O primeiro "clone"

Honeywell praticamente criou computadores capazes de executar programas IBM.

Hoje chamaríamos isso de compatibilidade binária.

---

Burroughs inspirou o futuro

Seu conceito de pilha antecipou tecnologias usadas décadas depois.

---

IBM quase faliu

O investimento no System/360 foi tão gigantesco que muitos acionistas acreditavam que seria o fim da empresa.

Foi exatamente o contrário.

---

Seymour Cray saiu para fundar sua própria empresa

E acabou criando alguns dos computadores mais rápidos do planeta.

---

A Guerra Fria acelerou tudo

Sem investimentos militares, provavelmente a evolução teria levado mais vinte anos.

---

Easter Eggs para Programadores COBOL

☕ O COBOL nasceu em 1959 e foi pensado para rodar em computadores de diferentes fabricantes. Antes do System/360, portar um programa entre máquinas era quase uma aventura arqueológica.

☕ O B5000 da Burroughs foi um dos primeiros computadores desenhados pensando em linguagens de alto nível, reduzindo a dependência da programação em Assembly.

☕ Muitos bancos brasileiros já utilizaram equipamentos Burroughs, UNIVAC, Honeywell e NCR antes de consolidarem seus parques em IBM.

☕ O nome "mainframe" só se popularizou porque a unidade central ficava instalada no main frame (gabinete principal) que concentrava CPU, memória e canais de E/S.

☕ Empresas como Amdahl provaram que era possível inovar mesmo dentro do ecossistema IBM, oferecendo equipamentos compatíveis com melhor relação custo-desempenho.

---

Dicas para Quem Deseja Estudar a História dos Mainframes

Se você deseja compreender realmente a evolução do IBM Z, vale a pena estudar a história dos seus concorrentes. Muitas ideias consideradas modernas nasceram em empresas que já não existem mais:

• Entenda a arquitetura do Burroughs B5000 para conhecer os conceitos de máquinas orientadas por pilha.

• Estude o UNIVAC I para compreender a transição dos cartões perfurados para a computação eletrônica comercial.

• Pesquise o CDC 6600 para entender como Seymour Cray revolucionou o paralelismo e a alta performance.

• Compare o IBM System/360 com seus sucessores (System/370, 308X, 3090, ES/9000) para perceber como a compatibilidade de software se tornou um dos maiores patrimônios da IBM.

• Explore a história da Honeywell, Bull, ICL e Fujitsu para descobrir como diferentes países buscaram independência tecnológica durante a Guerra Fria.

---

O Fim da Guerra e o Monopólio da IBM

Durante os anos 1970 e 1980, a competição diminuiu drasticamente.

A IBM havia conseguido algo extraordinário: transformar sua arquitetura em um padrão de mercado. Quem escolhia um System/370 ou, mais tarde, um 3090, investia em um ecossistema completo de hardware, sistemas operacionais, linguagens, bancos de dados, ferramentas e suporte técnico. Mudar de fornecedor passou a significar reescrever aplicações inteiras, treinar equipes e substituir uma infraestrutura construída ao longo de décadas.

Enquanto isso, muitos concorrentes enfrentaram dificuldades:

• A Burroughs fundiu-se com a Sperry, formando a Unisys em 1986.

• A CDC abandonou gradualmente o mercado de mainframes para concentrar esforços em supercomputação.

• A RCA vendeu sua divisão de computadores.

• A Honeywell deixou o segmento após diversas reestruturações.

• Empresas europeias como ICL, Bull e Siemens reduziram sua participação ou migraram para outros mercados.

• Fabricantes japoneses permaneceram relevantes, mas em grande parte adotando estratégias de compatibilidade com a arquitetura IBM.

Esse cenário levou muitos analistas da época a falar em um "monopólio de fato" da IBM no universo dos grandes sistemas corporativos. Embora outras empresas continuassem existindo e produzindo soluções importantes, a influência do ecossistema IBM tornou-se dominante.

Mas há uma ironia digna do Bellacosa Mainframe.

A IBM venceu a guerra dos fabricantes, porém jamais venceu sozinha.

Cada concorrente deixou uma peça fundamental no quebra-cabeça da computação moderna. O conceito de compatibilidade, as arquiteturas orientadas por pilha, a alta performance, os sistemas operacionais multiprogramados, a confiabilidade extrema e até muitas ideias presentes hoje no IBM Z, em máquinas virtuais e em ambientes de nuvem nasceram ou amadureceram graças à ousadia desses gigantes.

Assim, quando um programador COBOL executa um simples EXEC CICS, um READ VSAM ou um SELECT no Db2, ele também carrega um pouco do legado de engenheiros da Burroughs, da Honeywell, da UNIVAC, da CDC, da DEC, da Bull, da Fujitsu, da Hitachi e de tantas outras empresas que desafiaram os limites da tecnologia.

Porque a verdadeira história dos mainframes não é apenas a história da IBM.

É a história de uma geração de visionários que, entre 1940 e 1990, construiu as fundações invisíveis sobre as quais o mundo digital continua funcionando até hoje. E essa merece ser lembrada, estudada e homenageada por todos que amam a computação clássica.

Um pouco da historia do Mainframe Conheça os grandes fabricantes nos anos 50.