Translate

sábado, 30 de maio de 2026

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

 

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

ComponenteFunção
SA z/OSmotor de automação
REST Servergateway API
Zowe CLIinterface shell moderna
Ansibleautomaçã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:

VerboFunção
GET?
POST?
DELETE?

Solução

VerboFunção
GETconsulta
POSTcriação/request
DELETEremoçã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

ModoCaracterística
EmbeddedTomcat embutido
Libertydeploy WebSphere Liberty

☕ LAB 16 — CONFIG FILES ZOWE

Objetivo

Entender profiles.


Exercício

Explique:

  • base profile

  • sa profile


Solução

ProfileUso
basepropriedades genéricas
sapropriedades 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

sexta-feira, 29 de maio de 2026

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

 

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

CloudSA
PodDynamic Resource
kubectlZowe
YAMLPlaybook
DeploymentTemplate

☕ 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.


quinta-feira, 28 de maio de 2026

☕🔥💣 “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

 

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.

☕🔥💣

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

 

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:

TipoFunção
ROOTtopo da árvore
CHILDfilho
DEPENDENTdependente

No nosso caso:

SegmentoTipo
CURSOROOT
ALUNOCHILD
NOTACHILD 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:

PROCOPTFunção
Gread
Aall
Iinsert
Ddelete

☕ 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:

ComandoFunção
GUbusca específica
GNpróximo
GNPpró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.


☕🔥 DLI IMS AVANÇADO: O LADO SOMBRIO DO MAINFRAME QUE O SQL NUNCA CONSEGUIU SUBSTITUIR

 

Bellacosa Mainframe e o DL/I IMS o painel de controle dentro do banco de dados hierarquico

☕🔥 DLI IMS AVANÇADO: O LADO SOMBRIO DO MAINFRAME QUE O SQL NUNCA CONSEGUIU SUBSTITUIR

Durante décadas o mercado tentou decretar a morte do IMS.

Vieram os bancos relacionais.

Vieram os ERPs.

Vieram os clusters distribuídos.

Vieram NoSQL, cloud, Kubernetes, microservices e a eterna promessa de que “agora o mainframe acabou”.

Mas existe um pequeno detalhe inconveniente:

Enquanto muita tecnologia moderna ainda luta para entregar estabilidade em escala planetária…

o velho IMS continua processando bilhões de transações críticas diariamente com tempos de resposta absurdos.

E quem realmente conhece DL/I avançado sabe de uma verdade quase proibida no mundo corporativo:

Existem workloads onde o IMS simplesmente continua imbatível.

Não por nostalgia.

Não por legado.

Mas por engenharia brutalmente eficiente.


🌳 DL/I — O Anti-SQL

O SQL venceu o mundo porque trouxe abstração.

O DL/I sobreviveu porque eliminou abstração.

Essa diferença muda tudo.

No SQL o banco precisa descobrir:

  • caminho de acesso

  • plano de execução

  • índice

  • optimizer

  • cardinalidade

  • join strategy

No DL/I:

o programador já sabe exatamente onde quer chegar.

O acesso é navegacional.

Direto.

Hierárquico.

Cirúrgico.

Enquanto o SQL pergunta:

“O que você deseja?”

o DL/I pergunta:

“Você sabe navegar?”

E essa pergunta separa operadores de aventureiros.


⚡ O Verdadeiro Poder do Posicionamento

Muitos programadores COBOL juniores enxergam:

CALL 'CBLTDLI'

como apenas uma API antiga.

Veteranos enxergam outra coisa:

Controle absoluto do path físico.

No IMS avançado, posicionamento é tudo.

O estado corrente do PCB literalmente define o universo de navegação da aplicação.

Quando um programa executa:

GU ROOT
GNP CHILD
GNP CHILD
GN NEXT ROOT

ele não está apenas lendo registros.

Ele está percorrendo estruturas físicas reais de armazenamento.

O IMS não pensa em linhas.

Ele pensa em:

  • segmentos

  • paths

  • dependência hierárquica

  • posicionamento lógico

  • ponteiros físicos

E isso muda completamente a mentalidade de desenvolvimento.


💾 O Segredo Físico Que Pouca Gente Entende

O maior erro de quem vem do SQL é imaginar que o IMS seja apenas “um banco hierárquico”.

Não.

O IMS é um modelo de acesso físico extremamente otimizado.

A verdadeira mágica está nos ponteiros.

Em bancos HIDAM, HDAM e DEDB, o IMS reduz drasticamente o custo de navegação usando estruturas físicas extremamente agressivas para a época.

Enquanto bancos relacionais modernos frequentemente precisam montar planos complexos de execução…

o IMS muitas vezes apenas segue ponteiros previamente organizados.

É quase obsceno de tão eficiente.

Especialmente em workloads previsíveis.


🚀 HDAM — Quando Hashing Vira Arte Negra

Veteranos IMS sabem que HDAM não é apenas “acesso direto”.

HDAM é uma filosofia.

A randomizing routine define praticamente o comportamento físico do banco.

E aqui mora um dos pontos mais subestimados do universo mainframe:

O programador IMS influenciava diretamente o layout físico da informação.

Não existia o conforto moderno do:

“deixa o banco resolver.”

No IMS avançado:

você é parcialmente responsável pelo desempenho físico do sistema.

E isso assusta desenvolvedores modernos acostumados com abstração total.


🌳 Parentage — O Peso da Hierarquia

No mundo relacional:

JOIN resolve quase tudo.

No IMS:

hierarquia mal desenhada vira pesadelo operacional.

Veteranos conhecem a dor de:

  • logical relationships

  • secondary indexing

  • twin chains

  • parentage explosion

  • reorgs monstruosos

Porque o IMS premia modelos previsíveis.

Mas pune violentamente modelagens ruins.

Um DBD mal desenhado pode condenar décadas de manutenção.

E muitos sistemas bancários ainda carregam decisões arquiteturais feitas nos anos 70.


☠️ O Trauma Coletivo Chamado REORG

Se existe uma entidade mitológica no mundo IMS…

ela se chama:

REORG

Quem nunca passou madrugada acompanhando:

  • unload

  • reload

  • image copy

  • prefix resolution

  • pointer rebuild

  • HD reorganization

ainda não conheceu o verdadeiro lado operacional do IMS.

Porque diferente do mundo SQL moderno, no IMS o layout físico importa absurdamente.

Overflow chains crescem.

Ponteiros degradam.

Randomizers envelhecem mal.

E eventualmente o banco precisa ser reorganizado.

O problema?

Alguns ambientes IMS possuem dezenas de TB e bilhões de segmentos.

Reorganizar isso não é “maintenance window”.

É engenharia de guerra.


🔥 Fast Path — O Monstro Sagrado

Quando alguém menciona:

DEDB Fast Path

os veteranos imediatamente entendem que a conversa ficou séria.

Porque Fast Path não foi criado para conveniência.

Foi criado para TPS brutal.

A ideia era simples:

reduzir ainda mais overhead.

Menos logging.

Menos locking.

Menos complexidade.

Mais velocidade.

E mesmo hoje o desempenho de certos ambientes Fast Path continua assustador.

Especialmente em telecom e financial switching.


⚔️ IMS vs DB2 — A Guerra Que Nunca Acabou

O mercado gosta de tratar IMS e DB2 como concorrentes.

Veteranos sabem que isso é ingenuidade.

Os maiores ambientes do planeta usam:

IMS + DB2

ao mesmo tempo.

Porque cada um resolve problemas diferentes.

DB2 entrega:

  • flexibilidade

  • SQL

  • analytics

  • BI

  • consultas ad-hoc

IMS entrega:

  • TPS monstruoso

  • previsibilidade

  • latência mínima

  • throughput absurdo

O DB2 é um cérebro analítico.

O IMS é um sistema nervoso autônomo.


🧠 O Que os Novatos Não Percebem

A maioria dos desenvolvedores modernos nunca precisou pensar em:

  • CI split

  • root anchor points

  • segment occurrence

  • PCB sensitivity

  • path call optimization

  • SSA qualification

  • PROCOPT impact

Mas no IMS avançado esses detalhes definem:

  • performance

  • lock contention

  • response time

  • CPU consumption

  • operational scalability

E é justamente isso que torna o IMS tão fascinante.

Ele exige que o desenvolvedor compreenda a máquina.


☕ Easter Egg Mainframe

Existe uma velha piada entre sysprogs veteranos:

“SQL é para perguntar.
DL/I é para saber.”

😄

E honestamente…

existe uma certa verdade cruel nisso.


🌐 IMS Moderno — O Dinossauro Virou API

Talvez o aspecto mais surreal do IMS moderno seja este:

Hoje APIs REST em JSON frequentemente terminam em:

CBLTDLI

Lá no fundo.

Aplicativos mobile modernos.

Pix.

Cartões.

Cloud híbrida.

OpenShift.

Tudo isso frequentemente desemboca em um banco hierárquico criado antes da internet existir.

É quase cyberpunk corporativo.


💣 O Grande Paradoxo do IMS

O IMS parece antigo porque ele é antigo.

Mas ao mesmo tempo ele continua incrivelmente moderno em alguns princípios fundamentais:

  • eficiência

  • previsibilidade

  • throughput

  • estabilidade

  • controle físico

  • otimização extrema

Enquanto o mundo moderno adicionou camadas infinitas de abstração…

o IMS permaneceu brutalmente próximo do hardware.

E talvez seja justamente por isso que ele ainda sobreviva.


🚀 O Dinossauro Que Continua Dominando

O mercado adora prever o fim do mainframe.

Mas existe um detalhe inconveniente:

Boa parte do sistema financeiro mundial ainda depende dele.

E dentro desse ecossistema…

o IMS continua sendo uma das peças mais resilientes já criadas pela engenharia de software corporativa.

Talvez porque no final das contas:

moda tecnológica muda.

Mas performance real em missão crítica continua rara.

E o velho DL/I ainda sabe exatamente onde os dados estão.

☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN

Bellacosa Mainframe apresenta um checklist de RCA para sysprog junior


☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN

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

A maioria dos Sysprogs juniores aprende primeiro a resolver incidentes.

Poucos aprendem a impedir que eles aconteçam novamente.

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


🔍 NÍVEL 1 — FUNDAMENTOS DO INVESTIGADOR

Conhecer a arquitetura do ambiente

☐ Entender o fluxo completo da aplicação

☐ Conhecer as LPARs existentes

☐ Entender Sysplex

☐ Conhecer JES2/JES3

☐ Entender CICS

☐ Entender DB2

☐ Entender MQ

☐ Conhecer Storage Management

☐ Entender WLM

☐ Conhecer SDSF profundamente

Objetivo

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


📋 NÍVEL 2 — COLETA DE EVIDÊNCIAS

Antes de agir:

☐ Registrar horário exato do incidente

☐ Identificar quem reportou

☐ Verificar impacto

☐ Capturar mensagens de erro

☐ Salvar logs

☐ Salvar SYSLOG

☐ Salvar JESMSGLG

☐ Salvar JESJCL

☐ Salvar JESYSMSG

☐ Registrar alterações recentes

☐ Verificar deploys recentes

Regra de ouro

Nunca altere o ambiente antes de coletar evidências.


🔥 NÍVEL 3 — ANÁLISE JES2

☐ Verificar initiators

☐ Verificar classes

☐ Verificar backlog

☐ Verificar spool

☐ Verificar HOLDs

☐ Verificar jobs looping

☐ Verificar jobs aguardando recursos

☐ Verificar ENQ contention

☐ Verificar mensagens $HASP

Pergunta obrigatória

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


💾 NÍVEL 4 — STORAGE E MEMÓRIA

☐ Verificar CSA

☐ Verificar ECSA

☐ Verificar SQA

☐ Verificar ESQA

☐ Verificar Private Area

☐ Procurar storage leaks

☐ Analisar crescimento anormal

☐ Verificar mensagens IEA e IEF

☐ Consultar RMF

Atenção

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


⚡ NÍVEL 5 — PERFORMANCE

☐ Verificar CPU

☐ Verificar I/O

☐ Verificar Paging

☐ Verificar DASD

☐ Verificar Coupling Facility

☐ Verificar WLM

☐ Verificar gargalos

☐ Comparar com baseline

☐ Analisar tendências

Objetivo

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


🖥️ NÍVEL 6 — RCA EM CICS

☐ Verificar transações lentas

☐ Verificar tasks pendentes

☐ Verificar Short On Storage

☐ Verificar TD Queues

☐ Verificar TS Queues

☐ Verificar DB2 Attach

☐ Verificar MQ Attach

☐ Verificar abends

☐ Verificar dumps

☐ Analisar traces

Nunca conclua

"CICS está lento"

sem descobrir:

"POR QUE está lento?"


🗄️ NÍVEL 7 — RCA EM DB2

☐ Verificar deadlocks

☐ Verificar lock escalation

☐ Verificar SQLCODEs

☐ Verificar buffer pools

☐ Verificar índices

☐ Procurar full table scan

☐ Verificar RUNSTATS

☐ Verificar REORG pendente

☐ Verificar crescimento de tabelas

Regra

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


📬 NÍVEL 8 — RCA EM MQ

☐ Verificar Queue Depth

☐ Verificar canais

☐ Verificar backlog

☐ Verificar consumidores

☐ Verificar produtores

☐ Verificar DLQ

☐ Verificar mensagens presas

☐ Verificar timeouts

Lembre-se

Fila cheia normalmente é consequência.

Raramente é a causa raiz.


📊 NÍVEL 9 — OBSERVABILIDADE

☐ Utilizar OMEGAMON

☐ Utilizar RMF

☐ Utilizar SMF

☐ Utilizar NetView

☐ Utilizar Sysview

☐ Criar dashboards

☐ Definir baseline

☐ Identificar anomalias

☐ Correlacionar eventos

Meta

Parar de reagir.

Começar a prever.


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

Five Whys

☐ Aplicar os 5 Porquês


Timeline Analysis

☐ Construir linha do tempo


Event Correlation

☐ Correlacionar eventos


Impact Analysis

☐ Medir impacto real


Trend Analysis

☐ Procurar recorrência


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

☐ Automatizar alertas

☐ Automatizar coleta de evidências

☐ Automatizar correções simples

☐ Criar scripts REXX

☐ Criar procedimentos de recuperação

☐ Integrar com SA z/OS

☐ Integrar com NetView

☐ Criar runbooks

Objetivo

Não resolver mais rápido.

Resolver menos vezes.


📚 NÍVEL 12 — CONHECIMENTO HISTÓRICO

☐ Manter base de incidentes

☐ Documentar RCA

☐ Criar Wiki interna

☐ Registrar lições aprendidas

☐ Catalogar soluções

☐ Criar biblioteca de dumps

☐ Registrar padrões recorrentes

Ouro do Sysprog

Experiência documentada vale mais que memória.


🧠 NÍVEL 13 — MENTALIDADE DE MESTRE

Antes de qualquer ação pergunte:

☐ O que aconteceu?

☐ Quando aconteceu?

☐ Quem foi impactado?

☐ O que mudou?

☐ Isso já aconteceu antes?

☐ O que os logs mostram?

☐ O que os dados mostram?

☐ Estou tratando sintoma ou causa?

☐ Como impedir recorrência?

☐ O que aprendi hoje?


🏆 CHECKLIST FINAL DO SYSprog MESTRE

Quando um incidente ocorrer:

❌ Não reinicie imediatamente

❌ Não assuma conclusões

❌ Não culpe usuários

❌ Não culpe desenvolvedores

❌ Não culpe infraestrutura

✅ Colete evidências

✅ Analise dados

✅ Correlacione eventos

✅ Pergunte "por quê?"

✅ Encontre a causa raiz

✅ Elimine a recorrência

✅ Documente a descoberta

✅ Compartilhe conhecimento


☕ Regra Suprema do Bellacosa Mainframe

"O Padawan reinicia o CICS.

O Sysprog investiga o dump.

O Mestre encontra a causa raiz.

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

 

quarta-feira, 27 de maio de 2026

☕🚀 IMS: O DINOSSAURO IMORTAL QUE AINDA MOVE O MUNDO

 

Bellacosa Mainframe apresenta o banco de dados hieraquico ISM

☕🚀 IMS: O DINOSSAURO IMORTAL QUE AINDA MOVE O MUNDO

A incrível história do sistema criado na era Apollo que continua processando bilhões de transações todos os dias

Se você é um programador COBOL júnior e começou recentemente a ouvir palavras como IMS, DL/I, PCB, PSB ou GU, talvez tenha pensado:

“Meu Deus… isso parece tecnologia alienígena dos anos 70.”

E sinceramente?

Você não está totalmente errado. 😄

O IMS é uma das tecnologias mais antigas ainda em operação no planeta. Mas existe um detalhe importante:

Ele também é uma das mais resilientes, rápidas e lucrativas da história da computação corporativa.

Enquanto centenas de tecnologias desapareceram, o IMS sobreviveu.

E não apenas sobreviveu.

Ele continua processando:

  • cartões de crédito

  • ATM bancário

  • sistemas de companhias aéreas

  • seguros

  • telecom

  • operações financeiras globais

em volumes absurdos.

Sim… existe uma chance enorme de você já ter usado IMS hoje sem perceber.


🌕 A Origem do IMS — NASA, Apollo e o Homem na Lua

O IMS nasceu em 1968.

Naquela época, a IBM e a Rockwell trabalhavam no projeto Apollo da NASA.

O problema era gigantesco.

A NASA precisava controlar milhares de componentes do foguete Saturn V:

  • peças

  • logística

  • engenharia

  • rastreamento

  • montagem

E os bancos de dados tradicionais da época simplesmente não conseguiam entregar a performance necessária.

Então nasceu o IMS:

Information Management System

Inicialmente criado para gerenciamento hierárquico de informações críticas do projeto Apollo.

Ou seja:

Existe uma ligação histórica real entre o IMS e a corrida espacial.

☕ Easter Egg Mainframe:

Muita gente brinca dizendo:

“O homem chegou à Lua graças ao COBOL, ao mainframe e ao café.”

E honestamente… não é tão exagerado assim.


🌳 O Grande Diferencial do IMS

Diferente do DB2 ou Oracle, o IMS NÃO é relacional.

Ele trabalha com:

Banco de dados hierárquico

Imagine uma árvore:

CLIENTE
 └── CONTA
      └── CARTAO
           └── MOVIMENTO

No IMS os dados possuem:

  • pai

  • filho

  • caminho de navegação

Isso deixa o acesso extremamente rápido.

Enquanto um banco relacional precisa pensar em:

  • JOIN

  • optimizer

  • plano de acesso

  • estatísticas

o IMS normalmente já sabe exatamente onde navegar.

É quase como um labirinto secreto onde o programa já conhece o caminho.


⚡ Por Que o IMS é Tão Rápido?

Porque ele foi criado numa época brutalmente limitada.

Nos anos 60 e 70:

  • CPU era caríssima

  • disco era lento

  • memória era minúscula

Então a IBM projetou o IMS para minimizar ao máximo o número de acessos físicos ao disco.

O resultado?

Uma arquitetura extremamente otimizada.

O IMS utiliza:

  • ponteiros físicos

  • navegação direta

  • acesso hierárquico

  • estruturas previsíveis

Em vez de perguntar:

“Como encontrar o dado?”

o IMS trabalha com:

“Eu já sei exatamente onde ele está.”


💾 Como os Dados São Gravados Fisicamente?

Aqui entra uma das partes mais fascinantes do IMS.

Fisicamente os dados normalmente são armazenados em datasets z/OS usando:

  • VSAM

  • OSAM

Mas o IMS NÃO grava tabelas como um banco relacional.

Ele grava:

Segmentos hierárquicos

Exemplo:

CLIENTE
   ↓ ponteiro físico
CONTA
   ↓ ponteiro físico
MOVIMENTO

Os segmentos ficam ligados fisicamente por ponteiros internos.

Isso permite uma navegação extremamente rápida entre os registros.

É quase como se o banco tivesse túneis secretos ligando os dados.


🧠 O Que é DL/I?

Se existe um coração no IMS…

Esse coração é o:

DL/I — Data Language One

O DL/I é a interface usada pelos programas COBOL para conversar com o IMS.

No DB2 usamos:

SELECT
INSERT
UPDATE
DELETE

No IMS usamos comandos como:

  • GU

  • GN

  • GNP

  • ISRT

  • REPL

  • DLET

Tudo via:

CALL 'CBLTDLI'

Ou seja:

O programa COBOL literalmente navega pela árvore do banco.


👨‍💻 Exemplo Simples de Acesso IMS

Imagine que queremos localizar um cliente.

A chamada clássica seria:

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

O comando:

GU

significa:

Get Unique

O IMS então:

  1. usa o índice

  2. localiza o segmento

  3. posiciona o ponteiro

  4. devolve o registro

Tudo absurdamente rápido.


🔑 PCB, PSB e SSA — As Siglas Misteriosas

Quando alguém começa IMS pela primeira vez, parece que caiu num filme cyberpunk dos anos 70.

As siglas assustam.

Mas a lógica é simples.

PCB

Program Communication Block

Define o acesso ao banco.

PSB

Program Specification Block

Define quais bancos e PCBs o programa pode usar.

SSA

Segment Search Argument

É quase um “WHERE” do IMS.

Exemplo:

CLIENTE(COD=00001)

📜 IMS e JCL

No mundo IMS, o JCL também ganha superpoderes.

Um programa batch IMS normalmente roda com:

//STEP01 EXEC PGM=DFSRRC00,
// PARM='DLI,PROGIMS,PSBTEST'

O famoso:

DFSRRC00

é praticamente o “portal mágico” do batch IMS.

☕ Curiosidade Bellacosa Mainframe:

Quando um iniciante vê um JCL IMS pela primeira vez, normalmente reage assim:

“Isso é um JCL… ou um ritual arcano da IBM?”

😄


⚔️ IMS vs DB2

Essa é uma guerra clássica.

O IMS possui:

✅ performance monstruosa
✅ baixo overhead
✅ TPS absurdamente alto

Mas o DB2 possui:

✅ SQL flexível
✅ analytics
✅ joins
✅ consultas ad-hoc

Por isso muitos bancos usam:

IMS + DB2 juntos

IMS processa o core transacional.

DB2 faz relatórios e analytics.

É como:

IMS = motor Fórmula 1
DB2 = cérebro analítico

🤖 IMS Moderno — Sim, Ele Continua Evoluindo

Muita gente pensa que IMS ficou preso nos anos 70.

Errado.

Hoje o IMS conversa com:

  • APIs REST

  • JSON

  • Java

  • OpenShift

  • Cloud híbrida

  • Mobile banking

  • z/OS Connect

Ou seja:

Seu aplicativo de banco no celular pode estar conversando com um software criado há mais de 50 anos.

Isso é simplesmente absurdo.

E incrível.


💼 Vale a Pena Aprender IMS?

Para um programador COBOL júnior?

SIM. MUITO.

Porque existem poucos especialistas.

E muitos profissionais IMS estão se aposentando.

O mercado procura gente que entenda:

  • COBOL

  • IMS

  • JCL

  • VSAM

  • CICS

  • DB2

Essa combinação continua extremamente valorizada.

Especialmente em:

  • bancos

  • seguradoras

  • telecom

  • aviação

  • governo


☕ O Dinossauro Que Nunca Morreu

O IMS é um paradoxo fascinante.

Ele nasceu antes da internet moderna.

Antes do Windows.

Antes do Linux.

Antes do SQL dominar o mundo.

E mesmo assim continua vivo.

Mais do que vivo.

Continua movimentando bilhões de dólares diariamente.

Porque no fim das contas, empresas gigantes não querem apenas “tecnologia nova”.

Elas querem:

  • estabilidade

  • velocidade

  • segurança

  • confiabilidade

E nisso o IMS ainda é um verdadeiro monstro.

Ou como muita gente brinca no mundo mainframe:

“Tecnologia antiga não significa tecnologia ultrapassada.”

Especialmente quando ela ainda move o planeta.