Translate

Mostrar mensagens com a etiqueta DevOpsMainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta DevOpsMainframe. Mostrar todas as mensagens

terça-feira, 7 de abril de 2026

🧪 LAB SMP/E — “Do APPLY sem CHECK ao RESTORE salvador”

 

Bellacosa Mainframe indica um lab para troubleshooting no Z/os SMP/E

🧪 LAB SMP/E — “Do APPLY sem CHECK ao RESTORE salvador”

🎯 Objetivo

Você vai:

  • Executar RECEIVE → APPLY → ACCEPT → RESTORE
  • Simular um erro real
  • Diagnosticar via relatórios
  • Recuperar o sistema corretamente

👉 Traduzindo:

você vai errar com segurança para aprender de verdade


🧱 Cenário do LAB

🖥️ Ambiente

  • z/OS (real ou Hercules TK5)
  • SMP/E configurado
  • CSI existente
  • Zonas:
    • GLOBAL
    • TARGET
    • DLIB

📦 Dados do exercício

  • FMID: HXYZ123
  • PTFs:
    • UQ00001 (base)
    • UQ00002 (dependente)
    • UQ00003 (com problema 💀)

🔄 FASE 1 — RECEIVE

🎯 Objetivo

Carregar SYSMODs no SMP/E


🧾 JCL

//RECEIVE JOB ...
//SMPE EXEC PGM=GIMSMP
//SMPCSI DD DISP=SHR,DSN=SEU.CSI
//SMPPTFIN DD DISP=SHR,DSN=SEU.PTF.INPUT
//SMPCNTL DD *
SET BDY(GLOBAL).
RECEIVE SYSMODS.
/*

✅ Esperado

  • SYSMODs no SMPPTS
  • GLOBAL ZONE atualizada

🔍 Validar

  • SMPRPT
  • LIST SYSMODS

💣 FASE 2 — ERRO PROPOSITAL (APPLY SEM CHECK)

🎯 Objetivo

Simular erro real de produção


🧾 JCL (errado propositalmente)

//APPLY JOB ...
//SMPE EXEC PGM=GIMSMP
//SMPCSI DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL DD *
SET BDY(TARGET).
APPLY SELECT(UQ00003).
/*

💥 Resultado esperado

  • Aplicação incompleta OU
  • Sistema inconsistente

🧠 O que você fez

💀 ignorou dependências + não usou CHECK


🔍 FASE 3 — DIAGNÓSTICO

🎯 Objetivo

Descobrir o problema


📄 Analisar:

  • SMPOUT
  • SMPRPT
  • Causer Report

💡 Encontrar:

  • Dependência faltando (UQ00002)
  • Possível HOLD

🧠 Insight

SMP/E não falha — ele te avisa


🔁 FASE 4 — APPLY CORRETO

🎯 Objetivo

Corrigir com CHECK


🧾 JCL

//APPLY JOB ...
//SMPE EXEC PGM=GIMSMP
//SMPCSI DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL DD *
SET BDY(TARGET).
APPLY CHECK SELECT(UQ00003) GROUPEXTEND.
/*

✅ Resultado

  • Lista completa de dependências
  • Nenhuma alteração real

🔥 Agora aplicar certo:

APPLY SELECT(UQ00003) GROUPEXTEND.

📦 FASE 5 — ACCEPT

🎯 Objetivo

Consolidar mudança


🧾 JCL

//ACCEPT JOB ...
//SMPE EXEC PGM=GIMSMP
//SMPCSI DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL DD *
SET BDY(DLIB).
ACCEPT CHECK.
/*

⚠️ Depois:

ACCEPT.

💀 Agora você não volta fácil…


🚨 FASE 6 — INCIDENTE

🎯 Simular problema pós-APPLY

👉 Imagine:

  • Programa começa a falhar
  • Load module inconsistente

🔄 FASE 7 — RESTORE

🎯 Objetivo

Reverter mudança


🧾 JCL

//RESTORE JOB ...
//SMPE EXEC PGM=GIMSMP
//SMPCSI DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL DD *
SET BDY(TARGET).
RESTORE SELECT(UQ00003) GROUP CHECK.
/*

🔍 Ajustar dependências

Depois:

RESTORE SELECT(UQ00003) GROUP.

✅ Resultado

  • TARGET revertido
  • Sistema estável

💣 VARIAÇÃO AVANÇADA (nível sênior)

😈 Faça isso:

  1. APPLY
  2. ACCEPT
  3. Tente RESTORE

💥 Resultado:

RESTORE não resolve


🧠 Aprendizado:

ACCEPT muda o jogo completamente


📊 CHECKLIST DO LAB

EtapaStatus
RECEIVE executado
APPLY sem CHECK (erro)
Diagnóstico feito
APPLY correto
ACCEPT realizado
RESTORE executado

🧠 LIÇÕES DO LAB

🔥 1. RECEIVE define o futuro

🔥 2. APPLY muda o presente

🔥 3. ACCEPT congela o sistema

🔥 4. RESTORE depende do passado


☕ FRASE FINAL

💀 “O erro não está no SMP/E… está em quem pula etapas.”


segunda-feira, 23 de janeiro de 2023

🧠 SMP/E: O Orquestrador Invisível do z/OS — O Dev COBOL Não Vê… Mas Depende Todos os Dias

 


Bellacosa Mainframe apresente o orquestrador de atualizaçõs no Z/OS

🧠 SMP/E: O Orquestrador Invisível do z/OS — O Dev COBOL Não Vê… Mas Depende Todos os Dias

Se você é um dev COBOL sênior, já escreveu milhares de linhas, já enfrentou abends misteriosos, já discutiu copybook em reunião… mas existe uma verdade silenciosa:

Quem realmente controla o seu ambiente não é o COBOL. É o SMP/E.

E se você nunca mergulhou fundo nele… você está dirigindo um Ferrari com os olhos vendados.


🏛️ Origem: Quando instalar software virou um problema sério

Nos primórdios do mainframe:

  • Software era entregue em fitas físicas
  • Instalação era manual
  • Dependências? 😅 Boa sorte…

Foi aí que a IBM criou o:

👉 SMP (System Modification Program)
E depois evoluiu para o SMP/E (Extended)

💥 O objetivo:

Transformar o caos de instalação em um processo controlado, auditável e reversível


🧩 O mundo real: o que você usa… sem perceber

Você roda:

  • COBOL ✔
  • CICS ✔
  • DB2 ✔
  • REXX ✔
  • ISPF ✔

Mas tudo isso chegou ao sistema via:

👉 SMP/E


📦 O conceito mais importante: SYSMOD

Tudo no SMP/E gira em torno de:

👉 SYSMOD (System Modification)

Tipos:

  • FMID → Produto base
  • PTF → Fix oficial
  • APAR → Fix temporário
  • USERMOD → Customização

💥 Regra de ouro:

Se modifica algo → depende de um FMID


🧠 Easter Egg #1 (prova e vida real)

APAR não é elemento — é SYSMOD
(essa derruba muita gente 😄)


🧱 Elementos: o que realmente vai pro sistema

Um SYSMOD é composto por:

  • MOD → executável
  • SRC → source
  • MAC → macro
  • JAR / zFS → mundo UNIX
  • Panels / REXX / CLIST

💥 Tradução COBOL:

Seu load module veio de um MOD, que veio de um SRC, controlado pelo SMP/E


📀 RELFILE: o “pacote de entrega”

Antes do APPLY, existe o pacote:

👉 RELFILE

Hoje:

  • Download via internet

Antes:

  • 📼 Fita magnética

Dentro dele:

  • MCS (metadados)
  • Elementos do software

⚙️ O pipeline sagrado do SMP/E

Aqui está o coração da operação:

RECEIVE → APPLY → ACCEPT

📥 RECEIVE (entrada no sistema)

  • Carrega RELFILE
  • Atualiza GLOBAL ZONE
  • Prepara staging

👉 Ainda não instala nada


⚙️ APPLY (instalação real)

  • Copia elementos para TARGET LIBRARIES
  • Atualiza TARGET ZONE

👉 Agora o software roda


✅ ACCEPT (consolidação)

  • Copia para DISTRIBUTION LIBRARIES
  • Atualiza DLIB ZONE

👉 Vira baseline


🧠 Easter Egg #2 (nível prova)

RECEIVE → GLOBAL
APPLY → TARGET
ACCEPT → DLIB

Se decorar isso → passa em qualquer prova 😎


🗃️ CSI: o cérebro do SMP/E

👉 CSI (Consolidated Software Inventory)

Baseado em VSAM KSDS

Guarda:

  • Versões
  • Dependências
  • Elementos
  • Histórico

💥 É o “CMDB raiz” do mainframe


🧠 Curiosidade forte

Um CSI pode controlar vários produtos ao mesmo tempo


⚠️ O pulo do gato: dependências

Antes de instalar:

  • Prerequisite (PRE) → precisa antes
  • Corequisite (CO) → precisa junto

👉 SMP/E valida automaticamente


🧠 Easter Egg #3

SMP/E pode:

✔ Instalar dependências
✔ Cancelar instalação

Mas nunca:

❌ Instalar versão mais antiga sobre nova
❌ Desinstalar arbitrariamente


🔥 Insight de produção

SMP/E não é apt-get
SMP/E é governança


🏭 Exemplo real (modo Bellacosa)

Você precisa aplicar um fix no CICS:

  1. Recebe PTF
  2. SMP/E verifica:
    • FMID correto
    • PRE/CO ok
  3. APPLY:
    • Atualiza loadlibs
  4. Testa em ambiente
  5. ACCEPT:
    • Consolida baseline

⚠️ Prática avançada (ouro)

👉 Nunca dê ACCEPT imediatamente

Porque:

  • APPLY = reversível
  • ACCEPT = compromisso

🧠 Easter Egg #4 (experiência real)

Erro clássico:

GIMxxxx

👉 80% das vezes:

  • FMID errado
  • Dependência faltando
  • CSI inconsistente

🔌 Interfaces SMP/E

Você pode usar:

  • ISPF
  • Batch (JCL)
  • API

💥 Sim — SMP/E pode ser automatizado


🚀 SMP/E no mundo DevOps

Tradução moderna:

DevOpsSMP/E
PipelineRECEIVE/APPLY/ACCEPT
DeployAPPLY
PromoteACCEPT
ArtifactRELFILE

🧠 Easter Egg final

O mainframe já fazia DevOps… antes de ser moda.


🎯 Conclusão

Se você escreve COBOL e ignora SMP/E:

👉 Você domina a aplicação
👉 Mas não domina o ambiente


🔥 Frase final (pra guardar)

COBOL escreve o sistema.
SMP/E garante que ele exista.

sábado, 21 de setembro de 2013

🔥 “PASSOU EM HOMOLOGAÇÃO… QUEBROU EM PRODUÇÃO”: O Fantasma do S0C7 que Só Aparece Depois — Um Guia de Sobrevivência para QA, Sustentação e Padawans do Mainframe ☕💻

 

Bellacosa Mainframe ajudando a solucionar abends soc7

🔥 “PASSOU EM HOMOLOGAÇÃO… QUEBROU EM PRODUÇÃO”: O Fantasma do S0C7 que Só Aparece Depois — Um Guia de Sobrevivência para QA, Sustentação e Padawans do Mainframe ☕💻

Senhoras e senhores da trincheira do legado, cavaleiros do JCL, monges do dump IPCS e jovens padawans da qualidade…

Existe uma entidade que não respeita cronograma, SLA, ITIL nem cerimônia ágil.

Ela não aparece no DEV.
Não aparece no SIT.
Não aparece na UAT.

Mas às 02:37 da manhã de domingo, em batch crítico…

💥 S0C7 — DATA EXCEPTION

E o telefone toca.


☕ A História que Todo Time de Sustentação Já Viveu

Projeto entregue.
Testes aprovados.
Checklist verde.
Change implementado.

Primeira carga real de produção.

Tudo parece normal… até o job noturno cair.

No log:

IGZ0006S A data exception (System Completion Code=0C7)

O desenvolvedor jura:

“Mas isso passou em todos os testes!”

O analista de QA responde:

“Usamos os dados homologados aprovados pelo negócio.”

O suporte pensa:

“Ok… quem mexeu no layout do arquivo?”


🧠 Verdade Inconveniente nº 1

Homologação testa cenários.
Produção testa a realidade.

E a realidade tem:

✔ Dados sujos
✔ Interfaces antigas
✔ Sistemas externos fora de padrão
✔ Arquivos truncados
✔ Migrações parciais
✔ Conversões mal documentadas
✔ Operadores humanos cansados
✔ Programas de 1987 rodando “intactos”


🔎 O Vilão Invisível: Dados NÃO CONFIÁVEIS

Em ambientes corporativos reais, especialmente em sistemas core:

👉 O programa raramente quebra por lógica
👉 Ele quebra porque confiou em dados inválidos

E quando existe COMP-3 no meio

💣 Basta um nibble errado.


🧩 Onde QA e Homologação Mais Erram (Sem Saber)

Testes usam dados:

✔ Bonitos
✔ Consistentes
✔ Validados
✔ “De laboratório”

Produção usa dados:

💀 Históricos
💀 Herdados
💀 Convertidos
💀 Misturados
💀 Incompletos
💀 Digitados manualmente


📜 Um Easter Egg Histórico (Pouca Gente Sabe)

Nos anos 70 e 80, quando dados vinham de cartões perfurados e fitas:

👉 Erros físicos eram comuns
👉 Leituras incompletas aconteciam
👉 Bits podiam “virar”

Por isso, muitos sistemas antigos tinham:

  • Validações redundantes

  • Campos de controle

  • Checksums primitivos

  • Programas “sanitizadores”

Com a modernização…

Essas camadas desapareceram.

Mas os dados continuaram vivos.


🧨 Exemplo Real Clássico de Produção

Arquivo externo enviado por parceiro.

Layout:

05 VALOR-TOTAL PIC S9(9)V99 COMP-3.

Em homologação:

✔ Arquivo gerado por ferramenta
✔ Dados corretos

Em produção:

Um registro veio truncado por erro na transferência.

Hex esperado:

12 34 56 78 9C

Hex recebido:

12 34 56 78 9A

Nibble final inválido.

Resultado:

💥 S0C7 ao fazer COMPUTE


⚠️ Verdade Inconveniente nº 2

O erro não acontece na leitura.
Nem no MOVE.

👉 Ele explode quando o valor é usado.

Ou seja:

O problema pode estar centenas de linhas antes.


🛠️ Como Times de Sustentação Resolvem de Verdade

Não é só “corrigir o programa”.

É fazer engenharia reversa do desastre.

✔ Passo 1 — Identificar o registro exato

  • Dump

  • SYSOUT

  • SMF

  • Logs do step anterior


✔ Passo 2 — Analisar HEX (não DISPLAY)

Porque COMP-3 não é texto.

Ferramentas comuns:

  • IPCS

  • File-AID

  • Abend-AID

  • Debug Tool


✔ Passo 3 — Descobrir a origem

Perguntas chave:

  • Quem gerou o arquivo?

  • Houve compressão?

  • Transferência binária ou texto?

  • Mudou o layout?

  • Sistema fonte mudou linguagem?

  • Houve conversão ASCII/EBCDIC?


🧪 Guia de Ouro para QA de Mainframe

Se você trabalha com qualidade, homologação ou testes…

💎 Teste dados feios.

Crie cenários com:

  • Campos vazios

  • Bytes inválidos

  • Tamanhos errados

  • Registros truncados

  • Valores máximos

  • Valores negativos inesperados

  • Arquivos mistos

  • Dados históricos reais anonimizados

👉 Isso vale mais que mil casos “bonitinhos”.


🧙‍♂️ Técnicas de Defesa que Mestres do Mainframe Usam

🔹 Inicialização agressiva

MOVE ZERO TO WS-AMOUNT

🔹 Validação na entrada

Nunca confiar em interface externa.


🔹 Programas sanitizadores

Batch que valida e rejeita registros suspeitos antes do processamento principal.


🔹 Versionamento rigoroso de copybooks

Uma pequena divergência de layout pode causar caos.


🔹 Testes com dados de produção (mascarados)

Isso separa ambientes maduros dos amadores.


🤯 Curiosidade Técnica Pouco Comentada

S0C7 não é erro “de COBOL”.

É um hardware exception de decimal arithmetic tratado pelo runtime.

Ou seja:

👉 O processador detecta que os bits não formam um número decimal válido.

Mainframe não “tenta adivinhar”.
Ele simplesmente interrompe.

Precisão absoluta > tolerância.


🧩 Verdade Final para Padawans

Se você viu S0C7…

Não pense primeiro no código.

Pense:

“Qual dado traiu o programa?”


☕ Moral da História

Produção não é um ambiente maior.

É um ambiente mais caótico.

Programas COBOL antigos sobrevivem décadas porque:

👉 Foram escritos assumindo que o mundo é imperfeito.

Quando esquecemos disso…

O legado cobra.


💥 Regra de Ouro do Bellacosa Mainframe

“Sistema robusto não é o que funciona com dados corretos.
É o que sobrevive a dados errados.”