🧠 Padawan, aproxime-se do console… hoje o assunto é: Monitoramento de Disco no IBM Mainframe

 

Bellacosa Mainframe apresenta storage no ZOS

🧠 Padawan, aproxime-se do console… hoje o assunto é: Monitoramento de Disco no IBM Mainframe

(ou: como não deixar o DASD virar o Lado Sombrio da Força)

---

📜 Um pouco de história (porque no mainframe nada nasce ontem)

Antes de existir storage definido por software, cloud ou “é só aumentar o volume”, já existia DASD — Direct Access Storage Device.
Nos primórdios, isso significava discos gigantes, barulhentos, caríssimos e venerados 🛐.

👉 O mainframe sempre tratou disco como recurso nobre.
Nada de “joga log fora depois a gente vê”.

E aí entra o lendário…

---

IBM Mainframe unidade de disco 

💿 DASD – Direct Access Storage Device

No mundo z/OS, disco não é disco, é DASD.
E DASD tem personalidade, etiqueta e hierarquia.

Tipos clássicos

• 📀 3380 – Jurassic Park (ainda aparece em livro antigo)

• 💿 3390 – O padrão ouro (e nosso foco)

• 🧠 EAV / EAS – Extended Address Volumes (para os discos gigantes de hoje)

---

Unidade de disco 3390 antiga

🧱 O mito do 3390

📦 O que é um 3390?

Um modelo lógico de disco, não importa se o storage físico é:

• DS8K

• Flash

• NVMe disfarçado de DASD

👉 Para o z/OS, continua sendo um 3390, com:

• 📐 Trilhas

• 📊 Cylinders

• 🧮 Extents

Tamanhos clássicos

Tipo	Cylinders
3390-1	1.113
3390-3	3.339
3390-9	10.017
3390-27	32.760
EAV	milhões 😈

🧠 Easter Egg:

Mesmo em storage 100% flash, o z/OS ainda “pensa” em trilhas.
Legacy não morre, evolui.

---

👀 Por que monitorar DASD, Padawan?

Porque disco cheio não avisa com carinho.
Ele derruba job, trava aplicação e chama gerente.

Riscos clássicos

• 🚨 Volume acima de 85%

• 🚨 Fragmentação absurda

• 🚨 Catálogo estourado

• 🚨 Extents demais por dataset

• 🚨 Sorts falhando sem espaço temporário

---

🛠️ Ferramentas nativas (sem gastar um centavo)

📟 SDSF

Seu sabre de luz inicial.

Comandos úteis:

DA

ou

/D U,DASD,ONLINE

Você vê:

• Volume

• Device Type (3390)

• Online/Offline

• Uso geral

---

🧾 IDCAMS – O velho sábio

  LISTCAT LEVEL(SYS1) ALL

Ou para volumes:

  LISTCAT VOLUME(VOL001)

📌 Mostra:

• Quantos datasets

• Extents

• Fragmentação

• Catálogo

🧠 Easter Egg:

LISTCAT mal interpretado já causou pânico desnecessário em muito CPD.

---

🧪 DFSMS – O cérebro invisível

Se você usa:

• SMS

• Storage Groups

• Management Classes

Então o monitoramento precisa olhar:

• Storage Group cheio

• Pool desbalanceado

• Volumes quentes vs frios

Comandos:

D SMS,SG
D SMS,VOL

---

🧙‍♂️ Ferramentas corporativas (o lado premium da Força)

• IBM Tivoli / OMEGAMON

• BMC MainView

• Broadcom SYSVIEW

Essas ferramentas:

• Alertam antes do caos

• Criam gráficos bonitos

• Salvam operadores de madrugadas ruins ☕😵‍💫

---

📐 Métricas que todo Padawan deve decorar

🔢 Uso de volume

• 🟢 Até 70% → zen

• 🟡 70–85% → atenção

• 🔴 > 85% → reunião marcada

🧩 Fragmentação

• Muitos extents = performance ruim

• VSAM sofre mais que sequential

🧮 Extents

• Dataset com 200+ extents é pedido de REORG

• Antigamente: limite era dor e sofrimento

---

🧪 Exemplo real (história de guerra)

“O batch sempre rodou… até hoje.”

Motivo?

• Volume temporário (SORTWK) com 92%

• Job falha com:

IEC070I 112-112

Solução?

• Monitoramento

• Alocação dinâmica

• Limpeza automática

📌 Moral: disco cheio não falha… ele se vinga.

---

🧠 Curiosidades & Fofoquices de CPD

• 🔍 Muitos ambientes ainda usam um único volume SYSRES

• 🧓 Dataset criado em 1998 ainda rodando em produção

• 😅 Volume “temporário” com dados críticos

• 📦 Flash moderno, mas pensado como 3390-3

---

🧭 Dicas Bellacosa Mainframe™️

✔️ Nunca confie em volume acima de 80%
✔️ Monitore tendência, não só foto do momento
✔️ Volume “barato” é o que causa outage caro
✔️ Documente storage group (ninguém faz, todo mundo sofre)
✔️ Ensine o Padawan antes que ele vire Operador às 3h da manhã

---

🧩 Encerrando…

Monitorar DASD no mainframe não é só técnica —
é filosofia, história viva e respeito à máquina.

💬 “No mainframe, disco não acaba… ele avisa.
O problema é quando ninguém está ouvindo.”

 

Bellacosa Mainframe apresenta IBM Mainframe DB2 Runstats

🔷 RUNSTATS no DB2: Mantendo Estatísticas Sempre Frescas

No DB2 para IBM z/OS, RUNSTATS é a ferramenta que mantém o otimizador de consultas informado sobre os dados. Sem estatísticas precisas, o DB2 não consegue criar planos de execução eficientes, e suas queries podem ficar lentas ou pesadas.

---

🕰️ História e Origem

• Nos anos 80, com bancos de dados relacionais massivos da IBM, surgiu a necessidade de coletar informações sobre o volume e distribuição dos dados.

• O DB2 precisava de uma forma de “aprender” sobre tabelas e índices:

  • Quantas linhas existem

  • Quantas páginas são ocupadas

  • Distribuição dos valores em colunas

• Assim nasceu o RUNSTATS, permitindo que o otimizador de consultas escolha o melhor caminho de acesso.

Pense no RUNSTATS como alimentar o cérebro do DB2 para que ele saiba onde estão os dados e como acessá-los mais rápido.

---

⚙️ O que o RUNSTATS faz?

O RUNSTATS coleta estatísticas sobre tabelas e índices, incluindo:

1. Número de linhas

2. Número de páginas (clusters e extent)

3. Distribuição de valores em colunas (histogramas)

4. Número de valores distintos

5. Estatísticas de índice

Essas informações são usadas pelo otimizador DB2 para criar o plano de execução mais eficiente para SELECTs, JOINs e outras operações.

---

🔹 Sintaxe básica

RUNSTATS TABLESPACE nome_tabela
  TABLE(nome_tabela) AND INDEXES ALL;

• TABLE(nome_tabela) → a tabela alvo

• INDEXES ALL → coleta estatísticas de todos os índices da tabela

• Pode ser executado em batch ou online, dependendo da criticalidade

---

🔹 Opções comuns

• ON ALL COLUMNS → coleta histograma de todas as colunas

• ON COLUMNS (col1, col2) → coleta histograma apenas de colunas importantes

• WITH DISTRIBUTION ON → útil para colunas usadas em joins ou WHERE

---

💡 Dicas Bellacosa

1. Rodar periodicamente → especialmente depois de grandes INSERTs/UPDATEs/DELETEs

2. Priorizar colunas usadas em WHERE/JOIN → reduz custo de coleta de estatísticas

3. Evite RUNSTATS durante pico de produção → pode causar I/O extra

4. Use COPY + RUNSTATS em DB2 online → mantém performance sem travar aplicações

5. Sempre verifique os planos de execução → o RUNSTATS influencia diretamente o EXPLAIN PLAN.

---

🔍 Curiosidades e Easter Eggs

• O RUNSTATS não altera dados, apenas coleta informações.

• Alguns DBAs brincam que “RUNSTATS é como fazer checkup anual no seu banco de dados” — sem ele, você dirige no escuro.

• Se você fizer uma reorganização (REORG) e não rodar RUNSTATS, DB2 pode subestimar ou superestimar linhas → queries lentas.

---

📈 Impacto na Performance

• Consultas mais rápidas → otimizador tem informações precisas

• JOINs e filtros eficientes → DB2 escolhe índices corretos

• Sem RUNSTATS → DB2 pode fazer table scan em vez de index scan, desperdiçando CPU e I/O

• Em ambientes grandes (milhões de linhas), RUNSTATS planejado e incremental é crucial

---

🧪 Exemplo prático

Suponha que você tenha a tabela ORDERS no DB2 z/OS:

RUNSTATS TABLESPACE ORDSPACE
  TABLE(ORDERS)
  ON ALL COLUMNS
  AND INDEXES ALL;

• DB2 coleta estatísticas de todas as colunas da tabela e de todos os índices.

• Agora, quando você rodar:

SELECT CUSTOMERID, COUNT(*)
FROM ORDERS
WHERE ORDERDATE BETWEEN '2025-01-01' AND '2025-12-31'
GROUP BY CUSTOMERID;

• O otimizador usará estatísticas precisas para escolher o melhor índice e evitar full table scan.

---

🔑 Resumo Bellacosa

Conceito	Detalhe
O que é	Comando para coletar estatísticas sobre tabelas e índices
Sintaxe	RUNSTATS TABLESPACE ... TABLE(...) AND INDEXES ALL
Quando usar	Após grandes mudanças nos dados, ou periodicamente
Impacto	Melhora planos de execução e performance de queries
Dicas Bellacosa	Priorize colunas usadas em WHERE/JOIN, evite horários de pico, combine com REORG

---

💡 Easter Egg:

Mesmo que você tenha todos os índices perfeitos, DB2 sem RUNSTATS é como ter mapas sem GPS — o otimizador pode escolher caminhos ruins e atrasar seu batch.

 

Bellacosa Mainframe apresenta a batalha dos terços espanhois versus o samurais do periodo sengoku

⚔️ Quando o Mundo Colidiu: Terços Espanhóis vs Samurais (1582)

Uma lição de sistemas, disciplina e cultura — muito antes do mainframe existir

Se você acha que globalização começou com a internet, APIs ou cloud híbrida, sinto informar: em 1582 o mundo já rodava integrado, só que em modo batch marítimo, com latência de meses e documentação escrita à pena.

E foi nesse cenário que aconteceu algo que parece roteiro de anime histórico:
👉 soldados dos Terços espanhóis enfrentando guerreiros samurais no Japão feudal.

Não é lenda. Não é fanfic. É história.

---

🌍 O mundo antes do “isolamento japonês”

O Japão do século XVI estava longe de ser um sistema fechado. Durante o Período Sengoku, o país vivia guerras internas constantes, com senhores feudais (daimyōs) disputando poder como se fossem LPARs concorrentes pelo mesmo hardware.

Enquanto isso:

• Portugueses já haviam chegado ao Japão (1543)

• Jesuítas circulavam livremente

• Armas de fogo europeias eram fabricadas localmente

• Espanhóis dominavam as Filipinas

Ou seja: o Japão estava conectado ao mundo, testando novas “features” militares.

---

🛡️ Terços Espanhóis: o sistema mais estável da época

Os Terços eram a elite militar da Europa. Eles dominaram campos de batalha por mais de um século graças a algo simples e poderoso:

👉 integração de componentes.

• Piqueiros protegiam arcabuzeiros

• Arcabuzeiros davam suporte de fogo

• Disciplina rígida

• Cadeia de comando clara

• Treinamento contínuo

No mundo mainframe?

Os Terços eram um Sysplex humano: cada unidade falhava pouco, mas o conjunto era quase imbatível.

Eles não dependiam de heróis individuais.
Dependiam do processo.

---

⚔️ Samurais: excelência individual e adaptação rápida

O samurai real — não o romantizado — era um profissional da guerra:

• Mestre em katana, arco e lança

• Usuário experiente de armas de fogo (tanegashima)

• Treinado desde jovem

• Guiado por códigos de honra, mas também por pragmatismo

O Japão adotou armas de fogo mais rápido que muitos países europeus.
Sim, isso quebra vários mitos de anime.

No paralelo tecnológico:

O samurai era o engenheiro sênior raiz: domina tudo, resolve no braço, mas brilha mesmo quando bem integrado ao time.

---

💥 O confronto de 1582: menos Hollywood, mais realidade

O encontro entre Terços (ou soldados ibéricos ligados às Filipinas) e samurais ocorreu em um contexto de tensões locais, missões diplomáticas e confrontos armados pontuais.

Não foi uma batalha campal épica.
Foi um choque real de doutrinas militares.

Relatos da época mostram:

• Europeus impressionados com a ferocidade e técnica japonesa

• Japoneses atentos à eficiência das formações europeias

• Ambos entendendo que o inimigo não era “atrasado”

Resultado?
👉 Aprendizado mútuo, não aniquilação.

---

🧠 O que esse episódio ensinou ao mundo

Esse encontro ajudou a moldar decisões importantes:

• O Japão aperfeiçoou o uso de armas de fogo

• A disciplina coletiva ganhou mais valor

• Mais tarde, o xogunato Tokugawa restringiria armas não por ignorância, mas por controle social

Ou seja:

Às vezes você não elimina a tecnologia — você a governa.

Soa familiar, mainframer?

---

🥚 Easter eggs históricos (porque todo bom sistema tem)

• Samurais usavam arcabuzes em larga escala

• O Japão produzia armas com qualidade europeia

• Terços só perderam protagonismo no século XVII

• Animes como Drifters e Samurai Champloo exploram esse choque cultural

• Parece isekai? Mas é documentação histórica

---

🧩 A lição final (para quem vive entre COBOL e anime)

O confronto entre Terços e samurais deixa um recado claro:

O futuro não pertence ao mais forte, nem ao mais honrado.
Pertence a quem integra tradição com inovação.

No nosso mundo:

• COBOL + APIs

• Mainframe + Cloud

• Cultura antiga + tecnologia nova

Exatamente como em 1582.

---

☕ Comentário final estilo El Jefe

Enquanto muita gente ainda discute se o mainframe “vai acabar”, vale lembrar:
os sistemas que sobrevivem são aqueles que se adaptam sem perder identidade.

Os Terços caíram.
Os samurais mudaram.
O Japão se transformou.

E o mainframe?
Segue firme, silencioso, processando o mundo.

END-OF-JOB
RC=0

🛡️ SMP/E e Segurança: Quando manutenção vira proteção (ou vulnerabilidade)

 

Bellacosa Mainframe apresenta IBM SMP/E

🛡️ SMP/E e Segurança

Quando manutenção vira proteção (ou vulnerabilidade)

“No mainframe, segurança não começa no RACF.
Começa no SMP/E.”

---

🧠 Por que SMP/E é parte da segurança?

SMP/E controla o que entra no sistema operacional.

Quem controla:

• Código

• Versões

• Dependências

• Histórico

…controla superfície de ataque.

👉 Um PTF não aplicado é uma brecha.
👉 Um PTF mal aplicado é um risco maior ainda.

---

🔓 O maior mito

❌ “Segurança é só RACF, ACF2 ou TopSecret.”

✅ Verdade:

• RACF protege acesso

• SMP/E protege integridade do código

📌 Sem SMP/E bem gerenciado:

• Módulos vulneráveis continuam rodando

• Correções críticas não entram

• Auditoria reprova

---

🚨 PTF de segurança: prioridade máxima

A IBM libera PTFs que:

• Corrigem falhas exploráveis

• Atendem compliance (PCI, SOX, LGPD)

• Eliminam vetores de ataque

Esses PTFs geralmente vêm com:

• ++HOLD(SECURITY)

• Texto explicativo detalhado

👉 Não aplicar é decisão de risco.

---

🔍 ++HOLD(SECURITY): leia com atenção

O que significa?

++HOLD(SECURITY)

Indica:

• Impacto direto em segurança

• Mudança de comportamento

• Possível quebra de compatibilidade

📌 Normalmente envolve:

• Autorização

• Criptografia

• Controle de acesso

• SMF / auditoria

---

Dica Bellacosa

Ignore um HOLD de segurança e o auditor vai encontrar.

---

🔥 ++ERROR e segurança

Um ++ERROR em PTF de segurança é crítico:

• Pode corrigir parcialmente a falha

• Pode introduzir outro risco

• Pode exigir mitigação adicional

👉 Decisão nunca é automática.

📌 Boas ações:

• Ler APAR

• Avaliar CVE

• Consultar IBM

• Planejar superseding PTF

---

🔐 Controle de acesso ao SMP/E

Quem deve ter acesso?

• System Programmers

• Pouquíssimas pessoas

• Com segregação clara

📌 Proteger:

• CSI datasets

• SMP/E libraries

• JCL de manutenção

---

Boas práticas de RACF

• UACC=NONE

• Acesso mínimo necessário

• LOG de alterações

• Perfis específicos para SMP/E

👉 Quem mexe no SMP/E mexe no sistema inteiro.

---

🧾 Auditoria e compliance

Auditores adoram perguntar:

• Quais PTFs estão aplicados?

• Quando?

• Por quem?

• Por quê?

👉 SMP/E responde tudo isso.

📌 CSI é prova documental.

---

🧪 APPLY CHECK como ferramenta de segurança

APPLY CHECK ajuda a:

• Identificar impacto

• Prever conflitos

• Avaliar risco antes da mudança

💡 Dica Bellacosa:

“APPLY CHECK é auditoria preventiva.”

---

🔄 Manutenção atrasada = risco ativo

• PTF antigo = CVE ativo

• Função obsoleta = ataque conhecido

• Versão desatualizada = não conformidade

👉 Segurança também é disciplina de manutenção.

---

🧠 Caso real (estilo Bellacosa)

Falha crítica corrigida por PTF
PTF não aplicado por medo de IPL
Exploração acontece
Auditor pergunta: “Por quê?”

📌 Resposta errada:

“Porque sempre funcionou assim.”

---

🎓 Como aprender SMP/E focado em segurança

• Ler PTFs de segurança

• Analisar HOLDS

• Estudar CVEs

• Participar de workshops

• Integrar SMP/E com gestão de risco

---

🧠 Curiosidades Bellacosa

• SMP/E já fazia secure supply chain antes do termo existir

• Código assinado é inútil se não for aplicado

• Auditor confia mais no CSI do que em planilha

---

🧾 Comentário final – SMP/E e Segurança

Segurança não é só impedir acesso.
É garantir que o código certo esteja rodando.

E isso…
👉 é trabalho do SMP/E.

🛡️💾🔥

 

Bellacosa Mainframe apresenta o churrasco no anime

🥩 Em Anime, qual é o “corte bovino” que sempre aparece?

(ou: quando a marmorização vira efeito especial)

ao estilo Bellacosa Mainframe

Se você já assistiu anime suficiente, sabe do que estou falando.
A cena é clássica:

• A carne chega

• A câmera faz close

• Ela brilha ✨

• Alguém engole seco

• Outro personagem diz: “Isso é caro…”

E você pensa:

“Que corte bovino é esse que só aparece em anime?!”

Vamos decodificar esse dataset carnívoro.

---

🐂 Spoiler rápido: não é UM corte só

Em anime, o que aparece não é exatamente um corte, mas uma combinação de três conceitos:

1. Tipo de boi

2. Corte específico

3. Contexto cultural

👉 Anime trabalha com atalhos visuais.
Assim como um dump indica desastre, marmorização extrema indica luxo.

---

⭐ WAGYU (和牛) – o “hardware premium”

Se a carne:

• Parece derreter

• Tem gordura desenhada como mapa astral

• Brilha mais que opening shōnen

👉 É Wagyu.

📌 Importante (Easter egg nº 1):
Wagyu não é corte, é o tipo do boi.

Nos animes, Wagyu simboliza:

• Recompensa

• Status

• Cena especial

• “Hoje a conta é minha”

🎌 Animes onde aparece (direto ou indireto):

• Shokugeki no Soma

• Yuru Camp

• Oishinbo

• Silver Spoon

---

🔥 KARUBI (カルビ) – o rei do yakiniku

Cena de:

• Amigos

• Churrasco japonês

• Grelha pequena

• Carne fatiada

👉 Karubi.

O que é:

• Costela / short rib

• Gordurosa

• Cortada fina

• Assa em segundos

💡 Karubi é o batch job confiável:

• Sempre aparece

• Nunca falha

• Todo mundo gosta

---

🍖 RIBURO-SU (リブロース) – o ribeye japonês

Quando o anime quer mostrar:

• Carne “séria”

• Corte espesso

• Cozinheiro respeitado

👉 Riburo-su (ribeye).

📌 Marmorização bonita, mas sem exagero visual de Wagyu A5.

---

👅 GYŪTAN (牛タン) – a língua “de especialista”

Aparece quando:

• O personagem manja muito

• A cena é urbana

• O restaurante é tradicional

Gyūtan é:

• Técnica

• Regional (Sendai)

• Para quem entende

👉 Tipo aquele utilitário que só veterano sabe usar.

---

🥚 Easter eggs que passam batido

🥚 Quanto mais brilho, menos realista.
🥚 Gordura em anime é status social, não defeito.
🥚 Personagem pobre comendo Wagyu = episódio emocional garantido.
🥚 Anime raramente fala o nome do corte — a imagem resolve.

---

☕ Tradução para Mainframers

• Wagyu = hardware topo de linha

• Karubi = sistema confiável

• Ribeye = performance equilibrada

• Gyūtan = feature para iniciados

Anime não quer te ensinar açougue.
Quer te ensinar emoção via comida.

---

🧠 Comentário Bellacosa Mainframe

Assim como no data center:

• Você não usa o equipamento mais caro todo dia

• Mas quando usa… marca o momento

A carne em anime não é só carne.
É narrativa, afeto, recompensa e cultura.

E se depois disso você ficou com fome…
👉 missão cumprida.

---

JOB FINALIZADO
RC=0
SYSOUT: “Abrir aplicativo de delivery imediatamente.” 🍖🔥

📂 FILE MANAGER BASE (FMB) – IBM

 

Bellacosa Mainframe apresenta o IBM Mainframe ISPF File Manager

📂 FILE MANAGER BASE (FMB) – IBM

ao estilo Bellacosa Mainframe

Quem vive o dia a dia do mainframe sabe: entender layout de arquivo não é detalhe, é sobrevivência. E quando a pergunta clássica aparece — “em que posição começa e termina esse campo?” — eu não penso duas vezes: FMB – File Manager Base, da IBM.

Inserido de forma elegante no menu do TSO/ISPF, o FMB é aquele utilitário que não faz barulho, não aparece em buzzwords modernas, mas resolve problemas reais há décadas.

---

IBM Mainframe menu ISPFfm

🧠 Para que eu uso o FMB no dia a dia

Sempre que preciso consultar o layout de um arquivo sequencial, VSAM ou até datasets mais “exóticos”, recorro ao caminho:

FMB → Utilities → Copybook

Essa opção é ouro.

Ela apresenta, de forma clara e objetiva:

• Nome dos campos

• Tipo/formato (CHAR, PACKED, BINARY, etc.)

• Tamanho do campo

• Posição inicial

• Posição final

Ou seja: exatamente o que você precisa quando está conferindo um arquivo gerado por batch, validando uma carga, depurando um problema de produção ou simplesmente desconfiando que “isso aqui não bate”.

📌 Para quem já sofreu lendo copybook manualmente, contando coluna por coluna no papel (ou no Notepad 😅), isso é quase terapêutico.

---

IBM Mainframe z/OS File Manager 

🗂️ Valor prático real (não é marketing)

O FMB facilita muito:

• Conferência de conteúdo de arquivos sequenciais

• Validação de layouts em processos batch

• Análise rápida sem precisar abrir compilador ou rodar job

• Redução de erro humano (adeus contagem manual de colunas)

É um utilitário que economiza tempo, evita erro e aumenta confiança.

---

IBM Mainframe z/os ISPF File Manager Utilities13

🕰️ Data de origem (contexto histórico)

• 📅 Origem teórica: início dos anos 1990

• 🏢 Desenvolvido pela IBM como parte do conjunto de ferramentas de produtividade para MVS/TSO

• Evoluiu junto com:

  • ISPF

  • Ambientes z/OS

  • Necessidade crescente de análise de dados em produção

Ele nasce numa época em que:

“visualizar dados com contexto” era uma dor real e frequente.

---

IBM Mainframe print layout copy book

🚀 Data de lançamento (referência)

• 📆 Primeiras versões comerciais: por volta de 1992–1993

• Integrado posteriormente ao IBM File Manager for z/OS

• O File Manager Base (FMB) funciona como o “coração” da solução

---

💡 Dicas de uso (estilo Bellacosa)

• 🔎 Use o Copybook Viewer antes de qualquer alteração em programa batch

• 🧪 Compare layout esperado × arquivo real antes de acusar “erro no sistema”

• 📐 Confirme campos PACKED e BINARY — muitos problemas estão ali

• 🧘‍♂️ Em produção crítica, olhar o arquivo primeiro salva deploys desnecessários

---

🥚 Curiosidades & Easter Eggs

• O FMB mostra posições 1-based, como o COBOL — nada de index zero confuso

• Ele respeita o copybook original, inclusive REDEFINES

• Dá para encontrar erros de layout sem executar uma linha de código

• Muitos profissionais usam há anos e não sabem metade do que ele oferece

---

🤫 Fofoquices de mainframe

• Tem muita equipe que tem o FMB instalado e não usa

• Já vi debug de horas ser resolvido em 5 minutos de FMB

• Em várias empresas, só “os mais antigos” sabem navegar bem nele

• É comum ouvir: “ah, isso aí é coisa de velho” — até o dia que salva a madrugada 😄

---

📌 Exemplo prático

Imagine um arquivo de 300 bytes com um campo VALOR-TOTAL:

• Esperado: posição 121 a 135 (PACKED)

• No FMB: aparece como 121–134
  👉 Pronto, achou o erro de 1 byte que estava quebrando tudo.

Sem FMB? Boa sorte contando na unha.

---

💬 Comentário final (bem Bellacosa)

O File Manager Base não é moderno, não é “cloud native”, não aparece em slide bonito.
Mas é eficiente, confiável e maduro, exatamente como o mainframe gosta de ser.

Ferramenta simples, silenciosa e extremamente poderosa.
Para mim, um utilitário de altíssimo valor.

Quem conhece, usa.
Quem usa, confia.
Quem confia… dorme melhor depois do batch. 😎

SMP/E: Laboratório SMP/E: Workshop prático passo a passo - Parte 5

 

Bellacosa Mainframe apresemta IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 5 – Laboratório SMP/E: Workshop prático passo a passo

“SMP/E só vira conhecimento quando o JCL roda e você entende o RC.”

---

🎯 Objetivo do Laboratório

Simular um cenário real de manutenção z/OS, cobrindo:

• RECEIVE de um PTF

• APPLY CHECK

• APPLY real

• ACCEPT

• Análise de HOLD e ERROR

• Dicas de troubleshooting

📌 Cenário típico de produção.

---

🧪 Pré-requisitos do ambiente

Antes de começar, verifique:

• CSI configurado e acessível

• GLOBAL / TARGET / DLIB definidos

• FMID já instalado (FUNCTION)

• PTF disponível (Shopz / dataset)

💡 Dica Bellacosa:

“Se o FMID não existe, nada anda.”

---

📦 Cenário do exercício

• Produto: JES2

• FMID: HJES770

• PTF fictício: UJ12345

• Ambiente: TESTE (nunca produção)

---

🧩 Passo 1 – RECEIVE do PTF

JCL (exemplo didático)

SET BDY(GLOBAL).
RECEIVE SYSMODS.

O que validar no output:

• RC=0

• SYSMOD registrado no CSI

• Nenhuma mensagem de erro

📌 Se falhar aqui, pare.

---

🧪 Passo 2 – APPLY CHECK (obrigatório)

SET BDY(TARGET).
APPLY CHECK.

Resultado esperado:

• Lista de pré-requisitos

• Verificação de ++VER

• HOLD identificado:

++HOLD(SYSTEM) REQUIRES IPL

💡 Dica Bellacosa:

“CHECK é ensaio geral. Quem ignora paga ingresso caro.”

---

🛠️ Passo 3 – Análise do HOLD

Perguntas que o sysprog deve fazer:

• Precisa IPL?

• Pode ser feito agora?

• Existe janela?

📌 Decisão:
👉 Prosseguir com APPLY em teste.

---

🔧 Passo 4 – APPLY real

SET BDY(TARGET).
APPLY.

O que observar:

• RC=0 ou RC=4 (com HOLD)

• Módulos copiados para TARGET

• Mensagens de sucesso

📌 Aqui o sistema muda.

---

🚨 Situação alternativa – ++ERROR encontrado

Se aparecer:

++ERROR

Ação correta:

• Ler APAR

• Avaliar impacto

• Decidir: aplicar ou aguardar superseding PTF

👉 Nunca aplique no automático.

---

📦 Passo 5 – Testes funcionais

Antes do ACCEPT:

• Subir JES2

• Validar spool

• Ver logs

• Monitorar comportamento

💡 Dica Bellacosa:

“Teste em TARGET antes de casar com o DLIB.”

---

🧱 Passo 6 – ACCEPT (baseline)

SET BDY(DLIB).
ACCEPT.

Resultado:

• DLIB atualizado

• Histórico registrado

• Sistema preparado para futuras manutenções

📌 Agora virou padrão.

---

🔄 E se der problema? (RESTORE)

SET BDY(TARGET).
RESTORE.

⚠️ Atenção:

• RESTORE não é trivial

• Nem sempre volta tudo

• Documentação é vital

---

🧠 Erros comuns (vida real)

❌ ACCEPT sem teste
❌ APPLY direto em produção
❌ Ignorar HOLD
❌ Não ler APAR
❌ CSI compartilhado sem controle

👉 Todos já caíram nisso. Os bons aprendem rápido.

---

🎓 Checklist Bellacosa de Produção

✔ APPLY CHECK sempre
✔ Leia HOLDS e ERRORS
✔ Teste antes de ACCEPT
✔ Documente SYSMODs
✔ Nunca confie cegamente

---

🧠 Curiosidades finais

• APPLY é técnico

• ACCEPT é político

• CSI é sagrado

• SMP/E não esquece nada

---

🧾 Encerramento da Série

Quem domina SMP/E domina o z/OS.
Quem ignora SMP/E trabalha sob risco.

Esta série te leva:

• De iniciante

• A consciente

• A profissional de SMP/E

💾🔥