Reconhecimento pelos 5 anos no DIO Global - Digital Innovation One

 

Bellacosa Mainframe DIO Global 5 anos

O DIO Global faz 5 anos esse mês. E quando a gente olhar para essa data de verdade, o que aparece não é um número. São rostos. 

São mais de 50.000 profissionais que foram contratados em empresas de tecnologia através da DIO. Pessoas que estavam em transição de carreira, que buscavam a primeira vaga, que precisavam do inglês certo para competir com qualquer profissional do mundo. Que tinham talento, mas precisavam de um caminho. 

Você ajudou a construir esse caminho. 

O conteúdo que você produziu chegou a profissionais que mudaram de vida por conta do que aprenderam. Isso é raro. A maioria das pessoas passa anos trabalhando sem saber ao certo o impacto do que faz. Você sabe. 

Cinco anos é tempo suficiente para olhar para trás e ter clareza sobre quem construiu isso junto. E o seu nome está nessa lista. 

Em anexo você encontra um reconhecimento de gratidão da DIO pelo que você fez pela educação e pela carreira de tanta gente que confiou nesse projeto.  

 

Nosso agradecimento e reconhecimento por você ter impactado milhares de pessoas por meio da educação e empregabilidade. 

 

Obrigada pela sua contribuição.

DIO
Learning & Curriculum Lead

---------------------------------------------------------------------------------------------------------------------------------

Gratidão

Alcançar cinco anos de participação na DIO (Digital Innovation One) representa muito mais do que uma marca temporal. É o reconhecimento de uma trajetória construída por meio de aprendizado contínuo, troca de experiências e desenvolvimento profissional dentro de uma das maiores comunidades de tecnologia do Brasil.

Ao longo desse período, milhares de profissionais utilizaram a plataforma para expandir conhecimentos em áreas como programação, computação em nuvem, inteligência artificial, ciência de dados, segurança da informação, DevOps, arquitetura de sistemas e diversas outras especialidades do mercado tecnológico. A DIO tornou-se uma ponte entre conhecimento e oportunidades, aproximando estudantes, profissionais e empresas.

Receber um reconhecimento pelos cinco anos de jornada simboliza dedicação, persistência e compromisso com a evolução constante. Em um setor que se transforma diariamente, manter-se atualizado é um diferencial fundamental para enfrentar novos desafios e acompanhar as mudanças do mercado.

Além dos cursos e certificações, a experiência envolve participação em comunidades, eventos, bootcamps e iniciativas colaborativas que fortalecem o networking e o compartilhamento de conhecimento.

Esse marco também representa uma oportunidade para olhar para trás e perceber o quanto foi conquistado ao longo dos anos. Mais do que um certificado ou homenagem, os cinco anos na DIO refletem uma trajetória de crescimento, aprendizado contínuo e paixão pela tecnologia, valores essenciais para quem constrói uma carreira sólida na área de TI.

 

Bellacosa Mainframe e o monstro da divida tecnica 

☕💣 DÍVIDA TÉCNICA: O MONSTRO INVISÍVEL QUE ESTÁ COMENDO O SEU COBOL DESDE O SÉCULO PASSADO

"O sistema funciona perfeitamente. Só ninguém sabe como."

Se você trabalha com Mainframe há algum tempo, provavelmente já ouviu frases como:

• "Não mexe nisso que funciona."

• "Esse programa está em produção há 20 anos."

• "Só o João sabe alterar esse módulo."

• "Depois a gente documenta."

• "Precisamos entregar hoje."

Parabéns.

Você acabou de encontrar alguns dos maiores sintomas de uma das doenças mais comuns da tecnologia moderna:

A Dívida Técnica.

E não, ela não acontece apenas em Java, Python ou aplicações web modernas.

Na verdade, muitos dos maiores casos de dívida técnica do planeta estão rodando neste exato momento em sistemas COBOL responsáveis por bancos, seguradoras, governos, companhias aéreas e bolsas de valores.

Vamos entender o que é, como identificar, controlar e principalmente como sobreviver a ela.

---

O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida Técnica é o custo futuro gerado quando escolhemos uma solução rápida hoje em vez da melhor solução possível.

Imagine que você recebeu uma demanda urgente.

O gerente aparece correndo:

"Precisamos colocar essa alteração em produção amanhã."

Você sabe que o correto seria:

• revisar a arquitetura;

• atualizar documentação;

• criar casos de teste;

• revisar impactos;

• atualizar fluxogramas.

Mas o prazo não permite.

Então você faz um ajuste rápido.

Entrega.

Todo mundo feliz.

Até que seis meses depois alguém precisa alterar novamente aquele trecho.

Agora ninguém entende mais nada.

A dívida venceu.

E os juros começaram a ser cobrados.

---

A ANALOGIA COM O CARTÃO DE CRÉDITO

A comparação mais famosa é com uma dívida financeira.

Quando você compra algo parcelado:

Você ganha agora.

Mas paga depois.

Na dívida técnica acontece exatamente o mesmo.

Você ganha:

• velocidade;

• prazo;

• entrega rápida.

Mas paga depois com:

• bugs;

• retrabalho;

• manutenção cara;

• incidentes de produção.

Quanto mais tempo passa, maiores ficam os juros.

---

O COBOL NÃO CRIA DÍVIDA TÉCNICA

Essa é uma das maiores injustiças da informática.

Muitos dizem:

"Cobol é dívida técnica."

Errado.

COBOL não é dívida técnica.

COBOL mal mantido é dívida técnica.

Existem programas COBOL escritos há 30 anos que continuam:

• legíveis;

• documentados;

• organizados;

• eficientes.

E existem aplicações modernas escritas há seis meses que já parecem um filme de terror.

A linguagem não é o problema.

A disciplina é.

---

COMO A DÍVIDA TÉCNICA NASCE

Ela normalmente surge de quatro formas.

1. Pressão por prazo

O caso mais comum.

"Entrega primeiro."

"Arruma depois."

O problema é que o depois quase nunca chega.

---

2. Falta de documentação

O desenvolvedor conhece tudo.

Então ele pensa:

"Não preciso documentar."

Dois anos depois ele muda de empresa.

Agora ninguém entende o programa.

---

3. Correções emergenciais

Produção caiu.

Cliente está ligando.

Diretoria está nervosa.

O objetivo vira apenas:

"Faça voltar."

Nesse momento quase ninguém pensa em qualidade.

---

4. Sistemas legados

Bibliotecas antigas.

COPYBOOKs herdados.

Macros esquecidas.

JCLs copiados durante décadas.

Tudo isso acumula dívida.

---

EXEMPLO REAL DE DÍVIDA TÉCNICA EM COBOL

Imagine um cálculo de desconto.

Versão original:

IF CLIENTE-VIP
   COMPUTE DESCONTO = VALOR * 0.15
END-IF

Simples.

Legível.

Agora passam dez anos.

Novas regras surgem.

Resultado:

IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...

Mais tarde:

IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...
ELSE
IF REGIAO = 'S'
...

Depois de centenas de mudanças:

Ninguém sabe mais como o cálculo funciona.

O programa funciona.

Mas ninguém entende.

Isso é dívida técnica.

---

OS SINTOMAS MAIS PERIGOSOS

Se você encontrar estes sinais, ligue o alerta.

Programas gigantes

Mais de 10.000 linhas.

COPYBOOKs duplicados

A mesma estrutura em vários lugares.

JCLs clonados

Mudam apenas o nome do JOB.

Falta de comentários

Tudo depende da memória dos analistas.

Testes manuais

Ninguém consegue validar rapidamente.

Dependência de uma pessoa

"O Carlos sabe."

Quando você ouve isso, existe dívida técnica.

---

O EFEITO JUROS COMPOSTOS

Aqui está a parte assustadora.

Dívida técnica cresce de forma parecida com juros compostos.

Um bug gera:

• remendo;

• novo remendo;

• ajuste do remendo;

• correção da correção.

Depois de alguns anos ninguém consegue alterar sem medo.

O custo explode.

---

COMO MAPEAR DÍVIDA TÉCNICA

Primeiro passo:

Pare de adivinhar.

Crie um inventário.

Faça uma planilha simples.

Colunas:

• Sistema

• Programa

• Problema

• Impacto

• Complexidade

• Prioridade

Exemplo:

Programa	Problema	Impacto
COBCLI01	Sem documentação	Alto
COBFAT02	12.000 linhas	Alto
COBPAG03	Sem testes	Médio

Agora a dívida virou algo visível.

---

MÉTRICAS IMPORTANTES

Um programador júnior deve aprender a medir.

Algumas métricas úteis:

Número de ABENDs

Se cresce continuamente:

há algo errado.

---

Tempo de correção

Quanto tempo leva para corrigir um incidente?

Quanto maior, maior a dívida.

---

Quantidade de módulos sem documentação

Métrica simples e poderosa.

---

Cobertura de testes

Quanto mais baixa, maior o risco.

---

FERRAMENTAS ÚTEIS NO MAINFRAME

Muitos iniciantes acham que Mainframe não possui ferramentas modernas.

Possui.

E muitas.

IBM Application Discovery

Mapeia dependências.

Excelente para sistemas gigantes.

---

IBM ADDI

Application Discovery and Delivery Intelligence.

Mostra relacionamentos entre:

• COBOL

• JCL

• DB2

• CICS

---

IBM Debug Tool

Ajuda a entender comportamento de programas complexos.

---

IBM Fault Analyzer

Investiga ABENDs.

---

IBM File Manager

Analisa arquivos rapidamente.

---

IBM Dependency Based Build

Automação moderna para pipelines Mainframe.

---

COMO REDUZIR A DÍVIDA

Agora vem a parte prática.

---

Passo 1 – Pare de criar dívida nova

Antes de pagar a antiga.

Evite criar mais.

Parece óbvio.

Mas é onde tudo começa.

---

Passo 2 – Refatore pequenos trechos

Não tente reescrever tudo.

Ataque pequenas áreas.

Exemplo:

• nomes ruins;

• IFs excessivos;

• parágrafos gigantes.

---

Passo 3 – Documente enquanto aprende

Cada descoberta vira documentação.

Não espere um projeto oficial.

---

Passo 4 – Automatize testes

Mesmo testes simples ajudam.

Menos medo de alterar.

Mais velocidade.

---

Passo 5 – Padronize

Defina padrões.

Por exemplo:

• nomenclatura;

• comentários;

• estrutura de programas;

• organização de COPYBOOKs.

---

O ERRO MAIS COMUM DOS JUNIORES

Achar que refatorar significa reescrever tudo.

Não.

Refatoração significa melhorar sem alterar comportamento.

Você limpa.

Organiza.

Simplifica.

Sem mudar resultado.

---

O SEGREDO DOS ANALISTAS SENIORES

Muitos iniciantes acreditam que profissionais experientes sabem tudo.

Não sabem.

A diferença é que eles:

• documentam mais;

• investigam melhor;

• evitam atalhos perigosos;

• controlam a dívida técnica.

O conhecimento não está apenas no código.

Está na disciplina.

---

EASTER EGG DOS MAINFRAMEIROS

Se encontrar um comentário parecido com:

* NÃO REMOVER
* FUNCIONA ASSIM DESDE 1994

Você provavelmente encontrou um artefato arqueológico corporativo.

Trate com respeito.

Mas investigue.

Porque muitas vezes ele esconde uma dívida técnica histórica.

---

A REGRA DOS 5 MINUTOS

Uma dica poderosa.

Se você gastou cinco minutos para entender algo complicado:

documente.

O próximo desenvolvedor agradecerá.

E talvez esse próximo desenvolvedor seja você daqui a seis meses.

---

COMO EVOLUIR NA CARREIRA ATRAVÉS DA DÍVIDA TÉCNICA

Os melhores profissionais não são os que criam mais código.

São os que reduzem complexidade.

Quando você aprende a:

• mapear problemas;

• documentar;

• simplificar;

• automatizar;

• refatorar;

você deixa de ser apenas um programador.

Você passa a ser um engenheiro de software.

---

CONCLUSÃO

Dívida técnica não é um bug.

Não é um ABEND.

Não é um programa COBOL antigo.

Ela é o resultado de decisões acumuladas ao longo do tempo.

Algumas são necessárias.

Outras são perigosas.

O segredo não é eliminar toda dívida técnica.

Isso é impossível.

O segredo é conhecê-la, monitorá-la e pagá-la antes que ela assuma o controle do sistema.

Porque, no final das contas, o verdadeiro problema não é aquele programa COBOL de 1987.

O problema é ninguém mais entender por que ele ainda funciona.

E quando esse dia chega...

o próximo chamado de produção costuma acontecer às 03:17 da manhã de um domingo.

Aproveite e conheça BACKLOG

https://eljefemidnightlunch.blogspot.com/2025/01/backlog-o-arquivo-secreto-que-separa-um.html

Backlog

☕ MAINFRAME INSIGHTS

📋💣 BACKLOG: O Arquivo Secreto Que Separa um Programador COBOL Comum de um Verdadeiro Arquiteto de Sistemas

Descubra por que o backlog é muito mais do que uma lista de tarefas e como ele se tornou a arma estratégica dos profissionais que dominam sistemas críticos.

Ler Artigo Completo →

 

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 o laboratorio pratico de IBM System Automation

☕🔥 LABORATÓRIO DEFINITIVO — IBM Z SYSTEM AUTOMATION, ZOWE CLI E DEVOPS PARA SYSprog PADAWAN

20 Exercícios Práticos no Estilo Bellacosa Mainframe

Existe um momento na vida do sysprog padawan em que ele para de apenas observar o console verde…
e começa a automatizar o universo.

Este laboratório foi criado para:

• iniciantes

• operadores

• sysprogs juniors

• estudantes IBM Z

• aventureiros do Zowe

• guerreiros do NetView

Aqui você aprenderá:
✅ SA REST Server
✅ Swagger UI
✅ Zowe CLI
✅ Dynamic Resources
✅ APIs REST
✅ Curl
✅ Ansible
✅ Integração DevOps

Tudo em exercícios práticos.

Prepare o café.
Ajuste o SDSF.
E vamos entrar no hyperspace do IBM Z moderno.

---

☕ LAB 1 — ENTENDENDO O ECOSSISTEMA

Objetivo

Identificar os componentes da arquitetura moderna do SA.

---

Exercício

Explique o papel dos seguintes componentes:

• System Automation

• REST Server

• Zowe CLI

• Ansible Collection

---

Solução

Componente	Função
SA z/OS	motor de automação
REST Server	gateway API
Zowe CLI	interface shell moderna
Ansible	automação declarativa

---

☕ LAB 2 — ACESSANDO O SWAGGER UI

Objetivo

Explorar a documentação REST.

---

Exercício

Abra no navegador:

http://server:port/ibm/sa/swagger-ui/index.html

Liste:

• endpoints

• métodos HTTP

• exemplos JSON

---

Solução

Você verá:

• GET

• POST

• DELETE

• responses

• parameters

• CURL examples

---

☕ LAB 3 — IDENTIFICANDO HTTP VERBS

Objetivo

Entender operações REST.

---

Exercício

Associe:

Verbo	Função
GET	?
POST	?
DELETE	?

---

Solução

Verbo	Função
GET	consulta
POST	criação/request
DELETE	remoção

---

☕ LAB 4 — TESTANDO API VIA SWAGGER

Objetivo

Executar chamada REST real.

---

Exercício

Execute:

GET /resources

---

Solução esperada

{
 "resource":"CICSA",
 "status":"UP"
}

---

☕ LAB 5 — TESTANDO CURL

Objetivo

Executar API sem browser.

---

Exercício

Monte um CURL para listar resources.

---

Solução

curl -X GET https://server/resources

---

☕ LAB 6 — INSTALANDO ZOWE CLI

Objetivo

Preparar ambiente moderno.

---

Exercício

Liste os pré-requisitos do Zowe.

---

Solução

✅ Node.js
✅ npm
✅ gnome-keyring (Linux)

Instalação:

npm install -g @zowe/cli

---

☕ LAB 7 — LISTANDO PLUGINS

Objetivo

Conhecer extensões do Zowe.

---

Exercício

Qual comando lista plugins instalados?

---

Solução

zowe plugins list

---

☕ LAB 8 — INSTALANDO O PLUGIN SA

Objetivo

Integrar SA ao Zowe.

---

Exercício

Instale o plugin System Automation.

---

Solução

zowe plugins install @ibm/system-automation-for-zowe-cli

---

☕ LAB 9 — EXPLORANDO HELP

Objetivo

Aprender ajuda integrada.

---

Exercício

Obtenha ajuda do plugin SA.

---

Solução

zowe sa --help

---

☕ LAB 10 — GERANDO HELP HTML

Objetivo

Visualizar documentação web.

---

Exercício

Gere ajuda HTML.

---

Solução

zowe sa --help-web

---

☕ LAB 11 — LISTANDO RESOURCES

Objetivo

Consultar runtime SA.

---

Exercício

Liste todos os resources automatizados.

---

Solução

zowe sa list resources

---

☕ LAB 12 — LISTANDO TEMPLATES

Objetivo

Conhecer templates dinâmicos.

---

Exercício

Liste templates disponíveis.

---

Solução

zowe sa list templates

---

☕ LAB 13 — CRIANDO DYNAMIC RESOURCE

Objetivo

Entender provisioning dinâmico.

---

Exercício

Explique o conceito de dynamic resource.

---

Solução

Resource criado:

• em runtime

• sem rebuild total

• sem restart global

Conceito semelhante a:

• containers

• pods

• runtime provisioning

---

☕ LAB 14 — DELETANDO RESOURCE

Objetivo

Operar lifecycle.

---

Exercício

Delete resource GFBJOST.

---

Solução

zowe sa del res --name GFBJOST

---

☕ LAB 15 — ANALISANDO O REST SERVER

Objetivo

Entender arquitetura.

---

Exercício

Explique a diferença entre:

• OPT_EMBEDDED_WEBSERVER

• OPT_LIBERTY_DEPLOYED

---

Solução

Modo	Característica
Embedded	Tomcat embutido
Liberty	deploy WebSphere Liberty

---

☕ LAB 16 — CONFIG FILES ZOWE

Objetivo

Entender profiles.

---

Exercício

Explique:

• base profile

• sa profile

---

Solução

Profile	Uso
base	propriedades genéricas
sa	propriedades específicas SA

---

☕ LAB 17 — ENTENDENDO ANSIBLE

Objetivo

Introdução DevOps.

---

Exercício

Explique o que é automação declarativa.

---

Solução

Você descreve:

o estado desejado.

O Ansible executa:

automaticamente.

---

☕ LAB 18 — PLAYBOOK BÁSICO

Objetivo

Criar resource via YAML.

---

Exercício

Crie playbook simples.

---

Solução

- hosts: zos
  roles:
    - sa_create_dynamic_resource

---

☕ LAB 19 — PIPELINE DEVOPS

Objetivo

Entender integração moderna.

---

Exercício

Explique fluxo:

Git
 ↓
Pipeline
 ↓
Ansible
 ↓
REST API
 ↓
SA

---

Solução

Esse fluxo:

• automatiza deploy

• cria resources

• inicia aplicações

• integra mainframe ao DevOps

---

☕ LAB 20 — O SYSprog DO FUTURO

Objetivo

Reflexão final.

---

Exercício

Explique por que:

o mainframe moderno não vive apenas de ISPF e SDSF.

---

Solução

Porque o IBM Z moderno agora usa:

• APIs REST

• JSON

• YAML

• Zowe

• Ansible

• AIOps

• observabilidade

• pipelines DevOps

O sysprog moderno precisa dominar:

• operação clássica

• automação moderna

• integração híbrida

---

☕ DESAFIO FINAL DO PADAWAN

Monte um cenário onde:

• um Git Push

• dispara um pipeline

• executa Ansible

• cria dynamic resource

• inicia aplicação automaticamente no IBM Z.

Se você conseguir explicar esse fluxo…
você deixou de ser apenas operador.

E começou sua transformação em:

IBM Z Platform Engineer.

---

☕ FRASE FINAL DO LABORATÓRIO

“O futuro do mainframe não é abandonar o legado.
É conectar o legado ao universo das APIs, automação e DevOps.”

— Bellacosa Mainframe

 

Bellacosa Mainframe e o IBM Z System Automation

☕🔥 “DO 3270 AO DEVOPS” — O GUIA DEFINITIVO DO SYSprog PADAWAN PARA IBM Z SYSTEM AUTOMATION, ZOWE E APIs MODERNAS

Existe um momento na vida de todo sysprog padawan em que ele percebe uma verdade assustadora:

“O mainframe moderno não vive mais apenas de ISPF, SDSF e comandos verdes.”

E nesse instante começa a jornada.

Uma jornada que leva o operador clássico do:

• INGLIST

• INGAMS

• TSO

• NetView

• Automation Table

para um novo universo:

• REST APIs

• Swagger

• Zowe CLI

• Ansible

• YAML

• DevOps

• GitOps

• AIOps

Sim…
o IBM Z mudou.

E se você ainda imagina que automação no mainframe significa apenas:

START CICS
STOP DB2

então prepare seu café porque hoje vamos entrar no:

IBM Z System Automation MODERNO.

---

☕ O QUE É IBM Z SYSTEM AUTOMATION?

O IBM Z System Automation (SA z/OS):

é o cérebro operacional do mainframe.

Ele é responsável por:

• iniciar subsistemas

• parar aplicações

• monitorar ambientes

• tratar falhas

• executar recovery automático

• coordenar dependências

Pense nele como:

o “Kubernetes” do mundo enterprise tradicional.

---

🔥 EXEMPLO PRÁTICO

Imagine:

Você possui:

• DB2

• CICS

• MQ

• Batch

• WebSphere

Tudo depende um do outro.

O SA sabe:

• o que iniciar primeiro

• o que depende do quê

• como reagir a falhas

• como automatizar recovery

---

☕ O MUNDO ANTIGO DO SYSprog

Durante décadas:

o mainframe foi operado principalmente via 3270.

Comandos clássicos:

INGLIST
INGAMS
INGREQ
INGSET

Painéis verdes.
PF Keys.
Automation Tables.
Policy Database.

Funcionava maravilhosamente.

E ainda funciona.

Mas o mundo mudou.

---

🔥 O PROBLEMA

Enquanto Linux e Cloud evoluíam para:

• APIs

• pipelines

• automação declarativa

• integração CI/CD

o mainframe parecia isolado.

Até que a IBM começou uma revolução silenciosa.

---

☕ NASCE O SYSTEM AUTOMATION OPERATIONS REST SERVER

Esse componente:

mudou tudo.

O SA ganhou:

APIs REST modernas.

Agora qualquer software consegue conversar com o mainframe usando:

• HTTP

• JSON

• REST

• CURL

---

🧠 O QUE ISSO SIGNIFICA?

Antes:

Operador
   ↓
3270
   ↓
NetView

Agora:

Pipeline DevOps
      ↓
REST API
      ↓
IBM Z System Automation

---

☕ O QUE O REST SERVER CONSEGUE FAZER?

Ele permite:

✅ listar resources
✅ iniciar aplicações
✅ parar subsistemas
✅ criar dynamic resources
✅ deletar resources
✅ refresh policy
✅ consultar requests
✅ interagir com automation managers

---

🔥 MAS EXISTE UMA LIMITAÇÃO IMPORTANTE

O REST API:

NÃO edita a policy.

Ele opera:

o runtime.

Ou seja:

• você controla recursos

• mas não altera definições da policy

Isso é importante para:

• segurança

• governança

• integridade operacional

---

☕ SWAGGER UI — O LABORATÓRIO SECRETO DO SYSprog

Depois que o REST Server está ativo:

nasce o Swagger UI.

URL típica:

http://server:port/ibm/sa/swagger-ui/index.html

---

🔥 O QUE É ISSO?

Uma interface web interativa que mostra:

• endpoints

• parâmetros

• JSON

• responses

• códigos HTTP

E MAIS:

você pode testar chamadas ao vivo.

---

☕ EXEMPLO REAL

Consultar resources:

GET /resources

Resposta:

{
 "resource":"CICSA",
 "status":"UP"
}

---

🔥 AGORA O SYSprog COMEÇA A VIRAR DEVOPS ENGINEER

Porque:

APIs permitem integração total.

---

☕ CURL — O PODER BRUTO

O Swagger ainda mostra comandos CURL.

Exemplo:

curl -X GET https://server/resources

Agora imagine:

• scripts

• automação

• pipelines

• monitoramento externo

Tudo falando com SA.

---

☕ E ENTÃO SURGE O ZOWE CLI

O Zowe foi outra revolução gigantesca.

Ele trouxe:

shell moderno para o mainframe.

---

🔥 ANTES

3270

---

🔥 AGORA

zowe sa list resources

---

🧠 O ZOWE É COMO UM “LINUX TERMINAL” PARA z/OS

E isso reduz brutalmente:

a barreira de entrada no mainframe.

---

☕ POR QUE ISSO É IMPORTANTE?

Hoje muitos profissionais:

• conhecem Linux

• usam Git

• usam shell

• usam pipelines

Mas:

• não conhecem ISPF

• não conhecem PF Keys

• não conhecem 3270

O Zowe resolve isso.

---

☕ COMO O ZOWE FUNCIONA?

Arquitetura:

Zowe CLI
    ↓
SA Plug-in
    ↓
REST Server
    ↓
IBM Z System Automation

---

🔥 O ZOWE NÃO SUBSTITUI O NETVIEW

Ele é:

uma interface adicional.

---

☕ INSTALANDO O ZOWE

Pré-requisitos:

✅ Node.js
✅ npm
✅ gnome-keyring (Linux)

Instalação:

npm install -g @zowe/cli

---

☕ INSTALANDO O PLUGIN SA

zowe plugins install

---

☕ COMANDOS IMPORTANTES

Listar resources:

zowe sa list resources

Deletar dynamic resource:

zowe sa del res --name TESTE1

Ajuda:

zowe sa --help

Ajuda HTML:

zowe sa --help-web

---

☕ DYNAMIC RESOURCES — O CONCEITO MAIS IMPORTANTE

Isso aqui muda completamente a automação do mainframe.

---

🔥 O QUE É UM DYNAMIC RESOURCE?

Um recurso criado:

em runtime.

Sem:

• rebuild

• refresh completo

• restart global

---

🧠 ISSO É MUITO “CLOUD-LIKE”

---

☕ ANALOGIA MODERNA

Cloud	SA
Pod	Dynamic Resource
kubectl	Zowe
YAML	Playbook
Deployment	Template

---

☕ ENTRA O ANSIBLE

Agora chegamos ao nível Jedi.

---

🔥 O QUE É O ANSIBLE?

Ferramenta de automação declarativa baseada em:

YAML.

---

🧠 “DECLARATIVA” SIGNIFICA:

Você descreve:

o estado desejado.

E o Ansible executa.

---

☕ IBM Z SYSTEM AUTOMATION ANSIBLE COLLECTION

A IBM criou uma collection específica para SA.

Ela oferece duas roles:

sa_create_dynamic_resource
sa_delete_dynamic_resource

---

☕ EXEMPLO DE PLAYBOOK

- hosts: zos
  roles:
    - sa_create_dynamic_resource

---

🔥 O QUE ACONTECE?

Playbook
   ↓
REST API
   ↓
SA REST Server
   ↓
INGDYN CREATE

---

☕ ISSO É REVOLUCIONÁRIO

Porque agora:

o mainframe entra no pipeline DevOps.

---

☕ CENÁRIO REAL

Imagine:

Developer faz:

git push

Pipeline executa:

Ansible
 ↓
Deploy
 ↓
Create dynamic resource
 ↓
Start application

Tudo automático.

---

☕ O SYSprog DO FUTURO

O profissional moderno não será apenas:

operador de console.

Ele será:

• automation engineer

• platform engineer

• DevOps specialist

• API integrator

---

☕ AIOPS — O PRÓXIMO PASSO

A IBM está indo além.

Agora fala-se em:

AIOps.

Artificial Intelligence for IT Operations.

---

🔥 O OBJETIVO

Usar:

• analytics

• machine learning

• observability

• automation

para criar:

sistemas autônomos.

---

☕ O SA FAZ PARTE DISSO

Hoje o SA integra:

• observabilidade

• automation

• REST APIs

• eventos

• workflows

---

☕ O SYSprog PADAWAN PRECISA ENTENDER UMA VERDADE

O mainframe:

não está parado no tempo.

Na verdade:

ele está se tornando uma plataforma híbrida programável.

---

☕ O QUE VOCÊ DEVE ESTUDAR AGORA?

Depois desse curso:

• REST APIs

• JSON

• YAML

• Python

• Zowe

• Ansible

• Git

• OpenShift

• z/OSMF

• SMU

---

☕ DICA DE OURO DO LOBO VELHO

Aprenda:

os dois mundos.

Porque o profissional mais poderoso será aquele que souber:

✅ INGLIST
✅ NetView
✅ Policy
✅ Automation Tables

MAS TAMBÉM:

✅ APIs
✅ Zowe
✅ YAML
✅ Ansible
✅ DevOps

---

☕ CONCLUSÃO

O IBM Z moderno está atravessando a maior transformação operacional desde o surgimento do Sysplex.

O que antes era:

• centralizado

• fechado

• baseado em 3270

está se tornando:

• orientado a APIs

• integrado a pipelines

• declarativo

• automatizado

• cloud-aware

E o IBM Z System Automation é uma das peças centrais dessa transformação.

O sysprog padawan que aprender isso agora:

estará anos à frente do mercado.

Porque o futuro do mainframe:

não é abandonar o legado.

É integrar o legado ao futuro.

 

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 lahoratorio pratico de ims dl/i crie seu banco de dados hierarquico

☕🔥💣 LABORATÓRIO IMS DL/I: CRIANDO UM BANCO HIERÁRQUICO NA PRÁTICA

Como construir um banco IMS para CURSOS, ALUNOS e NOTAS — passo a passo para programadores COBOL iniciantes

Se você veio do mundo:

• DB2

• Oracle

• SQL Server

• MySQL

prepare-se.

Porque no IMS o mundo funciona de maneira MUITO diferente. 😄

Aqui não existem:

❌ tabelas tradicionais
❌ SELECT com JOIN
❌ modelagem relacional clássica

No IMS nós pensamos em:

🌳 HIERARQUIA

E quando você entende isso…

o “dinossauro” começa a fazer sentido.

---

🚀 Objetivo do Laboratório

Vamos criar um banco IMS para armazenar:

• cursos

• alunos

• notas

Nossa estrutura será:

CURSO
 └── ALUNO
      └── NOTA

Exemplo:

COBOL
 └── JOAO
      └── 9.5

---

🌳 Entendendo a Hierarquia

No IMS existe:

Tipo	Função
ROOT	topo da árvore
CHILD	filho
DEPENDENT	dependente

No nosso caso:

Segmento	Tipo
CURSO	ROOT
ALUNO	CHILD
NOTA	CHILD do ALUNO

---

💾 Estrutura Física Mental

Fisicamente o IMS gravará algo parecido com:

CURSO
   ↓ ponteiro
ALUNO
   ↓ ponteiro
NOTA

O IMS literalmente conecta segmentos usando ponteiros físicos.

---

☕ Etapa 1 — Criando o DBD

O:

DBD

(Database Description)

define a estrutura do banco.

---

📦 DBD Básico

DBD   NAME=ESCOLA,ACCESS=HIDAM

DATASET DD1=ESCOLADB

SEGM  NAME=CURSO,BYTES=50,PARENT=0
FIELD NAME=(CODCURSO,SEQ,U),BYTES=5,START=1

SEGM  NAME=ALUNO,BYTES=80,PARENT=CURSO
FIELD NAME=(MATRIC,SEQ,U),BYTES=6,START=1

SEGM  NAME=NOTA,BYTES=20,PARENT=ALUNO
FIELD NAME=(IDNOTA,SEQ,U),BYTES=4,START=1

DBDGEN
FINISH
END

---

🧠 O Que Está Acontecendo?

---

🌳 CURSO

Segmento ROOT.

Topo da árvore.

---

👨‍🎓 ALUNO

Filho de CURSO.

---

📊 NOTA

Filho de ALUNO.

---

🚀 ACCESS=HIDAM

Define tipo do banco.

HIDAM:

✅ rápido
✅ indexado
✅ muito usado em IMS clássico

---

☕ Etapa 2 — Gerando o DBD

Agora precisamos gerar o banco.

Usamos JCL.

---

📜 JCL DBDGEN

//DBDGEN EXEC PGM=ASMA90
//SYSIN DD *
  DBD ...
/*

Depois fazemos:

DBDGEN

para criar o módulo do banco.

---

🚀 Etapa 3 — Criando o PSB

O:

PSB

(Program Specification Block)

define como programas acessam o banco.

---

📦 Exemplo PSB

PSBGEN  PSBNAME=PSBESC

PCB     TYPE=DB,DBDNAME=ESCOLA,PROCOPT=G

SENSEG  NAME=CURSO
SENSEG  NAME=ALUNO,PARENT=CURSO
SENSEG  NAME=NOTA,PARENT=ALUNO

END

---

🧠 PROCOPT=G

Permite:

GET

Somente leitura.

Depois podemos usar:

PROCOPT	Função
G	read
A	all
I	insert
D	delete

---

☕ Etapa 4 — ACBGEN

Depois geramos:

ACB

O famoso:

Application Control Block

---

📜 JCL ACBGEN

//ACBGEN EXEC PGM=DFSRRC00

---

🚀 Etapa 5 — Inicializando Banco

Criamos datasets IMS.

Normalmente usando:

• IDCAMS

• VSAM

• utilities IMS

---

📦 Exemplo IDCAMS

//IDCAMS EXEC PGM=IDCAMS

 DEFINE CLUSTER -
 (NAME(ESCOLADB))

---

☕ Etapa 6 — Inserindo Dados

Agora vem a parte divertida. 😄

---

👨‍💻 Programa COBOL IMS

CALL 'CBLTDLI'
     USING 'ISRT'
           DB-PCB
           CURSO-AREA

---

🌳 ISRT

Significa:

INSERT SEGMENT

---

📦 Inserindo CURSO

CURSO = COBOL

---

👨‍🎓 Inserindo ALUNO

Depois navegamos:

CURSO → ALUNO

---

📊 Inserindo NOTA

Depois:

ALUNO → NOTA

---

🚀 Estrutura Final

COBOL
 └── JOAO
      └── 9.5

COBOL
 └── MARIA
      └── 8.7

---

☕ Etapa 7 — Consultando Dados

Agora usamos:

GU

(Get Unique)

---

📦 Exemplo

CALL 'CBLTDLI'
     USING 'GU  '
           DB-PCB
           AREA
           SSA.

---

🔑 SSA

Segment Search Argument.

Exemplo:

CURSO(CODCURSO=COBOL)

---

🚀 Navegando Pela Árvore

Agora usamos:

Comando	Função
GU	busca específica
GN	próximo
GNP	próximo filho

---

🌳 Exemplo Navegação

GU CURSO
GN ALUNO
GNP NOTA

---

☕ Etapa 8 — Atualizando Nota

Usamos:

REPL

(Replace)

---

📦 Fluxo

1️⃣ GU NOTA
2️⃣ altera AREA
3️⃣ REPL

---

☕ Etapa 9 — Deletando Registro

Usamos:

DLET

---

📦 Exemplo

CALL 'CBLTDLI'
     USING 'DLET'
           DB-PCB

---

🚀 O Que o Programador Junior Precisa Entender

No IMS:

⚡ você NÃO pensa em tabela.

Você pensa em:

✅ árvore
✅ caminho
✅ navegação
✅ pai-filho
✅ segmentos

---

⚔️ Diferença Mental DB2 vs IMS

---

🟦 DB2

Você pergunta:

SELECT *

---

🌳 IMS

Você navega:

ROOT → CHILD → CHILD

---

☕ Curiosidade Bellacosa Mainframe

O IMS nasceu em:

🚀 1968

para ajudar a NASA no projeto Apollo.

Décadas depois…

a mesma lógica hierárquica ainda processa:

💳 cartões
🏦 bancos
📱 mobile banking
✈️ companhias aéreas
📡 telecom

O “dinossauro” continua vivo.

E absurdamente rápido.