🧠 Bellacosa Mainframe — “z/OS 2.5: o monstro renascido no trono do ferro” ⚙️

 

🧠 Bellacosa Mainframe — “z/OS 2.5: o monstro renascido no trono do ferro” ⚙️
📅 Lançado em setembro de 2021 — o z/OS 2.5 é o início de uma nova era digital no coração de aço da IBM.

---

🧩 Um novo capítulo na dinastia z/OS

Quando o z/OS 2.5 chegou, ele não foi apenas “mais uma versão”.
Foi o recomeço do império z, uma resposta direta da IBM à revolução da IA, containers, APIs e automação que tomou o mundo corporativo.
Enquanto muitos achavam que o mainframe ficaria preso no COBOL e JCL, o z/OS 2.5 mostrou que o “dinossauro” aprendeu a pilotar drones. 🦖🚁

---

💾 Lançamento e base de hardware

• 📆 Lançado: setembro de 2021

• ⚙️ Hardware compatível: IBM z15 e z16

• 🧬 Firmware: PR/SM versão 6.0+

• 🧠 Suporte a memória: até 16 TB de memória real por LPAR

• 🧮 CPUs lógicas: até 2.000 (em sistemas de alta escala com z16)

O PR/SM (Processor Resource/System Manager) também evoluiu — agora com gerenciamento mais inteligente de créditos de CPU, priorizando workloads críticos (como CICS, DB2, e z/OSMF) em ambientes mistos de LPARs, especialmente sob WLM Intelligent Resource Director (IRD).

💡 Curiosidade Bellacosa: o PR/SM é o “prefeito das LPARs”. Decide quem fala, quem come e quem dorme no processador. E o z/OS 2.5 trouxe um prefeito com IA nos bastidores.

---

🧠 Avanços técnicos e memória expandida

O z/OS 2.5 trouxe um novo modelo de gerenciamento de endereçamento 64-bit estendido — o “2G-Above Bar Expansion”.
Isso significa que sistemas como DB2 v12+, IMS, e até CICS TS 5.6 podem acessar grandes quantidades de memória acima da região tradicional, reduzindo swapping e melhorando o throughput.

• Novo limite de memória de usuário: até 8 TB por address space

• Melhorias na CSA e SQA (áreas comuns): reorganizadas para eficiência em virtualização

• Nova LPA dinâmica: permite carregar módulos sem IPL em ambientes contínuos

---

⚙️ Softwares internos e subsistemas

O z/OS 2.5 veio afinadíssimo com o ecossistema z:

Componente	Versão recomendada	Novidades
CICS TS	5.6	APIs REST nativas, suporte OpenAPI 3.0
DB2	v12	Autotuning e Machine Learning Indexing
IMS	15.2	Suporte a Java e integração z/OS Connect EE
MQ	9.2	Mensageria híbrida com Kafka bridge
z/OSMF	2.5 built-in	Instalação simplificada via workflows
RACF	integrado	Suporte a autenticação multifator (MFA)

E claro, o z/OS Container Extensions (zCX) ganhou musculatura: agora executa containers Linux on z diretamente no LPAR do z/OS, sem precisar de z/VM.
Ou seja: Docker rodando dentro do mainframe — uma ironia deliciosa. 🐳💀

---

🧬 Instruções de máquina e arquitetura

O z/OS 2.5 se apoia nas novas instruções do z15 e z16, especialmente para segurança e compressão:

• AI acceleration com Matrix Multiply Assist

• Crypto Express7S com AES-256-GCM nativo

• zEDC v2.0 para compressão inline com até 40% menos overhead

• Guarded Storage Facility (GSF) para proteção contra buffer overflows

• Improved branch prediction em workloads Java e Python

Essas instruções são automaticamente exploradas pelo compilador Enterprise COBOL 6.4+ e pelo Java 11 do z/OS SDK, o que significa menos CPU, mais TPS e um sorriso de WLM feliz. 😎

---

🖥️ Interface e automação

O z/OSMF 2.5 é o verdadeiro painel de controle do futuro.
Ele transformou tarefas antes manuais (como definir SYS1.PARMLIB, atualizar PROCLIBs ou revisar SDSF) em workflows web interativos, permitindo que novos sysprogs e devops trabalhem sem TSO.

Além disso, o Ansible for z/OS ganhou integração oficial — é possível provisionar datasets, rodar jobs, configurar CICS e até fazer IPL via playbooks YAML.
O que antes levava horas de JCL, agora é automatizado com um simples “ansible-playbook zos.yaml”.

---

📊 Créditos de CPU e WLM inteligente

O z/OS 2.5 aprimorou a política de CPU credits e WLM dispatching, usando o SMF 120.15 para métricas mais refinadas de workloads containerizados.
O sistema reconhece quando uma workload está em zCX, em CICS ou em Java, e redistribui créditos automaticamente com base em prioridades e metas de SLA.

🧩 Easter Egg Bellacosa: o código interno que gerencia IRD no PR/SM ainda mantém nomes de planetas — “Venus”, “Mars” e “Saturn” — usados como labels em testes de laboratório da IBM desde os tempos do System/370. 🌌

---

🧵 Curiosidades e bastidores

• O z/OS 2.5 foi o último com suporte a IPL tradicional em modo 31-bit puro — uma era que se encerra com elegância.

• O Time-Travel Debugger (IBM Debug for z/OS) permite voltar no tempo durante o debugging, literalmente “rebobinando” a execução de um COBOL.

• O suporte à linguagem Python foi oficializado via IBM Open Enterprise SDK, abrindo caminho para automações híbridas.

• E o z/OS Cloud Broker conecta o mainframe direto ao OpenShift e Kubernetes. É o z/OS rodando em harmonia com o caos cloud. ☁️⚡

---

🔚 Conclusão — z/OS 2.5: o mainframe acordou de novo

O z/OS 2.5 não é apenas um upgrade — é um reboot arquitetural.
É o mainframe olhando para o futuro, conversando com APIs REST, rodando containers, automatizando via Ansible e protegendo dados com criptografia quântica pronta para o amanhã.

O aço agora tem alma digital.
E o Bellacosa Mainframe aplaude de pé. 👏💙

Lista de Artigos na Digital Innovatio One em 2021-09-29

Contributors Forks Stargazers Issues MIT License LinkedIn
Artigos na Digital Innovation One
DIO - Digital Innovation One : Artigos
Indice de artigos publicados no Forum da Comunidade da Digital Innovation One.
Indice de Artigos
🚀 Javascript : Testes condicionais, Arrow Functions e Operadores condicionais
https://web.digitalinnovation.one/articles/javascript-testes-condicionais-arrow-functions-e-operadores-condicionais
"Programação para Internet" "JavaScript" "Boas práticas"
🚀 Poderosa tecnica para salvar seu emprego. Use e abuse dos Testes Unitarios
https://web.digitalinnovation.one/articles/poderosa-tecnica-para-salvar-seu-emprego-testes-unitarios?back=%2Farticles
"Testes unitários" "Boas práticas" "QA"
🚀 Responda rapido o que é computaçao e computadores
https://web.digitalinnovation.one/articles/responda-rapido-o-que-e-computacao-e-computadores?back=/articles
"Informática Básica" "Boas práticas" "Arquitetura de Sistemas"
🚀 Som na caixa. Atividade 009 no Javascript Gruppen
https://web.digitalinnovation.one/articles/som-na-caixa-javascript-gruppen-atividade-009?back=/articles
"Informática Básica" "JavaScript" "Boas práticas"
🚀 Mao na Massa, Atividade 008 no Javascript Gruppen
https://web.digitalinnovation.one/articles/javascript-gruppen-atividade-008-mao-na-massa?back=/articles
"Informática Básica" "JavaScript"
🚀 Os misterios do CLI, computaçao no seculo XXI
https://web.digitalinnovation.one/articles/os-misterios-da-cli-computacao-no-seculo-xxi?back=/articles
"Informática Básica" "Boas práticas" "Arquitetura de Sistemas"
🚀 Bisbilhotando as base de dados no Mainframe, conheça o QMF
https://web.digitalinnovation.one/articles/bisbilhotando-as-bases-de-dados-no-mainframe?back=/articles
"Informática Básica" "SQL" "Arquitetura de Sistemas"
🚀 Qual o nome do diagrama usado em fluxos e processos?
https://web.digitalinnovation.one/articles/qual-o-nome-do-diagrama-usado-em-fluxos-e-processos?back=/articles
"Informática Básica" "Lógica de Programação" "Arquitetura de Sistemas"
🚀 O que é e para que serve a extensao de arquivos
https://web.digitalinnovation.one/articles/o-que-e-e-para-que-serve-a-extensao-de-arquivos?back=/articles
"Informática Básica" "Lógica de Programação" "Arquitetura de Sistemas"
🚀 Desenvolva habilidades gratuitamente no Microsoft Azure Virtual Trainning Day Modernize Net APPs
https://web.digitalinnovation.one/articles/desenvolva-habilidades-gratuitamente-no-microsoft-azure-virtual-training-day-modernize-net-apps?back=/articles
🚀 Divulgaçao de parças ajude-nos a fazer nossa comunidade crescer
https://web.digitalinnovation.one/articles/divulgacao-de-parcas-ajude-nos-a-fazer-nossa-rede-crescer?back=/articles
"Marketing Pessoal" "Marketing Digital" "Soft Skill"
🚀 Aprenda a fazer processos batch em MS-DOS
https://web.digitalinnovation.one/articles/aprenda-a-fazer-processos-batch-em-ms-dos?back=/articles
"Informática Básica" "Lógica de Programação" "Arquitetura de Sistemas"
🚀 Vida ou morte conheça o System Integration Testing SIT
https://web.digitalinnovation.one/articles/vida-ou-morte-conheca-o-system-integration-testing?back=/articles
"Testes unitários" "Boas práticas" "Arquitetura de Sistemas"
🚀 Conheça Mainframe no IBM Z Day
https://web.digitalinnovation.one/articles/conheca-mainframe-no-ibm-z-day?back=/articles
"Marketing Pessoal" "Arquitetura de Sistemas" "Soft Skill"
🚀 Aprenda MS-DOS e seus scripts bat no Windows
https://web.digitalinnovation.one/articles/aprenda-ms-dos-e-seus-scripts-bat-no-windows?back=/articles
"Informática Básica" "Arquitetura de Sistemas" "QA"
🚀 Algoritmos para classificaçao de listas e arrays
https://web.digitalinnovation.one/articles/algoritmos-para-classificacao-de-listas-e-arrays?back=/articles
"Estrutura de dados" "Lógica de Programação" "Arquitetura de Sistemas"
🚀 10 Segredos da Longevidade do Cobol
https://web.digitalinnovation.one/articles/10-segredos-da-longevidade-do-cobol?back=/articles
"Desperte o potencial" "Lógica de Programação" "Arquitetura de Sistemas"
🚀 A Força de um Gruppen torne-se um lider evoluindo suas equipes
https://web.digitalinnovation.one/articles/a-forca-de-um-gruppen-torne-se-um-lider-evoluindo-suas-equipes?back=/articles
"Marketing Pessoal" "Informática Básica" "Soft Skill"
🚀 Ajude o Tiozao, afinal o que é um developer advocate
https://web.digitalinnovation.one/articles/ajude-o-tiozao-afinal-o-que-e-um-developer-advocate?back=/articles
"Marketing Pessoal" "Arquitetura de Sistemas" "Soft Skill"
🚀 Rumo ao 1.000.000 de Devs, a sua ajude é Fundamental
https://web.digitalinnovation.one/articles/rumo-1000000-devs-sua-ajuda-e-fundamental?back=/articles
"Desperte o potencial" "Marketing Pessoal" "Soft Skill"
🚀 Cobol para padawan uma rapida olhadela
https://web.digitalinnovation.one/articles/cobol-para-padawans-uma-rapida-olhadela?back=/articles
"Desperte o potencial" "Informática Básica" "Arquitetura de Sistemas"
🚀 O fim da Big Blue gerou centenas de artigos, sera o Fim da IBM?
https://web.digitalinnovation.one/articles/epoca-de-mudancas-no-mainframe-e-a-possivel-derrocada-da-big-blue-sera
"Informática Básica" "Arquitetura de Sistemas" "Soft Skill"
🚀 Fluxograma na pratica e pseudocódigo em linguagem natural
https://web.digitalinnovation.one/articles/fluxograma-na-pratica-e-pseudocodigo-em-linguagem-natural
"Informática Básica" "Boas práticas" "Arquitetura de Sistemas"
🚀 Meu primeiro curso de informática, qual foi o seu????
https://web.digitalinnovation.one/articles/meu-primeiro-curso-de-informatica-qual-foi-o-seu
"Informática Básica" "Arquitetura de Sistemas"
🚀 Colapso do Banco TBS erro na migraçao e shutdown do sistema legado
https://web.digitalinnovation.one/articles/colapso-do-banco-tbs-erro-na-migracao-e-shutdown-do-sistema-legado
"Informática Básica" "Modelagem de Negócios" "Arquitetura de Sistemas"
🚀 Vamos codar? Crie um velocimetro em Html CSS e Javascript
https://web.digitalinnovation.one/articles/vamos-codar-crie-um-velocimetro-em-html-css-e-javascript
"JavaScript" "HTML" "CSS"
🚀 10 dicas para conquistar um emprego dos sonhos em T.I.
https://web.digitalinnovation.one/articles/10-dicas-para-conquistar-um-emprego-dos-sonhos-em-ti
"Marketing Pessoal" "Equipe Motivada" "Soft Skill"
🚀 O COBOL morreu? Vida longa ao Cobol!
https://web.digitalinnovation.one/articles/o-cobol-morreu-vida-longa-ao-cobol
"Informática Básica" "Boas práticas" "Arquitetura de Sistemas"
🚀 Aprenda a fazer uma nuvem de etiquetas em Html CSS e Javascript
https://web.digitalinnovation.one/articles/aprenda-a-fazer-uma-nuvem-de-etiquetas-em-html-css-e-javascript
"HTML" "JavaScript" "CSS"
🚀 Spaghetti Code um codigo sem nexo, o emaranhado de comandos que acabara com sua sanidade
https://web.digitalinnovation.one/articles/spaghetti-code-um-codigo-sem-nexo-emaranhado-de-comandos
"Programação para Internet" "Boas práticas" "Arquitetura de Sistemas"
🚀 17 dicas para JavaScript, Otimize e melhore a performance do seu código.
https://web.digitalinnovation.one/articles/javascript-otimize-e-melhore-a-performance-do-seu-codigo
"Programação para Internet" "JavaScript" "Boas práticas"
🚀 Seja resiliente evolua seus soft skills em T.I.
https://web.digitalinnovation.one/articles/seja-resiliente-evolua-seus-soft-skills-em-ti
"Marketing Pessoal" "Liderança de Equipe" "Soft Skill"
🚀 Prestaçao de Serviço e SLA, saiba mais sobre as garantias
https://web.digitalinnovation.one/articles/prestacao-de-servico-e-sla-saiba-mais-sobre-as-garantias
"Informática Básica" "Controle de gastos" "Boas práticas"
🚀 GITHub: O que colocar? Como criar um repositorio profissional?
https://web.digitalinnovation.one/articles/github-o-que-colocar-como-criar-um-repositorio-profissional
"Marketing Pessoal" "GitHub" "Arquitetura de Sistemas"
🚀 Saiba como indexar seu WebSite com uso de Robots.TXT [Tutorial]
https://web.digitalinnovation.one/articles/saiba-como-indexar-seu-website-com-uso-de-robotstxt-tutorial
"HTML" "Boas práticas" "Marketing Digital"
🚀 Javascript o poder da animaçao em Sprite Sheets
https://web.digitalinnovation.one/articles/javascript-o-poder-da-animacao-em-sprite-sheets
"JavaScript"
🚀 Um computador com sotaque inglês: Colossus e o inicio da computaçao
https://web.digitalinnovation.one/articles/um-computador-com-sotaque-ingles-colossus-e-o-inicio-da-computacao
"Informática Básica" "Arquitetura de Sistemas"
🚀 Ganhe dinheiro para realizar seus sonhos: Incubadoras, Aceleradoras e acionistas
https://web.digitalinnovation.one/articles/ganhe-dinheiro-para-realizar-seus-sonhos-incubadoras-aceleradoras-e-acionistas
"Marketing Pessoal" "Intraempreendedorismo" "Marketing Digital"
🚀 Dia 18 - Atalhos práticos do VS Code programe melhor
https://web.digitalinnovation.one/articles/dia-18-atalhos-praticos-do-vs-code-programe-melhor
"Informática Básica" "Boas práticas" "Arquitetura de Sistemas"
🚀 Como nomear variáveis num programa?
https://web.digitalinnovation.one/articles/como-nomear-variaveis-num-programa
"Programação para Internet" "Boas práticas" "Arquitetura de Sistemas"
🚀 Leilão Reverso e mas praticas na seleção de RH
https://web.digitalinnovation.one/articles/leilao-reverso-e-mas-praticas-na-selecao-de-rh
"Marketing Pessoal" "Liderança de Equipe" "Soft Skill"
🚀 Estilo CamelCase PascalCase nomeando direitinho.
https://web.digitalinnovation.one/articles/estilo-camelcase-pascalcase-nomeando-direitinho
"Programação para Internet" "Informática Básica" "Boas práticas"
🚀 Historias do Tiozão em Mainframe
https://web.digitalinnovation.one/articles/historias-do-tiozao-em-mainframe
"Equipe Motivada" "Arquitetura de Sistemas" "Soft Skill"
🚀 Netflix Clone: Como fazer um Deploy do seu WebSite em 3 passos . [Tutorial]
https://web.digitalinnovation.one/articles/netflix-clone-como-fazer-um-deploy-do-seu-website
"Programação para Internet" "GitHub" "HTML"
🚀 Hard Skill : Origens do Computador [Hardware]
https://web.digitalinnovation.one/articles/hard-skill-origens-do-computador
"Informática Básica" "Arquitetura de Sistemas"
🚀 Soft Skill: aprenda 5 regras para um bom convívio social
https://web.digitalinnovation.one/articles/soft-skill-aprenda-5-regras-para-um-bom-convivio-social
"Desperte o potencial" "Marketing Pessoal" "Soft Skill"
🚀 Roteiro teorico para trabalhar com Mainframe
https://web.digitalinnovation.one/articles/roteiro-teorico-para-trabalhar-com-mainframe
"Informática Básica" "Lógica de Programação" "Arquitetura de Sistemas"
🚀 Mainframe, conheça um pouco sobre Sistemas Centrais
https://web.digitalinnovation.one/articles/mainframe-conheca-um-pouco-sobre-sistemas-centrais
"Boas práticas" "Arquitetura de Sistemas"
🚀 Dia 17: Não faça confusão com arrays, conheça coleções indexadas e chaveadas no JavaScript
https://web.digitalinnovation.one/articles/dia-17-nao-faca-confusao-com-arrays-listas-e-colecoes-no-javascript
"Informática Básica" "JavaScript" "Arquitetura de Sistemas"
🚀 Dia 16 : Vantagens do Javascript
https://web.digitalinnovation.one/articles/dia-16-vantagens-do-javascript
"HTML" "JavaScript" "CSS"
🚀 Bootcamp e Técnica Pomodoro
https://web.digitalinnovation.one/articles/bootcamp-e-tecnica-pomodoro
"Marketing Pessoal"
🚀 Você ainda vai ouvir falar muito de DART.
https://web.digitalinnovation.one/articles/bootcamp-e-tecnica-pomodoro
"Programação para Internet" "Dart" "UI/UX"
🚀 ASCII ART - Quando simples caracteres viram arte
https://web.digitalinnovation.one/articles/ascii-art-quando-simples-caracteres-viram-arte
"Marketing Digital"
🚀 Dia 15: A Resposta é 42, minha homenagem ao Guia do Mochileiro das Galáxias
https://web.digitalinnovation.one/articles/dia15-a-resposta-e-42-minha-homenagem-ao-guia-do-mochileiro-das-galaxias
"Desperte o potencial"
🚀 Dia 14: Liberdade de criar aliada a uma boa remuneração.
https://web.digitalinnovation.one/articles/dia-14-liberdade-de-criar-aliada-a-uma-boa-remuneracao
"Marketing Pessoal" "Boas práticas" "Soft Skill"
🚀 Ah seu eu soubesse... Dia 13 – 3 Dicas para ser um dos top 10
https://web.digitalinnovation.one/articles/ah-seu-eu-soubesse-dia-13-3-dicas-para-ser-um-dos-top-10
"Marketing Pessoal" "Boas práticas" "Soft Skill"
🚀 Como incluir um video do YouTube em sua pagina HTML? [Tutorial]]
https://web.digitalinnovation.one/articles/como-incluir-um-video-do-youtube-em-sua-pagina-html-tutorial
"Programação para Internet" "HTML" "Boas práticas"
🚀 Dia 12: Dicas campeãs para terminar um Bootcamp [24 passos]
https://web.digitalinnovation.one/articles/dia-12-dicas-campeas-para-terminar-um-bootcamp
"Equipe Motivada" "Consultoria de Contratação" "Boas práticas"
🚀 Como fazer o Desafio 21 dias 21 artigos ? @Desafio21DiasNaDIO
https://web.digitalinnovation.one/articles/desafio-21-dias-21-artigos-desafio21diasnadio
"Programação para Internet" "Marketing Pessoal" "Soft Skill"
🚀 Dia 11 - Como me atualizo? 3 Fontes de Estudos
https://web.digitalinnovation.one/articles/dia-11-como-me-atualizo-3-fontes-de-estudos
"Desperte o potencial" "Marketing Pessoal"
🚀 SOFT SKILLS o que um bom DEV necessita ter e expandir.
https://web.digitalinnovation.one/articles/soft-skills-o-que-um-bom-dev-necessita-ter-e-expandir
"Marketing Pessoal" "Boas práticas" "Soft Skill"
🚀 Desafio convide 5 amigos e ajude a construir a maior Comunidade de DEVs do Brasil
https://web.digitalinnovation.one/articles/desafio-convide-5-amigos-e-ajude-a-construir-a-maior-comunidade-de-devs-do-brasil
"Desperte o potencial" "Marketing Pessoal" "Soft Skill"
🚀 ETICA em Informatica.
https://web.digitalinnovation.one/articles/etica-em-informatica
"Marketing Pessoal" "Intraempreendedorismo" "Negócios Exponenciais"
🚀 Dia 10 - Um dos melhores bootcamps: JS Game Developers
https://web.digitalinnovation.one/articles/dia-10-um-dos-melhores-bootcamps-js-game-developers
"JavaScript" "Marketing Digital" "Soft Skill"
🚀 Bugou? Por que dizemos isso a erros no aplicativo? [Você sabia?]
https://web.digitalinnovation.one/articles/bugou-por-que-dizemos-isso-a-erros-no-aplicativo-voce-sabia
"Jira" "Marketing Pessoal" "Arquitetura de Sistemas"
🚀 Cheguei agora, que curso devo fazer?
https://web.digitalinnovation.one/articles/cheguei-agora-que-curso-devo-fazer
"Liderança de Equipe" "Soft Skill"
🚀 Dia 9 - Homenagem a Incrivel Grace
https://web.digitalinnovation.one/articles/dia-9-homenagem-a-incrivel-grace
"Desperte o potencial" "Marketing Digital"
🚀 Desmitificando o LINKEDIN.
https://web.digitalinnovation.one/articles/desmitificando-o-linkedin
"Marketing Pessoal" "Liderança de Equipe" "Marketing Digital"
🚀 To do Data Science
https://web.digitalinnovation.one/articles/to-do-data-science
🚀 Hackathon, seja um as na programação [Você sabia?]
https://web.digitalinnovation.one/articles/hackathon-seja-um-as-na-programacao-voce-sabia
"Informática Básica" "Soft Skill" "Live Coding"
🚀 Nove gestantes nao geram um bebe em apenas um mes
https://web.digitalinnovation.one/articles/nove-gravidas-nao-geram-um-bebe-em-apenas-um-mes
"Desperte o potencial" "Arquitetura de Sistemas" "Soft Skill"
🚀 Seja visível, aumente sua Reputação [Você sabia?]
"Desperte o potencial" "Marketing Pessoal" "Informática Básica"
🚀 O que são entities HTML? [Você Sabia?]
https://web.digitalinnovation.one/articles/o-que-sao-entities-html-voce-sabia
"HTML" "Boas práticas" "Soft Skill"
🚀 Dia 8 - Se eu fosse eu no inicio, faria...
https://web.digitalinnovation.one/articles/dia-8-se-eu-fosse-eu-no-inicio-faria
"Desperte o potencial" "Marketing Pessoal" "Soft Skill"
🚀 Troll nao é tão divertido assim. [Você sabia?]
https://web.digitalinnovation.one/articles/troll-nao-e-tao-divertido-assim-voce-sabia
"Marketing Pessoal"
🚀 SPAM! SPAM! SPAM! [Você sabia?]
https://web.digitalinnovation.one/articles/spam-spam-spam-voce-sabia
"Marketing Pessoal" "Soft Skill"
🚀 A importância do código de conduta. [Você sabia?]
https://web.digitalinnovation.one/articles/a-importancia-do-codigo-de-conduta-voce-sabia
"Marketing Pessoal" "Boas práticas" "Soft Skill"
🚀 Saiba como ganhar 350 reais da DIO
https://web.digitalinnovation.one/articles/saiba-como-ganhar-350-reais-da-dio
🚀 Padawan na Plataforma? Esta perdido? Nao sabe o que fazer?
https://web.digitalinnovation.one/articles/padawan-na-plataforma-esta-perdido-nao-sabe-o-que-fazer
"Marketing Pessoal" "Informática Básica" "Soft Skill"
🚀 Conceitos funcionais: WORKFLOW
https://web.digitalinnovation.one/articles/conceitos-funcionais-workflow
"Desperte o potencial" "Liderança de Equipe"
🚀 Dia 7: JavaScript & Plano de Estudos
https://web.digitalinnovation.one/articles/dia-7-javascript-plano-de-estudos
"Marketing Pessoal" "JavaScript" "Node.js"
🚀 Seja visível, aumente sua Reputação
https://web.digitalinnovation.one/articles/seja-visivel-aumente-sua-reputacao-voce-sabia
"Desperte o potencial" "Marketing Pessoal"
🚀 Nao sabe emitir certificado de Bootcamp?
https://web.digitalinnovation.one/articles/nao-sabe-emitir-certificado-de-bootcamp
"Marketing Pessoal"
🚀 FAQ : Segredos e bastidores da DIO [Você sabia?]
https://web.digitalinnovation.one/articles/faq-segredos-e-bastidores-da-dio-voce-sabia
"Marketing Digital" "Soft Skill" "UI/UX"
🚀 Triplice alicerce da informatica: PEOPLEWARE
https://web.digitalinnovation.one/articles/triplice-alicerce-da-informatica-peopleware
"Marketing Pessoal" "Arquitetura de Sistemas" "Soft Skill"
🚀 Following e sua importância na comunidade DIO.
https://web.digitalinnovation.one/articles/following-e-sua-importancia-na-comunidade-dio
"Marketing Pessoal"
Republicado ✅
🚀 Dia 6 – Uma conversa sobre JavaScript
https://web.digitalinnovation.one/articles/dia-6-uma-conversa-sobre-javascript
"Programação para Internet" "JavaScript" "UI/UX"
Republicado ✅
🚀 V8 a engine do Chrome: Turbinando seu Javascript
https://web.digitalinnovation.one/articles/v8-a-engine-do-chrome-turbinando-seu-javascript
"Programação para Internet" "JavaScript" "Arquitetura de Sistemas"
Republicado ✅
🚀 Dia 5 – Explorando além do JS, mas dentro do JS: conheça o NODE.JS
https://web.digitalinnovation.one/articles/dia-5-explorando-alem-do-js-mas-dentro-do-js-conheca-o-nodejs
"Informática Básica" "JavaScript" "Node.js"
Republicado ✅
🚀 Preciso de você!!! Desenhista, ilustrador, alguém cheio de imaginação
https://web.digitalinnovation.one/articles/preciso-de-voce-desenhista-ilustrador-e-cheio-de-imaginacao
"Desperte o potencial" "Marketing Pessoal" "Intraempreendedorismo"
Republicado ✅
🚀 Dia 4 – JavaScript e laços de repetição
https://web.digitalinnovation.one/articles/dia-4-javascript-e-lacos-de-repeticao
"Programação para Internet" "JavaScript" "Arquitetura de Sistemas"
Republicado ✅
🚀 Dia 3 – JAVASCRIPT: Variáveis
https://web.digitalinnovation.one/articles/dia-3-javascript-variaveis
"Programação para Internet" "HTML" "JavaScript"
Republicado ✅
🚀 Dia 2 - Do setup ao hello world em BASIC - MSX 1988
https://web.digitalinnovation.one/articles/dia-2-do-setup-ao-hello-world-em-basic-msx-1988
"Programação para Internet" "Testes unitários" "Arquitetura de Sistemas"
Republicado ✅
🚀 Dia 1 - 5 Dicas de como você pode organizar seus estudos
https://web.digitalinnovation.one/articles/dia-1-5-dicas-de-como-voce-organiza-seus-estudos
"Programação para Internet" "Informática Básica" "Produto Digital"
Republicado ✅
🚀 Coding Dojo
https://web.digitalinnovation.one/articles/coding-dojo
"Programação para Internet" "Estrutura de dados" "Lógica de Programação"
Republicado ✅
🚀 HTML Tricks: Como navegar em diretorios?
https://web.digitalinnovation.one/articles/html-tricks-como-navegar-em-diretorios
"HTML" "JavaScript" "CSS"
Republicado ✅

🚀 Você sabe o que são bits bytes kilobytes?
https://web.digitalinnovation.one/articles/voce-sabe-o-que-sao-bits-bytes-kilobytes
"Programação para Internet" "Arquitetura de Sistemas"
Republicado ✅

🚀 Dilema da Seringa em programação de sistemas
https://web.digitalinnovation.one/articles/dilema-da-seringa-em-programacao-de-sistemas
"Informática Básica" "Arquitetura de Sistemas" "Soft Skill"
Republicado ✅

🚀 Deu ruim no levantamento de Requisitos: A Síndrome de Dr. Ivon SaF.
https://web.digitalinnovation.one/articles/deu-ruim-no-levantamento-de-requisitos-a-sindrome-de-dr-ivon-saf
"Logística" "Produto Digital" "Arquitetura de Sistemas"
Republicado ✅

* DIO - Digital Inovation One *

Inscreva-se na Dio
Vagner Bellacosa perfil na Dio

Metaverso: A Próxima Revolução da Computação?

 

Bellacosa Mainframe e o metaverso o novo hype?

☕ Um Café no Bellacosa Mainframe

Metaverso: A Próxima Revolução da Computação?

Um Guia para o Programador COBOL Padawan — Escrito em 2021, Quando o Futuro Ainda Está Sendo Programado

"Este artigo foi escrito sob a perspectiva de 2022. Ainda não conhecemos o futuro do Metaverso. Não sabemos se ele se tornará a próxima Internet ou apenas mais uma etapa na evolução da computação. O objetivo é registrar o momento histórico, as expectativas e os desafios vividos nesta época."

---

"Padawan... você consegue imaginar um terminal 3270 em três dimensões?"

Essa pergunta parece absurda.

Você provavelmente olha para sua tela verde, abre o ISPF, executa um programa COBOL, consulta uma tabela Db2 e pensa:

"Por que eu precisaria de um mundo virtual para fazer isso?"

É uma excelente pergunta.

Mas curiosamente...

Quando surgiu a Internet, muita gente fez exatamente a mesma pergunta.

Quando apareceu o smartphone, também.

Quando surgiu o Cloud Computing...

Novamente.

A história da computação é repleta de tecnologias inicialmente desacreditadas.

Algumas fracassaram completamente.

Outras mudaram o planeta.

Hoje, em 2021, existe uma palavra ocupando praticamente todas as conferências de tecnologia.

Metaverso.

Será ele a próxima revolução?

Ou apenas mais um buzzword?

Ainda não sabemos.

E justamente por isso vale a pena estudar sua origem.

---

Afinal... o que é o Metaverso?

A definição mais simples seria:

Um ambiente virtual persistente onde pessoas, empresas e sistemas podem interagir utilizando representações digitais chamadas avatares.

Mas essa definição é simplista.

Na prática, o Metaverso tenta unir diversas tecnologias:

• Internet

• Computação gráfica

• Realidade Virtual (VR)

• Realidade Aumentada (AR)

• Inteligência Artificial

• Blockchain

• Computação em Nuvem

• Redes de alta velocidade (5G)

• Sensores

• Interfaces naturais

É menos uma tecnologia única e mais uma convergência tecnológica.

---

O Metaverso nasceu muito antes do Facebook

Muita gente acredita que Zuckerberg inventou o conceito.

Na realidade...

Ele apenas popularizou o nome.

A verdadeira origem está na literatura.

---

1992 — Snow Crash

O escritor Neal Stephenson publicou o romance de ficção científica Snow Crash.

Ali apareceu pela primeira vez o termo:

Metaverse.

No livro, milhões de pessoas acessavam um universo virtual compartilhado.

Cada usuário possuía um avatar.

Existiam ruas.

Prédios.

Empresas.

Publicidade.

Economia.

Tudo muito parecido com uma Internet tridimensional.

Hoje, olhando em 2022, impressiona perceber quantas ideias daquele livro parecem tecnologicamente possíveis.

---

Ainda Antes...

Mesmo antes do nome Metaverso existir, várias experiências já caminhavam nessa direção.

Na década de 1980 surgiram ambientes gráficos multiusuário.

Na década de 1990 apareceram mundos persistentes online.

Os primeiros MMOs começaram a demonstrar algo interessante:

As pessoas gostam de viver experiências compartilhadas em mundos digitais.

---

Os Games Sempre Chegaram Primeiro

Existe uma curiosidade fascinante.

Quase toda grande inovação de interface chega primeiro aos videogames.

Foi assim com:

• mouse

• placas aceleradoras

• áudio 3D

• captura de movimentos

• realidade virtual

O Metaverso também segue esse caminho.

---

Ultima Online

Em 1997...

Milhares de jogadores conviviam dentro do mesmo mundo.

Economia própria.

Comércio.

Guildas.

Casamentos.

Política.

Era um pequeno Metaverso.

---

EverQuest

Depois veio EverQuest.

O conceito evoluiu.

Os mundos tornaram-se maiores.

Mais persistentes.

Mais sociais.

---

World of Warcraft

Talvez nenhum jogo tenha demonstrado tão claramente o potencial de um universo virtual.

Milhões de jogadores.

Economia.

Mercado.

Profissões.

Eventos.

Organizações complexas.

Na prática...

Muitos jovens aprenderam liderança dentro de guildas.

---

Second Life

Em 2003 surgiu um caso extremamente curioso.

Second Life.

Ao contrário dos jogos tradicionais...

Não existia exatamente um objetivo.

As pessoas apenas viviam.

Compravam terrenos.

Construíam casas.

Realizavam reuniões.

Criavam empresas.

Faziam palestras.

Até universidades passaram a experimentar esse ambiente.

Será que o Second Life estava apenas vinte anos adiantado?

Ainda não sabemos.

---

Os Avatares

No Metaverso...

Você praticamente nunca aparece como realmente é.

Você cria um representante digital.

Seu Avatar.

A palavra vem do sânscrito.

Originalmente significava:

Manifestação.

Encarnação.

Representação.

Hoje passou a significar nossa identidade digital.

Talvez, no futuro, um profissional possua diferentes avatares.

Um corporativo.

Outro social.

Outro para entretenimento.

---

A Busca Pela Imersão

Durante décadas a indústria tenta responder uma pergunta.

Como fazer alguém esquecer que está olhando para uma tela?

Essa busca criou diversos equipamentos.

---

Data Glove

Na década de 1980 surgiram luvas capazes de detectar movimentos dos dedos.

Pareciam ficção científica.

Mas funcionavam.

---

Bellacosa Mainframe e a lendaria luva power glove

Nintendo Power Glove

Aqui existe um dos maiores ícones da cultura pop.

Em 1989 surgiu a famosa Power Glove.

Ela prometia controlar jogos apenas com movimentos das mãos.

Era revolucionária.

Na teoria.

Na prática...

A tecnologia ainda não era suficientemente precisa.

Mesmo assim, marcou gerações.

Curiosamente...

A ideia nunca morreu.

Hoje vários controladores modernos utilizam exatamente esse conceito.

---

Bellacosa Mainframe e as mascaras de realidade virtual

Óculos de Realidade Virtual

Outra tentativa histórica.

Desde os anos 1990 surgiram inúmeros headsets.

Mas havia limitações:

• peso

• resolução

• atraso na imagem

• desconforto

• custo

Agora, em 2022, a tecnologia parece finalmente atingir maturidade suficiente para uso comercial.

---

A Grande Mudança de 2021

Quando Mark Zuckerberg anunciou a mudança de Facebook para Meta...

O mercado inteiro parou.

Não era apenas uma troca de nome.

Era uma declaração estratégica.

A empresa estava dizendo:

"O próximo capítulo da Internet será tridimensional."

Isso desencadeou investimentos bilionários.

---

O Interesse das Empresas

Grandes organizações começaram a imaginar aplicações.

Treinamentos.

Universidades.

Museus.

Arquitetura.

Medicina.

Eventos.

Comércio.

Turismo.

Atendimento ao cliente.

Até bancos estudam possibilidades.

---

E o Mainframe?

Você pode estar pensando.

"O que isso muda para quem programa COBOL?"

Mais do que parece.

Imagine um operador de datacenter utilizando realidade aumentada para localizar rapidamente equipamentos.

Imagine treinamentos de recuperação de desastre em ambientes virtuais.

Imagine novos funcionários caminhando virtualmente por um IBM Z antes mesmo de entrar em um CPD.

Imagine documentação interativa.

Imagine um Sysprog visualizando relações entre LPARs como um mapa tridimensional.

Ainda parece ficção.

Mas várias pesquisas caminham exatamente nessa direção.

---

O Valor Real

Toda tecnologia precisa responder uma pergunta.

Quanto valor ela entrega?

O Metaverso promete reduzir custos em:

• treinamento

• engenharia

• manutenção

• colaboração internacional

Se cumprir essa promessa...

Poderá transformar diversas áreas.

---

Os Grandes Desafios

Nem tudo são flores.

Existem obstáculos importantes.

Hardware

Headsets ainda são caros.

---

Ergonomia

Usar um equipamento durante horas pode causar fadiga.

---

Redes

Experiências imersivas exigem baixa latência.

---

Segurança

Como proteger identidades digitais?

Como impedir fraudes?

Como autenticar usuários?

---

Privacidade

Sensores capturam:

• movimentos

• direção dos olhos

• voz

• expressões faciais

Quem controlará esses dados?

---

Padronização

Hoje cada empresa constrói seu próprio ambiente.

Será possível existir um Metaverso aberto?

Ou teremos vários "metaversos" incompatíveis entre si?

---

Blockchain Será Necessário?

Muitos acreditam que NFTs permitirão possuir objetos digitais.

Outros discordam.

Ainda é cedo para saber.

Em 2022 não existe consenso.

---

Curiosidades

Pouca gente sabe que:

• O termo Avatar possui milhares de anos.

• O conceito de Metaverso nasceu em um romance.

• O Power Glove virou item cult.

• O Second Life já permitia comprar imóveis virtuais muito antes da atual onda.

• Muitos conceitos vistos hoje já apareciam em filmes como Tron (1982), The Lawnmower Man (1992), The Matrix (1999) e Ready Player One (2018).

A ficção científica frequentemente serve como laboratório de ideias para a engenharia.

---

Easter Egg Bellacosa Mainframe

Imagine um operador de 1985 ouvindo a seguinte frase:

"Daqui a algumas décadas você poderá entrar virtualmente dentro do datacenter, caminhar ao redor de um IBM Z, visualizar o uso de CPU em tempo real como hologramas e conversar com especialistas de outros países sem sair da sala."

Talvez ele respondesse:

"Primeiro me diga se o JES2 terminou o processamento da folha de pagamento."

E, honestamente...

Ele teria razão.

Porque toda inovação precisa conviver com aquilo que já funciona.

---

O Futuro Ainda Está Aberto

Em 2022 ninguém possui respostas definitivas.

Talvez o Metaverso se torne a maior evolução da Internet desde a Web.

Talvez encontre nichos específicos, como treinamento, engenharia, medicina e entretenimento.

Talvez leve muitos anos até amadurecer.

Talvez novas tecnologias mudem completamente essa visão.

O que sabemos é que a computação sempre evolui em ciclos. Algumas ideias chegam cedo demais, outras precisam esperar que hardware, redes e software alcancem o mesmo nível de maturidade. O Metaverso pode estar exatamente nesse ponto de inflexão.

Para o programador COBOL padawan, a lição mais importante não é apostar cegamente nem rejeitar por preconceito. É observar, estudar, experimentar e compreender como cada nova tecnologia pode complementar o ecossistema corporativo.

Afinal, quem imaginaria, há sessenta anos, que programas COBOL escritos para grandes computadores continuariam processando trilhões de dólares enquanto convivem com APIs REST, containers, nuvem, inteligência artificial e aplicações móveis?

Se existe uma lição que o IBM Z ensina todos os dias, é esta:

A inovação não acontece substituindo tudo de uma vez. Ela acontece integrando o novo com aquilo que já provou seu valor.

Talvez, daqui a dez anos, olhemos para 2022 como o verdadeiro início de uma nova era da computação. Ou talvez como apenas mais um capítulo da longa história da evolução digital.

Hoje, ainda não sabemos.

E é justamente isso que torna este momento tão fascinante.

 

Bellacosa Mainframe apresenta JCL V2R5 Job Control Language

🔥 JCL no z/OS V2R5 — o imortal que virou pilar do futuro

---

📅 Datas importantes

• Release (GA): setembro de 2021

• Final de suporte IBM (EoS): 30 de setembro de 2027

O z/OS V2R5 não “atualizou” o JCL.
Ele assumiu oficialmente que o JCL faz parte do futuro do mainframe.

---

🧬 Contexto histórico

Quando o z/OS V2R5 chegou, o mundo já estava diferente:

• Cloud híbrida consolidada

• DevOps institucionalizado

• APIs como padrão

• Observabilidade, automação, SRE

• Mainframe 100% integrado ao ecossistema corporativo

E no centro de tudo isso…

👉 o JCL seguia intocável, sólido, previsível.

Bellacosa diria sem rodeios:

“O futuro chegou. E o JCL já estava lá esperando.”

---

JCL V2R5 Job Control Language

✨ O que há de novo no JCL no V2R5 (sem quebrar nada)

Aqui está a genialidade do V2R5:
nenhuma ruptura, só consolidação.

🆕 1. JCL como contrato operacional definitivo

No V2R5:

• JCL é acionado por:

  • APIs REST

  • eventos

  • pipelines CI/CD

  • schedulers corporativos

• JCL vira interface estável entre o mundo moderno e o core bancário

👉 O job é o endpoint invisível.

---

🆕 2. JES2 e DFSMS no auge da maturidade

• Spool altamente escalável

• Restart/recovery extremamente previsíveis

• Storage totalmente orientado a políticas

• Menos parâmetros “hardcoded” no JCL

O sistema sabe mais.
O JCL fica mais limpo.

---

🆕 3. Batch como serviço

No V2R5, o batch deixa de ser:
❌ “processo noturno”

E passa a ser:
✅ serviço corporativo sob demanda

Chamado quando:

• um evento ocorre

• uma API é acionada

• um fechamento precisa acontecer

---

🔧 Melhorias percebidas no chão de fábrica

✔ Jobs mais rápidos e previsíveis
✔ Menos intervenção humana
✔ Menos tuning manual
✔ JCL tratado como código crítico
✔ Auditoria e rastreabilidade melhores

Nada mudou no //STEP01 EXEC.
Tudo mudou no papel do JCL.

---

🥚 Easter Eggs (para mainframer raiz)

• 🥚 JCL escrito no OS/360 ainda roda no V2R5

• 🥚 IEFBR14 continua sendo usado (e continuará)

• 🥚 Comentários no JCL mais antigos que containers 😅

• 🥚 O erro clássico permanece:

  • RC ignorado

  • DISP mal planejado

  • dataset em uso

👉 Tecnologia muda. Erro humano não.

---

💡 Dicas Bellacosa para JCL no z/OS V2R5

🔹 Trate JCL como infraestrutura crítica
🔹 Versione JCL como código
🔹 Padronize nomes, comentários e RC
🔹 Use sempre:

• IF / THEN / ELSE

• mensagens claras

• logs bem definidos

🔹 Lembre-se:

Esse JCL vai sobreviver a arquiteturas, gestores e modas.

---

📈 Evolução do JCL até o V2R5

Era	Papel do JCL
OS/360	Controle batch
MVS	Automação
OS/390	Base corporativa
z/OS V1.x	Orquestrador
z/OS V2R2–V2R4	Mundo híbrido
z/OS V2R5	Pilar do futuro

👉 No V2R5, o JCL deixa de ser “legacy” e vira fundação estratégica.

---

📜 Exemplo de JCL “cara de V2R5”

//BELLV25  JOB (ACCT),'JCL z/OS V2R5',
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//*
//* JOB PODE SER DISPARADO POR API, PIPELINE OU SCHEDULER
//*
//STEP01   EXEC PGM=COREPROC
//STEPLIB  DD  DSN=BELLACOSA.LOADLIB,DISP=SHR
//SYSOUT   DD  SYSOUT=*
//*
//IF (STEP01.RC = 0) THEN
//STEP02   EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  DELETE BELLACOSA.WORK.TEMP
  SET MAXCC = 0
/*
//ENDIF

💬 Comentário Bellacosa:

“Esse job não sabe se foi chamado por um operador
ou por uma API em Kubernetes.
E nem precisa saber.”

---

🧠 Comentário final

O JCL no z/OS V2R5 é a prova definitiva de que:

• estabilidade vence hype

• previsibilidade vence moda

• legado bem feito vira futuro

Enquanto outras plataformas tentam “reinventar” automação,
o JCL segue fazendo o que sempre fez:

🔥 entregar, fechar, garantir e não falhar.

JCL não é passado.
JCL é confiança acumulada ao longo de décadas.

 

Bellacosa Mainframe o samurai dos robots Tanaka Hisashige

☕⚙️💣 O PROGRAMADOR QUE CRIOU ROBÔS NO TEMPO DOS SAMURAIS — TANAKA HISASHIGE E O MAINFRAME MECÂNICO QUE ANTECEDEU A TOSHIBA

Existe uma curiosidade fascinante na história da tecnologia que poucos profissionais de TI conhecem.

Quando pensamos nos grandes nomes da engenharia, normalmente lembramos de Alan Turing, Thomas Edison, Nikola Tesla, Grace Hopper ou dos pioneiros da IBM. Mas existe um personagem extraordinário que viveu no Japão do século XIX e que, sob a ótica de um profissional de mainframe, parece ter vindo diretamente do futuro.

Seu nome era Tanaka Hisashige.

E se você observar atentamente sua trajetória, perceberá algo impressionante:

Tanaka estava criando sistemas automatizados quando o mundo sequer imaginava a existência de computadores.

Para entender sua importância, precisamos voltar ao Japão do início do século XIX.

Naquela época, o país ainda vivia sob o xogunato Tokugawa. Os samurais dominavam a sociedade, a industrialização praticamente não existia e boa parte do conhecimento tecnológico europeu demorava anos para chegar ao arquipélago.

Foi nesse ambiente que nasceu Tanaka Hisashige, em 1799.

Desde criança, ele demonstrava uma curiosidade quase obsessiva por mecanismos.

Enquanto outras pessoas observavam um relógio para saber as horas, Tanaka queria desmontá-lo para entender como funcionava.

Enquanto outras pessoas admiravam uma máquina, ele queria descobrir como construí-la.

Esse comportamento é familiar para qualquer programador experiente.

Afinal, quantos profissionais de TI começaram suas carreiras desmontando equipamentos apenas para descobrir o que existia dentro deles?

Ainda jovem, Tanaka tornou-se conhecido pela criação dos famosos Karakuri Ningyō.

Os Karakuri eram autômatos mecânicos extremamente sofisticados para a época.

Imagine um robô.

Agora remova a eletricidade.

Remova os motores.

Remova os circuitos.

Remova os microprocessadores.

O que sobra?

Engrenagens, molas, pesos e mecanismos cuidadosamente projetados.

Foi exatamente isso que Tanaka utilizou para construir máquinas capazes de realizar tarefas aparentemente inteligentes.

Seu autômato mais famoso servia chá aos convidados.

O boneco caminhava sozinho, transportava a bandeja, aguardava que a xícara fosse retirada e retornava ao ponto inicial quando o convidado terminava de beber.

Para um observador moderno, isso parece uma simples curiosidade histórica.

Para um profissional de automação, porém, a interpretação é diferente.

Aquilo era um workflow.

Um processo automatizado.

Uma rotina programada.

Um job batch mecânico executando instruções pré-definidas.

Em outras palavras, Tanaka estava criando automação muito antes da palavra automação existir.

Mas o verdadeiro salto tecnológico viria anos depois.

Entre suas criações mais impressionantes está o lendário Man-nen Dokei, conhecido internacionalmente como o Myriad Year Clock.

Talvez este seja o equipamento que mais desperte admiração entre engenheiros modernos.

À primeira vista, parece apenas um relógio ornamentado.

Na prática, era um sistema mecânico de extrema complexidade.

O equipamento era capaz de controlar simultaneamente diversos calendários, indicar fases da Lua, acompanhar ciclos astronômicos e adaptar-se ao peculiar sistema japonês de medição do tempo utilizado na época.

Tudo isso sem eletrônica.

Sem software.

Sem firmware.

Sem banco de dados.

Sem energia elétrica.

Quando observamos seus mecanismos internos, a sensação é semelhante à de analisar um programa COBOL escrito por um desenvolvedor brilhante.

Cada componente possui uma função específica.

Cada engrenagem depende de outra.

Cada movimento desencadeia uma cadeia de eventos cuidadosamente planejada.

Nada é aleatório.

Nada é supérfluo.

Tudo foi projetado para funcionar durante anos com extrema confiabilidade.

Se existisse uma certificação de alta disponibilidade no século XIX, aquele relógio certamente teria sido aprovado.

Com a abertura gradual do Japão ao Ocidente, uma nova oportunidade surgiu.

Tecnologias europeias começaram a chegar ao país.

Máquinas a vapor, telégrafos e equipamentos industriais despertavam a curiosidade dos engenheiros japoneses.

Enquanto muitos observavam aquelas inovações com cautela, Tanaka fazia aquilo que todo grande especialista em tecnologia faz diante de uma novidade.

Ele estudava.

Desmontava mentalmente.

Entendia os conceitos.

E construía sua própria versão.

Em pouco tempo estava envolvido na fabricação de motores, equipamentos industriais e sistemas telegráficos.

É importante compreender o tamanho desse feito.

Hoje qualquer profissional pode assistir a vídeos, participar de cursos online ou consultar documentação técnica instantaneamente.

Tanaka não possuía nada disso.

Muitas vezes precisava interpretar informações incompletas, realizar engenharia reversa e desenvolver soluções praticamente do zero.

Era como receber apenas o dump de um ABEND e reconstruir sozinho toda a aplicação.

Seu talento chamou a atenção do governo japonês durante a Restauração Meiji.

O país precisava modernizar sua infraestrutura rapidamente.

Ferrovias, telecomunicações e sistemas industriais tornaram-se prioridades nacionais.

Tanaka foi convocado para participar dessa transformação.

Em 1875 fundou a Tanaka Seisakusho.

O objetivo inicial era fabricar equipamentos telegráficos para apoiar a expansão das comunicações japonesas.

Parece algo simples.

Mas, sob uma perspectiva histórica, foi um marco gigantesco.

Estamos falando da origem de uma empresa que, décadas depois, evoluiria para uma das maiores corporações tecnológicas do planeta.

O nome moderno dessa organização é conhecido por praticamente qualquer profissional de tecnologia:

Toshiba.

Sim.

A gigantesca Toshiba surgiu das iniciativas de um inventor que começou construindo autômatos mecânicos durante a era dos samurais.

Existe uma lição extremamente valiosa nessa história.

Quando analisamos as realizações de Tanaka Hisashige, percebemos que sua verdadeira genialidade não estava apenas nas máquinas.

Estava na forma de pensar.

Ele observava sistemas.

Identificava processos.

Compreendia dependências.

Criava mecanismos confiáveis.

Automatizava atividades repetitivas.

Reduzia intervenção humana.

Aumentava eficiência.

Em essência, ele aplicava exatamente os mesmos princípios utilizados atualmente por arquitetos de software, especialistas DevOps, engenheiros de automação e profissionais de mainframe.

As tecnologias mudaram.

As ferramentas mudaram.

As linguagens mudaram.

Mas a lógica fundamental continua a mesma.

Resolver problemas por meio de sistemas confiáveis.

Talvez seja por isso que sua história continue tão relevante mais de duzentos anos depois.

Tanaka Hisashige nos lembra que inovação não depende apenas de ferramentas modernas.

Não depende de inteligência artificial.

Não depende de nuvem.

Não depende de processadores avançados.

A verdadeira inovação nasce da curiosidade.

Nasce da observação.

Nasce da vontade de compreender como as coisas funcionam.

E principalmente da coragem de construir algo que ainda não existe.

Por isso, quando alguém afirmar que automação começou com computadores, vale lembrar da figura daquele engenheiro japonês cercado por engrenagens, molas e mecanismos de precisão.

Enquanto o resto do mundo ainda tentava compreender as máquinas do presente, Tanaka Hisashige já estava projetando o futuro.

Ou, como diríamos no Bellacosa Mainframe:

"Quando os outros ainda estavam procurando o manual de operação, Tanaka já tinha colocado o sistema em produção."

☕ Lição Bellacosa Mainframe: Todo grande sistema nasce da mesma pergunta que guiou Tanaka há mais de 200 anos: "Como posso fazer isso funcionar sozinho, de forma confiável e por muito tempo?" A resposta para essa pergunta continua movendo desde autômatos mecânicos até os maiores mainframes do planeta.

Why-Why Analysis sem Mistérios : O Guia do Programador COBOL Padawan para Encontrar a Causa Raiz antes que o ABEND Ataque Novamente

 

Bellacosa Mainframe e tecnica do why-why analysis

☕ Um Café no Bellacosa Mainframe

Why-Why Analysis sem Mistérios

O Guia do Programador COBOL Padawan para Encontrar a Causa Raiz antes que o ABEND Ataque Novamente

Há uma cena que se repete diariamente nos corredores digitais de muitas empresas.

Um job termina com ABEND S0C7.

O operador abre o chamado.

O programador examina o SYSOUT.

Encontra um campo numérico contendo caracteres inválidos.

Corrige o registro, reinicia o processamento e anuncia:

“Problema resolvido.”

A ponte de comando comemora. O batch volta a navegar. O SLA é preservado. O café continua quente.

Três dias depois, o mesmo erro acontece novamente.

Outro registro inválido. Outro S0C7. Outro restart. Outro chamado. Outra madrugada perdida.

Nesse momento, o programador COBOL Padawan começa a perceber uma verdade desconfortável:

O erro foi corrigido, mas o problema não foi resolvido.

É justamente nesse ponto que entra a Why-Why Analysis, também conhecida como 5 Whys, Five Whys, Análise dos Cinco Porquês ou simplesmente Análise Por Quê–Por Quê.

Trata-se de uma técnica aparentemente simples: diante de um problema, perguntamos repetidamente “por quê?” até encontrar a causa fundamental que permitiu que aquele evento acontecesse.

Mas não se engane.

A técnica não consiste em repetir “por quê?” como uma criança curiosa até alguém perder a paciência. Ela é uma disciplina de investigação, pensamento lógico, observação, análise de evidências e melhoria contínua.

No universo Bellacosa Mainframe, podemos compará-la ao trabalho de um oficial científico da Frota Estelar: não basta saber que o sistema perdeu potência. É necessário descobrir qual componente falhou, por que falhou, que condição permitiu a falha e o que deve ser modificado para que a nave não fique à deriva novamente.

Prepare o café, ajuste o terminal 3270 e venha para a sala de diagnóstico. Nossa missão é viajar além do sintoma e alcançar a verdadeira causa raiz.

---

1. O que é a Why-Why Analysis?

A Why-Why Analysis é uma técnica de análise de causa raiz, ou Root Cause Analysis — RCA, utilizada para investigar problemas, falhas, defeitos, atrasos, interrupções e resultados indesejados.

Seu funcionamento básico pode ser representado assim:

Problema observado
       ↓
Por que aconteceu?
       ↓
Causa imediata
       ↓
Por que essa causa existia?
       ↓
Causa intermediária
       ↓
Por que o processo permitiu isso?
       ↓
Causa sistêmica
       ↓
Contramedida

O método parte do princípio de que aquilo que enxergamos inicialmente costuma ser apenas a manifestação visível de algo mais profundo.

Um ABEND é uma manifestação.

Uma transação lenta é uma manifestação.

Um arquivo não catalogado é uma manifestação.

Uma reclamação de cliente é uma manifestação.

Um job atrasado é uma manifestação.

Uma falha de deploy é uma manifestação.

A pergunta correta não é apenas:

“O que aconteceu?”

Também precisamos perguntar:

“Por que o sistema permitiu que isso acontecesse?”

Essa segunda pergunta nos leva do território dos sintomas para o território dos processos.

---

2. A origem da técnica na Toyota

A técnica dos Cinco Porquês está associada a Sakichi Toyoda, inventor, industrial japonês e fundador do grupo que daria origem à Toyota.

Posteriormente, a abordagem foi incorporada e popularizada no Toyota Production System, especialmente por nomes como Taiichi Ohno, um dos principais arquitetos do sistema de produção da empresa.

A lógica era poderosa: quando uma máquina parava, o objetivo não era apenas colocá-la novamente em funcionamento. Era necessário compreender por que ela havia parado e impedir que a mesma falha voltasse a ocorrer.

Taiichi Ohno defendia que, ao repetir a pergunta “por quê?” algumas vezes, a natureza do problema e sua solução poderiam se tornar mais claras.

A técnica passou a caminhar ao lado de conceitos como:

• Kaizen;

• Lean Manufacturing;

• Just in Time;

• Jidoka;

• eliminação de desperdícios;

• padronização;

• melhoria contínua;

• gestão visual;

• qualidade na fonte.

Com o tempo, sua aplicação atravessou os portões das fábricas.

Hoje, a Why-Why Analysis pode ser aplicada em:

• desenvolvimento de software;

• operação de data centers;

• mainframes;

• DevOps;

• segurança da informação;

• atendimento ao cliente;

• logística;

• engenharia;

• saúde;

• projetos;

• gestão da qualidade;

• processos administrativos;

• análise de incidentes.

O chão de fábrica tornou-se também o chão digital.

A máquina industrial pode ser um servidor.

A linha de produção pode ser um pipeline CI/CD.

O defeito em uma peça pode ser um bug em um programa COBOL.

A parada de produção pode ser uma indisponibilidade em CICS.

Os princípios permanecem os mesmos.

---

3. Por que são cinco porquês?

O nome “Cinco Porquês” pode causar uma interpretação equivocada: a ideia de que obrigatoriamente devemos fazer exatamente cinco perguntas.

Isso não é verdade.

Em alguns casos, três perguntas serão suficientes.

Em outros, poderemos precisar de seis, sete ou dez.

O número cinco funciona como uma referência prática. Em muitos problemas, aproximadamente cinco níveis de investigação conseguem atravessar as causas superficiais e alcançar um ponto em que uma ação sistêmica pode ser implementada.

Portanto, a regra correta é:

Pergunte “por quê?” quantas vezes forem necessárias para chegar a uma causa que possa ser controlada, corrigida e comprovada.

Não pare no quinto porquê apenas porque o formulário terminou.

Também não continue indefinidamente até chegar a respostas filosóficas como:

“Porque os seres humanos criaram computadores.”

A investigação precisa terminar em uma causa relevante para o processo analisado.

---

4. Sintoma, problema, causa e causa raiz

Um dos principais desafios da análise é separar quatro conceitos diferentes.

Sintoma

É a manifestação percebida.

Exemplos:

• o job atrasou;

• a transação ficou lenta;

• o cliente reclamou;

• o programa terminou com S0C7;

• o arquivo não foi criado;

• o pipeline falhou.

Problema

É a descrição objetiva do evento indesejado.

Exemplo:

O job FATUR001 terminou com S0C7 às 02h17, durante o processamento do arquivo CLIENTES.DIARIO, no registro 47.321.

Quanto mais precisa for a definição, melhor será a investigação.

Causa imediata

É aquilo que diretamente provocou o evento.

Exemplo:

Um campo definido como numérico continha o valor “12A45”.

Causa raiz

É a condição fundamental que permitiu que a causa imediata existisse.

Exemplo:

A aplicação não possui validação de dados na entrada, e o processo de integração permite que arquivos fora do layout cheguem ao programa de faturamento.

A diferença é gigantesca.

A causa imediata explica o erro.

A causa raiz explica a recorrência.

---

5. Contramedida não é o mesmo que correção

Em Lean, costuma-se usar a palavra contramedida.

A correção trata o problema presente.

A contramedida reduz ou elimina a possibilidade de repetição.

Considere este cenário:

Problema: programa terminou com S0C7.
Correção: alterar manualmente o registro inválido.
Contramedida: validar o arquivo antes do processamento e rejeitar registros incompatíveis com o layout.

A correção permite continuar.

A contramedida transforma o processo.

Outro exemplo:

Problema: job não encontrou a LOADLIB.
Correção: incluir a biblioteca manualmente na STEPLIB.
Contramedida: corrigir a PROC catalogada e estabelecer controle de versão para o JCL.

Reiniciar um serviço não é necessariamente uma contramedida.

Aumentar memória não é necessariamente uma contramedida.

Pedir para alguém “tomar mais cuidado” quase nunca é uma contramedida.

Uma boa contramedida atua sobre o processo, o sistema, o padrão, o treinamento, a automação ou os controles.

---

6. O passo a passo da Why-Why Analysis

Vamos montar uma sequência digna de um procedimento operacional da Frota Estelar.

Passo 1 — Defina o problema com precisão

Evite descrições vagas:

O sistema está ruim.
O batch está lento.
O CICS travou.
O usuário fez algo errado.

Prefira descrições mensuráveis:

O job PGTO010 aumentou seu tempo de execução de 35 minutos para 2 horas e 48 minutos após a mudança de 14 de julho.

Uma boa descrição deve responder:

• o que aconteceu;

• quando aconteceu;

• onde aconteceu;

• qual componente foi afetado;

• qual era o comportamento esperado;

• qual foi o comportamento observado;

• qual foi o impacto.

---

Passo 2 — Vá ao Gemba digital

No Lean, Gemba significa o lugar real onde o trabalho acontece.

Em uma fábrica, é a linha de produção.

No mainframe, o Gemba pode ser:

• SDSF;

• JESMSGLG;

• JESJCL;

• JESYSMSG;

• SYSLOG;

• dump;

• IPCS;

• RMF;

• SMF;

• CICS trace;

• Db2 accounting trace;

• EXPLAIN;

• log do pipeline;

• histórico do scheduler;

• mensagens de console;

• spool do job.

Não investigue apenas por telefone.

Não aceite somente:

“Disseram que o sistema caiu.”

Vá até a evidência.

O mainframe possui uma memória operacional extraordinária. Muitos eventos deixam rastros em logs, mensagens, registros SMF, dumps e relatórios.

O programador que aprende a ler esses rastros deixa de ser apenas um codificador e começa a se tornar um investigador de sistemas.

---

Passo 3 — Pergunte o primeiro porquê

A resposta deve estar baseada em evidência.

Problema:

O job terminou com S0C7.

Por quê?

Porque uma instrução aritmética tentou processar um campo com conteúdo inválido.

Essa resposta deve ser sustentada por informações como:

• offset da falha;

• dump;

• statement correspondente;

• conteúdo do campo;

• layout;

• valores dos registradores;

• mapa de compilação.

---

Passo 4 — Transforme a resposta na próxima pergunta

Agora pergunte:

Por que o campo continha conteúdo inválido?

Resposta:

Porque o arquivo de entrada trouxe caracteres alfabéticos em uma posição definida como numérica.

Próxima pergunta:

Por que o arquivo trouxe caracteres alfabéticos nessa posição?

Resposta:

Porque o sistema fornecedor alterou o layout sem atualizar o copybook utilizado pelo programa consumidor.

Próxima pergunta:

Por que a alteração de layout não atualizou o copybook?

Resposta:

Porque os dois sistemas não possuem um processo integrado de gestão e versionamento de contratos de dados.

Agora estamos muito além do S0C7.

Chegamos a uma falha de governança.

---

Passo 5 — Verifique a cadeia lógica

Cada resposta precisa explicar diretamente a pergunta anterior.

A cadeia deve fazer sentido de baixo para cima.

Podemos usar a chamada lógica do “portanto”:

Não existe gestão de versão do layout.
Portanto, o copybook do consumidor ficou desatualizado.
Portanto, o programa interpretou os dados incorretamente.
Portanto, um campo alfanumérico chegou a uma operação numérica.
Portanto, ocorreu S0C7.

Quando a cadeia é coerente nos dois sentidos, a análise ganha força.

Caso existam saltos lógicos, suposições ou generalizações, precisamos investigar mais.

---

Passo 6 — Identifique o ponto de prevenção

Uma boa causa raiz normalmente aponta para um ponto onde a recorrência pode ser evitada.

Pergunte:

O que podemos modificar para impedir que essa cadeia se repita?

Possíveis ações:

• versionar copybooks;

• validar arquivos;

• criar testes de contrato;

• automatizar comparação de layouts;

• exigir aprovação formal para mudanças;

• incluir verificação no pipeline;

• gerar documentação compartilhada;

• notificar sistemas consumidores.

A melhor solução pode combinar várias ações.

---

Passo 7 — Defina responsável, prazo e evidência de sucesso

Uma análise sem plano de ação vira decoração de reunião.

Toda contramedida precisa de:

• responsável;

• prazo;

• prioridade;

• critério de conclusão;

• forma de validação;

• acompanhamento.

Exemplo:

Ação: implementar validação automática do layout antes do processamento.
Responsável: equipe de integração.
Prazo: 30 dias.
Critério de sucesso: 100% dos arquivos incompatíveis rejeitados antes da execução do programa COBOL.
Monitoramento: relatório diário e alerta automático.

---

Passo 8 — Monitore a recorrência

Depois da mudança, acompanhe:

• o problema voltou?

• surgiu outro efeito?

• o tempo de processamento melhorou?

• a taxa de falhas caiu?

• a equipe está seguindo o novo padrão?

• a automação está funcionando?

• a documentação foi atualizada?

A melhoria só é confirmada quando os resultados demonstram que a causa foi controlada.

---

7. Exemplo completo: ABEND S0C7 em COBOL

Vamos entrar em uma investigação completa.

Problema

O programa COBOL FATU120 terminou com ABEND S0C7 durante o processamento noturno.

Primeiro porquê

Por que ocorreu S0C7?

Porque o programa tentou somar um campo com conteúdo não numérico.

Segundo porquê

Por que o campo continha valor não numérico?

Porque o campo VALOR-PARCELA recebeu espaços e letras.

Terceiro porquê

Por que o programa recebeu espaços e letras em um campo esperado como numérico?

Porque o arquivo de entrada foi gerado com um layout diferente do copybook utilizado.

Quarto porquê

Por que o layout do arquivo estava diferente?

Porque o sistema de origem alterou o tamanho e o formato do campo sem comunicar formalmente os consumidores.

Quinto porquê

Por que não houve comunicação formal?

Porque não existe processo corporativo de controle de versão, aprovação e distribuição dos contratos de arquivos.

Causa raiz

Ausência de governança sobre layouts compartilhados.

Correção imediata

Corrigir o registro e reprocessar o job.

Contramedidas

• criar repositório central de copybooks;

• versionar layouts;

• implementar testes de contrato;

• validar comprimento e formato do arquivo;

• estabelecer processo de aprovação;

• incluir consumidores na revisão de mudanças;

• adicionar tratamento de dados inválidos no COBOL.

Observe como a investigação saiu de uma instrução aritmética e terminou em governança de integração.

Essa é a força do método.

---

8. Exemplo: batch lento no Db2

Problema

O job de faturamento passou de 40 minutos para quatro horas.

Por quê 1

Porque uma consulta SQL passou a consumir muito mais tempo.

Por quê 2

Porque o Db2 escolheu um access path com table space scan.

Por quê 3

Porque as estatísticas das tabelas estavam desatualizadas.

Por quê 4

Porque a rotina de RUNSTATS não executou após uma grande carga de dados.

Por quê 5

Porque o processo de carga não possui dependência automática para atualização de estatísticas.

Causa raiz

O fluxo operacional não associa grandes cargas de dados à manutenção das estatísticas necessárias ao otimizador.

Contramedidas

• executar RUNSTATS após cargas significativas;

• revisar o REBIND;

• monitorar mudanças de access path;

• criar alertas de cardinalidade;

• integrar manutenção ao scheduler;

• avaliar índices e distribuição dos dados.

A solução superficial seria “criar um índice”.

Mas talvez o índice já exista.

Talvez o verdadeiro problema seja o processo que deixou o otimizador trabalhando com uma visão antiga dos dados.

---

9. Exemplo: transação CICS lenta

Problema

A transação PAG1 passou a responder em 18 segundos.

Por quê 1

Porque uma chamada a um serviço externo demorava 15 segundos.

Por quê 2

Porque a fila MQ acumulou milhares de mensagens.

Por quê 3

Porque uma instância consumidora estava parada.

Por quê 4

Porque o processo Java terminou por falta de memória.

Por quê 5

Porque uma atualização introduziu um vazamento de memória não detectado nos testes.

Por quê 6

Porque os testes não incluíam execução prolongada com carga semelhante à produção.

Causa raiz

Ausência de testes de resistência e observação de consumo de memória no pipeline.

Contramedidas

• teste de carga prolongado;

• análise de heap;

• alertas de crescimento de memória;

• rollback automático;

• limite de backlog da fila;

• monitoramento ponta a ponta.

A transação CICS era a vítima visível.

A causa real estava muito longe dela.

---

10. O erro de culpar pessoas

Uma das regras mais importantes da Why-Why Analysis é:

Analise o processo, não ataque a pessoa.

Uma resposta como:

“O operador errou.”

raramente representa uma boa causa raiz.

Precisamos continuar:

Por que o operador errou?

Talvez:

• o procedimento estivesse desatualizado;

• a tela fosse confusa;

• não existisse validação;

• o treinamento fosse insuficiente;

• duas opções tivessem nomes semelhantes;

• o sistema permitisse uma ação perigosa sem confirmação;

• a equipe estivesse sobrecarregada;

• a documentação não estivesse disponível.

Chamar tudo de “erro humano” é frequentemente uma maneira elegante de encerrar a investigação cedo demais.

Pessoas cometem erros.

Sistemas maduros são projetados para:

• evitar erros;

• detectar erros;

• limitar impactos;

• facilitar recuperação;

• tornar a ação correta mais simples;

• tornar a ação incorreta mais difícil.

A pergunta não deve ser apenas:

“Quem fez?”

Mas:

“Que condição tornou esse erro possível?”

Essa mudança de mentalidade fortalece a cultura de aprendizado e evita a caça aos culpados.

---

11. Quando a análise se transforma em árvore

Nem todo problema possui uma única linha causal.

Algumas falhas resultam da combinação de vários fatores.

Exemplo:

Job atrasou
 ├── volume de dados aumentou
 ├── CPU ficou limitada
 ├── SQL perdeu índice
 └── execução iniciou fora da janela

Nesse caso, a análise pode se ramificar.

Para cada ramo, perguntamos novos porquês.

A Why-Why pode então trabalhar em conjunto com:

• Diagrama de Ishikawa;

• Árvore de Falhas;

• Pareto;

• FMEA;

• análise de barreiras;

• análise cronológica;

• Kepner-Tregoe;

• DMAIC;

• investigação de incidentes.

O método é excelente, mas não deve ser usado como martelo universal.

Quando o problema envolve múltiplas causas independentes, uma linha única de cinco perguntas pode simplificar demais a realidade.

---

12. Integração com Ishikawa

O Diagrama de Ishikawa, conhecido como espinha de peixe, ajuda a levantar categorias de possíveis causas.

Categorias comuns incluem:

• método;

• máquina;

• mão de obra;

• material;

• medição;

• meio ambiente.

Em tecnologia, podemos adaptar:

• aplicação;

• infraestrutura;

• dados;

• processo;

• pessoas;

• segurança;

• dependências;

• monitoramento.

O Ishikawa ajuda a encontrar áreas de investigação.

Os Cinco Porquês ajudam a aprofundar cada área.

Exemplo:

Categoria: Dados
Problema: S0C7
Por quê? Campo inválido.
Por quê? Layout incompatível.
Por quê? Copybook desatualizado.
Por quê? Mudança não comunicada.
Por quê? Ausência de governança.

As duas ferramentas se complementam muito bem.

---

13. Relação com PDCA

A análise dos porquês se encaixa perfeitamente no ciclo PDCA.

Plan

Definir o problema, coletar evidências e encontrar a causa raiz.

Do

Implementar a contramedida.

Check

Verificar se o resultado melhorou e se o problema deixou de ocorrer.

Act

Padronizar a solução ou revisar a hipótese caso o problema continue.

A etapa “Check” é frequentemente esquecida.

Uma equipe implementa a mudança e considera o assunto encerrado.

Mas sem medir o resultado, não sabemos se a causa estava correta.

---

14. Relação com DMAIC e Six Sigma

Dentro do Six Sigma, o método pode ser utilizado principalmente na fase Analyze do DMAIC.

Define

Qual é o problema?

Measure

Qual é sua frequência, impacto e comportamento?

Analyze

Quais causas explicam o problema?

Improve

Quais mudanças eliminam ou reduzem as causas?

Control

Como garantir que a melhoria seja sustentada?

A Why-Why Analysis ajuda a estruturar hipóteses, mas em problemas complexos deve ser apoiada por dados estatísticos e testes.

Perguntar por quê não substitui medir.

---

15. Dicas práticas para uma boa análise

Não aceite respostas vagas

Evite:

• falta de atenção;

• problema no sistema;

• erro de comunicação;

• falha operacional;

• problema de performance.

Pergunte:

• qual sistema?

• qual falha?

• que comunicação?

• em qual etapa?

• qual métrica?

• qual evidência?

---

Não transforme opinião em fato

“Acho que foi a rede” não é conclusão.

É hipótese.

Precisamos de:

• tempos de resposta;

• logs;

• traces;

• pacotes perdidos;

• métricas;

• comparação histórica.

---

Não pule etapas

É tentador sair de:

“O job falhou”

diretamente para:

“Precisamos trocar a ferramenta.”

Essa conclusão pode não ter nenhuma ligação comprovada com o evento.

A cadeia precisa ser construída passo a passo.

---

Não confunda correlação com causalidade

Dois eventos acontecerem juntos não significa que um causou o outro.

Exemplo:

O job ficou lento depois da instalação de uma nova versão.

A versão pode ser a causa.

Mas também pode ter ocorrido:

• aumento de volume;

• mudança de índice;

• alteração de prioridade WLM;

• concorrência;

• problema de I/O;

• mudança no scheduler.

Investigue.

---

Faça a análise em equipe

Inclua pessoas que conhecem diferentes partes do fluxo:

• programador;

• operador;

• DBA;

• analista de produção;

• sysprog;

• segurança;

• infraestrutura;

• negócio;

• suporte.

Sistemas corporativos são cadeias complexas. Raramente uma única pessoa enxerga tudo.

---

Registre as evidências

Uma boa análise deve indicar:

• pergunta;

• resposta;

• evidência;

• responsável pela validação;

• ação proposta.

Isso evita que a conclusão seja apenas uma opinião coletiva.

---

16. Um modelo simples para usar

PROBLEMA:
Descreva o evento com data, hora, sistema, impacto e comportamento esperado.

POR QUÊ 1:
Pergunta:
Resposta:
Evidência:

POR QUÊ 2:
Pergunta:
Resposta:
Evidência:

POR QUÊ 3:
Pergunta:
Resposta:
Evidência:

POR QUÊ 4:
Pergunta:
Resposta:
Evidência:

POR QUÊ 5:
Pergunta:
Resposta:
Evidência:

CAUSA RAIZ:
Condição sistêmica comprovada que permitiu o problema.

CORREÇÃO IMEDIATA:
Ação para restaurar o serviço.

CONTRAMEDIDA:
Ação para evitar recorrência.

RESPONSÁVEL:
Nome ou equipe.

PRAZO:
Data prevista.

VALIDAÇÃO:
Métrica que demonstrará a eficácia.

Esse modelo pode ser usado em uma planilha, wiki, ferramenta ITSM, documento de incidente ou post-mortem.

---

17. Curiosidades da sala de máquinas

A primeira curiosidade é que os Cinco Porquês não precisam produzir uma única resposta correta e absoluta. Em investigações reais, diferentes equipes podem construir cadeias diferentes. O importante é validar cada elo com evidências.

A segunda é que uma causa raiz pode estar fora do componente que apresentou o erro. Um programa COBOL pode falhar por uma alteração feita em uma aplicação distribuída, em um arquivo, em uma regra de negócio ou em um processo manual.

A terceira é que problemas recorrentes são frequentemente sinais de que a organização está tratando sintomas. Quando o mesmo incidente aparece repetidamente com pequenas variações, vale procurar uma causa sistêmica comum.

A quarta é que uma boa análise costuma revelar oportunidades maiores do que o incidente original. Ao investigar um arquivo inválido, podemos descobrir falhas de governança, testes, comunicação e automação.

A quinta é que a pergunta “por quê?” deve ser feita com curiosidade, não com acusação. O tom muda tudo.

Compare:

“Por que você fez isso?”

com:

“Que condições do processo levaram a esse resultado?”

A segunda pergunta abre portas.

A primeira ergue escudos.

---

18. Easter egg: o incidente da USS Enterprise-Z

Imagine uma nave híbrida: metade USS Enterprise, metade IBM Z.

No centro da sala de máquinas existe um z17 processando transações interplanetárias em COBOL.

De repente, o alerta vermelho é acionado.

IEF450I STARJOB STEP010 - ABEND=S0C7

O Capitão Kirk pergunta:

— Sr. Spock, por que o sistema de navegação financeira caiu?

Spock responde:

— Porque uma rotina aritmética processou um campo não numérico.

Kirk respira aliviado:

— Então corrija o campo.

Spock ergue uma sobrancelha:

— Isso restauraria o processamento, Capitão, mas não explicaria a origem do dado inválido.

O primeiro porquê revela o campo.

O segundo revela o arquivo.

O terceiro revela o copybook.

O quarto revela uma mudança não comunicada.

O quinto revela que a Federação não possui governança para contratos de dados entre planetas.

Scotty entra correndo:

— Capitão, posso fazer o job rodar em vinte minutos!

Spock responde:

— E ele falhará novamente na próxima remessa de carga de Vulcano.

A solução definitiva inclui:

• versionamento de copybooks;

• validação automática;

• testes de contrato;

• comunicação entre sistemas;

• monitoramento;

• rollback.

Kirk então compreende:

Reiniciar a nave é manutenção.
Eliminar a causa da falha é engenharia.

No canto da tela, escondido entre os registros do spool, aparece o easter egg:

       01  LOGICA-VULCANA       PIC X(20)
           VALUE 'VIDA-LONGA-E-SEM-S0C7'.

---

19. Quando não usar apenas os Cinco Porquês

A técnica pode ser insuficiente quando:

• existem diversas causas simultâneas;

• o problema é altamente probabilístico;

• há forte interação entre componentes;

• a falha envolve segurança crítica;

• os dados são contraditórios;

• o evento nunca havia ocorrido;

• a cadeia causal é extensa;

• há fatores humanos, tecnológicos e organizacionais combinados.

Nessas situações, combine o método com ferramentas mais robustas.

Em incidentes graves, use também:

• linha do tempo;

• análise de mudanças;

• Fault Tree Analysis;

• análise de barreiras;

• FMEA;

• dados de observabilidade;

• testes controlados;

• revisão independente;

• post-mortem sem culpa.

O objetivo não é preencher cinco caixas.

O objetivo é aprender a verdade operacional do sistema.

---

20. Conclusão: não pare no primeiro “por quê”

O programador iniciante olha para o ABEND.

O programador experiente olha para os dados.

O analista sênior olha para o fluxo.

O arquiteto olha para o sistema.

O verdadeiro resolvedor de problemas olha para as condições que permitiram a falha.

A Why-Why Analysis ensina exatamente essa evolução.

Ela nos convida a sair do modo reativo:

Falhou → corrigir → reiniciar → esquecer.

E migrar para um modo de melhoria contínua:

Falhou
  ↓
observar
  ↓
investigar
  ↓
comprovar
  ↓
corrigir
  ↓
prevenir
  ↓
monitorar
  ↓
aprender

No ambiente mainframe, onde milhões de transações dependem de processos maduros, confiáveis e repetíveis, essa mentalidade é especialmente valiosa.

Não basta fazer o job voltar.

É preciso compreender por que ele parou.

Não basta corrigir o registro.

É preciso descobrir por que o registro chegou inválido.

Não basta culpar o operador.

É preciso entender por que o processo permitiu o engano.

Não basta apagar o incêndio.

É preciso descobrir quem deixou combustível perto do reator de dobra.

A pergunta “por quê?” parece pequena, mas abre portas gigantescas.

Cada porquê remove uma camada de aparência.

Cada resposta bem comprovada aproxima a equipe da verdade.

Cada causa raiz eliminada torna o sistema mais robusto.

Portanto, na próxima vez que um programa COBOL terminar com ABEND, não se limite à primeira mensagem do spool.

Abra o dump.

Consulte o SYSOUT.

Converse com as equipes.

Verifique os fatos.

Siga a cadeia lógica.

Pergunte novamente.

E novamente.

Até que o sintoma deixe de ser o centro da investigação e o processo revele aquilo que realmente precisa ser transformado.

Como diria o oficial científico da Bellacosa Enterprise:

“Uma correção que não elimina a recorrência é apenas um adiamento logicamente organizado do próximo incidente.”

Vida longa ao COBOL, ao IBM Z e aos programadores que nunca se contentam com o primeiro porquê.