Bellacosa Mainframe apresenta um review smp/e 

🧠 SMP/E for z/OS – Uma Revisão

Revisão definitiva (com cheiro de fita, CSI alinhado e café frio ☕)

Se você acha que SMP/E é complicado, relaxa: ele só é honesto.
Honesto no sentido de que reflete exatamente a complexidade do z/OS — sem abstrações mágicas, sem “next, next, finish”.

SMP/E não é só uma ferramenta.
É memória histórica, controle cirúrgico e disciplina operacional.

Vamos revisar The Network do SMP/E for z/OS Workshop no melhor estilo Bellacosa Mainframe: com contexto, visão sistêmica e alguns easter eggs que só quem já brigou com um CSI entende 😉

---

🏛️ Antes do SMP/E: quando tudo era fita, suor e coragem

Nos anos 70, o mundo era simples — e perigoso.

• O sistema vinha em DLIB tapes

• O SYSGEN tinha Stage 1 e Stage 2

• O programador montava tudo na unha

• E manutenção?
  👉 Manual. Muito manual.

Resultado?

• Instabilidade

• Erros humanos

• Sistemas que “funcionavam… até não funcionarem”

💾 Easter egg #1:

Quem nunca teve medo de rodar um IEP_COPY no volume errado… não viveu essa época.

---

🧬 A chegada do SMP (e depois SMP/E)

Nos anos 80, a IBM fez algo revolucionário:
automatizou o que não podia mais depender da memória humana.

Nascia o SMP, que depois evoluiu para SMP/E (System Modification Program / Extended).

Agora o sistema tinha:

• Global Zone → cérebro

• Target Zone → sistema em execução

• Distribution Zone (DLIB) → fonte da verdade

Tudo documentado.
Tudo rastreável.
Tudo auditável.

---

🧠 O conceito-chave: CSI (Consolidated Software Inventory)

O CSI é o coração do SMP/E.

Ele responde perguntas críticas como:

• O que está instalado?

• Onde está?

• Como foi construído?

• Quem depende de quem?

Zonas:

• Global Zone
  Índice mestre + opções de controle

• Target Zone
  Reflete o que está rodando

• Distribution Zone
  Reflete o que foi entregue

📌 Regra de ouro:

SMP/E não adivinha. Ele só faz exatamente o que o CSI diz.

---

📦 Tudo em SMP/E é SYSMOD

Não existe exceção.
Se entrou no SMP/E, virou SYSMOD.

Tipos clássicos:

• FUNCTION → produto novo

• PTF → serviço preventivo

• APAR → correção corretiva

• USERMOD → customização local (o famoso “aqui a gente fez diferente”)

Todos eles têm:

• MCS (++ statements) → inteligência

• Modification Text → o código

💾 Easter egg #2:

Viu ++HOLD? Pare. Respire. Leia o PSP antes de qualquer APPLY.

---

🔁 O fluxo eterno do SMP/E

O ciclo que nunca muda:

1. RECEIVE

   • Entra no SMPPTS

   • Atualiza Global Zone

   • Nada muda no sistema ainda

2. APPLY

   • Atualiza Target Libraries

   • Sistema pode ser testado

   • Ainda reversível

3. RESTORE

   • Volta ao último nível aceito

   • Usa DLIB como fonte

   • Seu botão de “desfazer”

4. ACCEPT

   • Atualiza DLIB

   • Ponto sem volta

   • Agora é história oficial

💣 Easter egg #3:

ACCEPT em produção sem teste é um pedido formal de incidente grave.

---

🌐 The Network: quando o SMP/E ganhou internet

Chegamos ao ponto alto do módulo: entrega eletrônica.

Com Shopz / JustShopz, tudo mudou:

• Menos fita

• Mais automação

• Menos transporte físico

• Mais rastreabilidade

Opções modernas:

• ServerPac → replace completo

• CBPDO → produto ou serviço incremental

• Internet Delivery

  • RECEIVE FROMNETWORK

  • RECEIVE FROMNTS

  • RECEIVE ORDER

📦 Tudo chegando direto no HFS/zFS, validado por hash, protegido por certificado X.509.

🔐 Easter egg #4:

Se o RACDCERT não reconhece seu certificado, o SMP/E também não vai.

---

🧾 Shopz, pedidos e abas que importam

Depois de submeter o pedido:

• Ele aparece como Open

• Depois Submitted ou Order Center

• E você acompanha em:
  👉 In Progress

Quando muda para Download…
🎉 chegou a hora.

📬 E-mail da IBM
🔗 Link direto
⏳ 14 dias de validade

---

🧠 SMP/E moderno não é só manutenção

Hoje o SMP/E também:

• Ordena PTF automaticamente

• Agenda serviço

• Controla origem dos fixes (SourceID)

• Centraliza histórico

Tudo isso com:

• RECEIVE ORDER

• ORDER Management (Option 7)

• Java ou ICSF

• FTPS + Hash SHA-1

---

🧪 Planejamento: onde bons sysprogs se diferenciam

Antes de qualquer INSTALL:

• Clone do sistema

• Program Directory

• PSP Buckets

• Espaço em Target, DLIB e SMP/E datasets

• IVP depois

• Testes reais

• Migração controlada

🧠 Easter egg final:

O melhor sysprog não é o que instala rápido.
É o que dorme tranquilo depois do IPL.

---

🏁 Conclusão

SMP/E não é moda.
Não é hype.
Não é simples.

Ele é engenharia de software em estado puro, aplicada a um dos ambientes mais críticos do planeta.

E se você chegou até aqui entendendo tudo isso…
👉 Parabéns: você fala fluentemente Mainframe.

 

Bellacosa Mainframe apresenta o REXX

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional  

Se você já salvou produção com um exec improvisado, já rasgou SDSF via ADDRESS, ou já ouviu

“isso dá pra automatizar em REXX, né?”
então puxa a cadeira.
Aqui é REXX técnico, sem verniz didático e com cheiro de madrugada.

---

🕰️ Histórico & Origem — por que o REXX virou arma de produção

O REXX (Restructured Extended Executor) nasce na IBM nos anos 80 com uma missão clara:

• Substituir JCL “verboso”

• Padronizar scripts

• Criar uma linguagem legível, extensível e integrada ao sistema

Ele não foi feito para ser “bonito”.
Foi feito para controlar ambiente.

☕ Verdade histórica:

REXX não é linguagem de apoio — é linguagem de governo operacional.

---

🧠 Conceito de Ambiente de Processamento

REXX não executa no vácuo.
Ele sempre roda dentro de um ambiente:

• TSO/E

• Batch

• SDSF

• ISPF

• CICS (indiretamente)

• Programas externos

Cada ambiente define:

• Comandos válidos

• RC interpretado

• Recursos disponíveis

• Permissões RACF

🔥 Easter egg:
O mesmo EXEC pode funcionar em TSO e falhar em Batch sem mudar uma linha.

---

🧩 Fundamentos da Linguagem — simples na superfície, profunda no núcleo

Sintaxe & Elementos

• Tipagem dinâmica

• Strings como cidadão de primeira classe

• Sem declaração obrigatória

• Case-insensitive (armadilha clássica)

📌 Exemplo:

parse upper arg parm1 parm2
if parm1 = '' then exit 8

☕ Comentário ácido:
REXX perdoa erro demais — e isso cobra seu preço em produção.

---

🏗️ Estrutura de um Programa REXX

Todo EXEC sério tem:

1. Identificação

2. Validação de ambiente

3. Tratamento de RC

4. Controle de erro

5. Cleanup

📌 Exemplo base:

/* REXX */
signal on error
signal on failure
signal on syntax

address tso
"ALLOC FI(IN) DA('DATASET') SHR"
...
exit 0

🔥 Veterano sabe:
EXEC sem SIGNAL ON é convite ao caos.

---

🧮 Estrutura de Dados — tabelas na memória

REXX não tem array clássico.
Tem stem variables.

tab.1 = 'A'
tab.2 = 'B'
tab.0 = 2

☕ Curiosidade:
Stem mal controlado vira memory leak conceitual.

---

📂 Acesso a Arquivos & Geração de Relatórios

• ALLOC / FREE

• EXECIO DISKR / DISKW

• Geração de relatórios spoolados

• Integração com SORT

📌 Exemplo:

"EXECIO * DISKR IN (STEM L.)"
do i=1 to L.0
  say L.i
end

🔥 Easter egg:
EXECIO ignora erro… até você checar o RC.

---

🔃 Classificação & Manipulação de Dados

• SORT via IDCAMS

• SORT via ICETOOL

• Manipulação em memória (lento)

• Pipeline híbrido REXX + SORT

☕ Regra de produção:

Se precisa ordenar muito, não é REXX — é SORT.

---

🗂️ Acesso a Diretório de PDS

REXX + ISPF services:

• LMDINIT

• LMMLIST

• LMCLOSE

📌 Exemplo:

address ispexec
"LMINIT DATAID(DID) DATASET('MY.PDS')"
"LMMLIST DATAID(DID) OPTION(LIST)"

🔥 Veterano:
ISPF services dão poder… e risco.

---

🧑‍💻 Interatividade com Usuário (TSO)

• Pseudo-conversational

• Command-level

• SAY / PULL

• Mensagens controladas

☕ Fofoquice:
Interface feia, mas resolve crise em minutos.

---

🧪 Modos de Execução REXX

🟢 REXX Linha de Comando (Online)

• Interativo

• Debug rápido

• Dependente de perfil

🟡 REXX Batch Script (Interpretado)

• Executa via IKJEFT01

• Dependente de ambiente

• Mais flexível

🔴 REXX Batch Compilado

• Performance superior

• RC previsível

• Menos tolerante a erro

• Exige processo de build

🔥 Script vs Compilado:

Interpretado é agilidade.
Compilado é confiabilidade.

---

🔐 REXX + RACF

REXX não ignora segurança:

• Herda permissões do usuário

• Pode consultar via RACROUTE (indireto)

• Controla acesso via classes

☕ Verdade dura:
EXEC com SPECIAL é bomba com pavio curto.

---

🗄️ REXX + DB2

• DSNREXX

• SQL dinâmico

• RC + SQLCODE + SQLSTATE

• Automação de consultas e relatórios

📌 Exemplo:

ADDRESS DSNREXX
"EXECSQL SELECT COUNT(*) INTO :CNT FROM SYSIBM.SYSTABLES"

🔥 Easter egg:
SQLCODE ignorado vira incidente invisível.

---

🔀 ADDRESS — o coração da integração

ADDRESS muda o destino dos comandos:

• TSO

• ISPEXEC

• SDSF

• CONSOLE

• DSNREXX

☕🔥 Regra sagrada:

Quem domina ADDRESS domina o sistema.

---

🔢 Return Code (RC) — o idioma da produção

• RC ≠ erro sempre

• RC precisa ser interpretado

• Padronização é vital

if rc > 4 then exit rc

🔥 Veterano:
RC não tratado é mentira operacional.

---

📘 Programa do Curso — visão hardcore

Estrutura Geral / Labs

• Ambiente restritivo

• Casos reais

• Incidentes simulados

Instruções REXX

• IF, DO, SELECT

• SIGNAL, EXIT

• PARSE

Funções Internas / Sub-rotinas

• Modularização

• Reuso

• Controle de escopo

Comandos REXX

• SAY, PULL, TRACE

• QUEUE / PULL

• EXECIO

Funções TSO / CONSOLE

• WTO

• MODIFY

• DUMP

• SDSF

INTERPRET (🔥 perigoso)

• Execução dinâmica

• Flexibilidade extrema

• Risco máximo

☕ Comentário ácido:

INTERPRET é poder absoluto — use sóbrio.

---

🥚 Easter Eggs & Fofoquices REXX

• Todo ambiente tem um EXEC “salvador”

• Sempre existe um REXX sem comentários rodando há anos

• O melhor REXX é o que não precisa ser explicado

• Debug começa com TRACE ?R

---

☕🔥 Conclusão — Manifesto El Jefe REXX

REXX não é:

• Script simples

• Linguagem de iniciante

• Alternativa ao COBOL

REXX é:

• Cola do z/OS

• Automação estratégica

• Ferramenta de sobrevivência em produção

☕🔥 Quem domina REXX,
não programa apenas —
orquestra o mainframe.

 

Bellacosa Mainframe explica o JSON

🔥☕ JSON: O “COBOL DOS DADOS MODERNOS”? — A Linguagem Invisível Que Dominou APIs, Nuvem e Até o Mainframe ☕🔥

“Enquanto muita gente ainda pensava em arquivos texto… o JSON já estava preparando o planeta para microserviços, APIs e integração global.”

---

🚀 Introdução — O Formato Que Conquistou o Mundo

Se existe algo que une JavaScript, Python, Java, Node.js, Kubernetes, APIs REST, Open Banking, cloud e até o z/OS… esse algo é o JSON.

Sim…

Aquele bloco aparentemente simples:

{
  "cliente": "BELLACOSA",
  "conta": 12345,
  "saldo": 9999.99
}

Hoje parece trivial.

Mas o impacto do JSON na computação foi monstruoso.

Ele virou:

• o idioma oficial das APIs,
• a “cola” da internet moderna,
• o padrão universal de troca de dados,
• e uma das maiores revoluções silenciosas da computação corporativa.

E o mais curioso?

O JSON nasceu de forma extremamente simples… quase como um “truque elegante” dentro do JavaScript.

---

🧠 Quem Criou o JSON?

O JSON foi criado por:

👨 Douglas Crockford

Programador, arquiteto de software e evangelista JavaScript.

---

📅 Data de Criação

O JSON começou a ganhar forma por volta de:

📌 2001

E foi oficialmente popularizado entre:

📌 2002–2005

---

🌍 O Problema Que o JSON Resolveu

Antes do JSON, integração era quase sempre baseada em:

• XML
• CSV
• Arquivos posicionais
• Protocolos binários
• EDI
• Mensagens proprietárias

O problema?

Tudo era:

• pesado,
• verboso,
• lento,
• difícil de ler,
• difícil de debugar.

Exemplo de XML:

<cliente>
   <nome>BELLACOSA</nome>
   <saldo>9999.99</saldo>
</cliente>

Agora compare com JSON:

{
   "nome": "BELLACOSA",
   "saldo": 9999.99
}

Menos ruído.
Mais legibilidade.
Mais velocidade.
Mais simplicidade.

E o mercado enlouqueceu.

---

⚡ O Grande Segredo do JSON

O JSON nasceu inspirado diretamente nos objetos JavaScript.

Na prática:

var cliente = {
   nome: "BELLACOSA",
   saldo: 9999.99
}

Douglas Crockford percebeu:

“E se isso virar um formato universal de troca de dados?”

E virou.

---

🔥 O JSON Explodiu Com as APIs REST

Quando APIs REST começaram a dominar o mercado…

o JSON virou praticamente obrigatório.

Porque:

• era leve,
• rápido,
• fácil de parsear,
• perfeito para internet,
• amigável para humanos.

Resultado?

O XML começou a perder espaço rapidamente.

---

☕ O Mainframe Não Ficou de Fora

Aqui começa a parte interessante para o mundo COBOL.

Muita gente achava:

“Mainframe nunca vai falar JSON.”

Erro histórico.

Hoje o z/OS conversa JSON o tempo inteiro:

• APIs REST
• z/OS Connect
• CICS Web Services
• MQ
• Kafka
• Open Banking
• Microsserviços
• Cloud híbrida

O JSON virou peça fundamental da modernização mainframe.

---

🧠 COBOL + JSON = O Casamento Corporativo Moderno

A IBM percebeu rapidamente:

Se o mainframe quisesse continuar reinando…
precisaria falar JSON nativamente.

E então vieram recursos modernos como:

📌 JSON PARSE

e

📌 JSON GENERATE

no Enterprise COBOL.

---

🚀 Exemplo COBOL Moderno Com JSON

Gerando JSON

IDENTIFICATION DIVISION.
PROGRAM-ID. GERJSON.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 CLIENTE.
   05 NOME      PIC X(20) VALUE 'BELLACOSA'.
   05 SALDO     PIC 9(5)V99 VALUE 99999.99.

01 JSON-SAIDA  PIC X(200).

PROCEDURE DIVISION.

JSON GENERATE JSON-SAIDA
   FROM CLIENTE

DISPLAY JSON-SAIDA.

STOP RUN.

Saída:

{"NOME":"BELLACOSA","SALDO":99999.99}

---

🔥 Parsing JSON no COBOL

Recebendo API REST

JSON PARSE JSON-ENTRADA
   INTO CLIENTE

Isso foi revolucionário no z/OS.

Porque eliminou:

• parsers manuais,
• tratamentos absurdos,
• lógica artesanal,
• conversões complexas.

---

🧠 O Que Tornou o JSON Tão Poderoso?

📌 1. Legibilidade Humana

Até operador consegue entender.

---

📌 2. Estrutura Hierárquica

Permite:

• objetos,
• listas,
• arrays,
• árvores complexas.

---

📌 3. Independência de Linguagem

Funciona em:

• COBOL
• Java
• Python
• Go
• Node.js
• Rust
• RPG
• PL/I

---

📌 4. Perfeito Para APIs

JSON praticamente virou:

“o TCP/IP da integração moderna.”

---

⚠️ Desvantagens do JSON

Nem tudo são flores.

---

❌ 1. Sem Tipagem Forte

JSON puro não define:

• decimal fixo,
• packed decimal,
• COMP-3,
• datas reais.

Isso gera problemas em integrações financeiras.

---

❌ 2. Overhead de Texto

JSON é texto.

Protocolos binários podem ser mais rápidos.

---

❌ 3. Segurança

Parsing inseguro pode causar:

• injection,
• payload malicioso,
• consumo excessivo de memória.

---

❌ 4. Precisão Numérica

Problema clássico:

• valores financeiros,
• arredondamentos,
• IEEE floating point.

O mainframe sofre muito menos disso graças ao decimal packed.

---

🔥 Curiosidades Históricas

☕ JSON NÃO É Linguagem

Apesar do nome:

JavaScript Object Notation

JSON NÃO é uma linguagem de programação.

É apenas um formato de dados.

---

☕ O JSON Virou Padrão Oficial

RFC oficial:

📌 RFC 8259

---

☕ XML Dominava Absolutamente

Antes do JSON:

• SOAP,
• WSDL,
• XML Schema,
• namespaces,
• tags gigantescas.

Parecia um ritual mágico corporativo.

JSON chegou como uma motosserra.

---

💣 Easter Egg Histórico

Douglas Crockford chegou a remover referências perigosas do JavaScript porque:

📌 JSON podia executar código involuntariamente

No começo muita gente fazia:

eval(json)

Isso virou um pesadelo de segurança.

Daí nasceram parsers seguros.

---

🚀 JSON no Mundo Mainframe Moderno

Hoje o JSON está em todo lugar no z/OS:

Tecnologia	Uso
z/OS Connect	APIs REST
CICS	Web Services
IMS	Integração moderna
MQ	Mensageria
Kafka	Streaming
Db2 REST	APIs corporativas
Open Banking	Payloads financeiros
Cloud híbrida	Microsserviços

---

🔥 O JSON Mudou o Papel do Programador COBOL

Antigamente:

• COBOL manipulava arquivos,
• VSAM,
• copybooks,
• EBCDIC.

Hoje o COBOL moderno:

• consome APIs,
• gera REST,
• fala HTTP,
• troca JSON,
• integra cloud,
• conversa com Kubernetes.

O programador COBOL virou:

engenheiro de integração corporativa.

---

☕ Comparação Filosófica: JSON vs Copybook COBOL

Curiosamente…

JSON lembra MUITO a ideia dos copybooks.

Veja:

Copybook

01 CLIENTE.
   05 NOME PIC X(20).
   05 SALDO PIC 9(5)V99.

JSON

{
   "NOME": "BELLACOSA",
   "SALDO": 99999.99
}

Ambos descrevem estrutura de dados.

A diferença?

O JSON atravessa internet, nuvem e APIs.

---

🧠 O Verdadeiro Motivo do Sucesso do JSON

Não foi tecnologia.

Foi simplicidade.

O JSON venceu porque:

• humanos entendem,
• programadores gostam,
• APIs adoram,
• clouds dependem,
• empresas inteiras padronizaram nele.

---

💣 Conclusão — O JSON Virou a “Nova Linguagem Universal”

O JSON não matou o COBOL.

Na verdade…

Ele ajudou o COBOL a sobreviver à era cloud.

Hoje o mainframe continua relevante porque aprendeu:

• REST,
• APIs,
• microsserviços,
• containers,
• integração moderna,
• e principalmente…
• JSON.

E talvez essa seja a maior ironia da computação:

O formato que nasceu no JavaScript acabou ajudando o z/OS a continuar dominando o coração financeiro do planeta.

---

☕ Frase Final no Estilo Bellacosa Mainframe

“O COBOL continua processando bilhões… mas agora conversa com o mundo em JSON.” 🔥🚀

 

SMP/E for z/OS Workshop : LIST & REPORT Commands

 

Bellacosa Mainframe apresenta SMP/E List and Report Commands

SMP/E for z/OS Workshop

ACCEPT Processing – LIST & REPORT Commands

Quando olhar o CSI é tão importante quanto instalar o código

Instalar SYSMOD qualquer um instala.
Agora… saber exatamente o que está instalado, onde, por quê e com qual dependência
👉 isso separa operador de System Programmer.

É aqui que entram os comandos LIST e REPORT.

---

LIST Command

Abrindo o CSI como quem abre o capô do sistema

O comando LIST é o bisturi do SMP/E.
Ele não interpreta, não deduz, não opina.
Ele mostra os fatos gravados no CSI.

📌 O LIST pode extrair informações de:

• Global Zone

• Target Zone

• Distribution Zone

• SMPPTS

• SMPLOG

• SMPSCDS

💡 Easter egg #1

Se você confia mais na memória do que no LIST,
o CSI vai te humilhar em algum momento.

---

Boundary: o detalhe que separa sucesso de confusão

Antes de usar LIST, você define o boundary:

• Global Zone → acesso a SMPPTS

• Zona com DDDEF do SMPLOG

• Target Zone associada ao SMPSCDS

• Ou tudo de uma vez com:

ALLZONES

⚠️ ALLZONES lista tudo que existe, não tudo que você quer ver.

💡 Easter egg #2

ALLZONES às 3 da manhã
é como dar SELECT * em produção.

---

O que dá pra listar no Global Zone

Com LIST você pode ver:

• OPTIONS

• UTILITIES

• DDDEFs

• FMIDSETs

• ZONESETs

• SYSMOD entries

• MCS entries do SMPPTS

• HOLDDATA (++HOLD)

HOLDDATA com lupa

Você pode filtrar por:

• HOLDERROR

• HOLDSYSTEM

• HOLDUSER

E ainda combinar com SYSMOD específico.

📌 Se combinar filtros demais, o SMP/E só lista
entradas que satisfaçam todos.

---

Filtros avançados (onde mora o poder)

LIST aceita os mesmos refinamentos do APPLY/ACCEPT:

• SOURCEID

• EXSRCID

• FORFMID

• XZLMOD

• XZLMODP

• XREF

👉 Ideal para:

• Debug de dependência

• Auditoria

• Pós-migração

• Comparação entre ambientes

💡 Easter egg #3

SOURCEID bem usado
vale mais que planilha paralela.

---

LIST em Target e Distribution Zones

Além do básico, você pode listar:

• TARGETZONE definition

• DLIBZONE definition

• DDDEFs

• ELEMENT entries:

  • MOD

  • MAC

  • SRC

  • JAR

  • HFS

• LMOD entries

SYSMOD entries com status

Você pode filtrar por:

• ERROR

• SUP (superseded)

• NOSUP

• RESTORE

• NOAPPLY

• NOACCEPT

• BYPASS

• DELETE

📌 SUP e NOSUP são mutuamente exclusivos.

💡 Easter egg #4

SYSMOD em ERROR não é bug
é aviso ignorado.

---

LIST LOG e BACKUP

• LIST LOG → conteúdo do SMPLOG

  • Total ou por intervalo de data

• LIST BACKUP → conteúdo do SMPSCDS

  • Tudo ou por SYSMOD específico

👉 LIST é o comando ideal para auditoria forense do SMP/E.

---

LIST vs DIALOG QUERY

LIST = dados brutos
QUERY = visão amigável

Quando a coisa aperta…
LIST sempre vence.

---

REPORT Command

Quando você precisa que o SMP/E pense por você

Se o LIST mostra,
o REPORT analisa.

Ele cruza zonas, dependências, FMIDs, SOURCEIDs e HOLDs
e ainda gera comandos prontos.

📌 REPORT é o SMP/E dizendo:

“relaxa, eu faço a correlação.”

---

REPORT CROSSZONE

Dependência entre produtos e zonas

Usado para responder:

“Instalei isso aqui… quebrou quem?”

Requisitos:

• ZONESET obrigatório

• Pode limitar por:

  • FMID

  • ZONE

O relatório mostra:

• Dependências cruzadas

• SYSMODs faltantes

• Se já foram RECEIVED

• Quem causou a dependência

👉 E ainda gera comandos SMP/E no SMPPUNCH

NOPUNCH

se você não quiser os comandos.

💡 Easter egg #5

SMPPUNCH esquecido
vira APPLY acidental.

---

REPORT ERRSYSMODS

Quando o passado volta pra cobrar

Identifica SYSMODs que:

• Já foram instalados

• Mas agora estão em ERROR HOLD

Pode analisar:

• Global Zone

• Target Zone

• Distribution Zone

Filtros:

• Data inicial / final

• FMID

O relatório mostra:

• SYSMOD afetado

• Reason ID

• Quem resolve

• ++HOLD completo

💡 Easter egg #6

ERROR HOLD não some
só muda de lugar.

---

REPORT SOURCEID

Quem veio de onde?

Descobre:

• Quais SOURCEIDs existem

• Quais SYSMODs usam cada um

Com ou sem filtro por SYSMOD.

👉 Excelente para:

• FIXCAT

• Hardware novo

• Coexistência

• Migração de release

---

REPORT SYSMODS

Comparação entre zonas

Usado para:

• Validar ambientes

• Comparar releases

• Checar desvio de serviço

Parâmetros:

• INZONE

• COMPAREDTO

Resultado:

• O que existe em uma zona

• E não existe na outra

• Com comandos prontos para corrigir

💡 Easter egg #7

Ambiente “igual” sem REPORT
é fé, não evidência.

---

REPORT MISSINGFIX (FIXCAT)

Adeus PSP Bucket manual

Disponível a partir do SMP/E 3.6.

Identifica:

• APARs faltantes

• Por categoria FIXCAT

• Para hardware, software e coexistência

Mostra:

• FIXCAT

• APAR

• PTF corretivo

• Dependências

• Problemas de HOLD

📌 Dois blocos:
1️⃣ Missing fixes
2️⃣ Resolving SYSMODs em erro

💡 Easter egg #8

FIXCAT bem usado
economiza fim de semana inteiro.

---

Bellacosa Summary – em poucas linhas

LIST mostra o que existe
REPORT explica o impacto
SMPPUNCH sugere a correção
Você decide se confia

---

Checklist Bellacosa – LIST & REPORT

✔ LIST antes de APPLY
✔ REPORT antes de migrar
✔ FIXCAT sempre atualizado
✔ SOURCEID bem definido
✔ SMPPUNCH revisado
✔ LOG nunca ignorado

---

Conclusão

Quem domina LIST e REPORT:

• Não instala no escuro

• Não depende de planilha

• Não descobre erro em produção

• Não briga com auditor

💡 Easter egg final

O SMP/E sempre soube a verdade.
Você só precisava perguntar direito.

Bellacosa Mainframe Storage e DASD 3390

---

💽 Tracks, Cilindros e DASD no IBM Mainframe

Arquitetura, não nostalgia

“O mainframe não mede storage em tracks e cilindros porque é antigo.
Ele faz isso porque sabe exatamente o que está fazendo.”

---

1️⃣ A origem da filosofia: quando hardware importava (e ainda importa)

Desde os primórdios do IBM System/360 (1964), o mainframe foi projetado com um princípio inegociável:

👉 Controle total do I/O

Naquela época:

• Disco era caro

• CPU era valiosa

• I/O era o gargalo

💡 Conclusão da IBM:

“Se o gargalo é I/O, precisamos dominar o disco até o último detalhe físico.”

Assim nascem os conceitos de:

• Track

• Cilindro

• Bloco

• Extent

Nada disso é acaso. É engenharia.

---

2️⃣ O que é um TRACK (pista) – o átomo do DASD

📀 Track é:

• Uma circunferência física no platter do disco

• Unidade mínima de alocação real

• Otimizada para leitura e escrita sequencial

Características importantes:

• Contém um ou mais blocos

• O tamanho em bytes não é fixo

• Depende de:

  • Dataset (PS, PO, VSAM)

  • BLKSIZE

  • Tipo de acesso

📏 Referência clássica (3390):

• ≈ 56 KB por track (didático, não absoluto)

🧪 Easter egg técnico:

Mesmo quando você pede espaço em MB,
o DFSMS converte tudo para tracks internamente 😎

---

3️⃣ O que é um CILINDRO – o segredo da performance

🛢️ Cilindro =
Conjunto de tracks alinhados verticalmente em todos os pratos do disco.

Por que isso é genial?

• O braço do disco não precisa se mover

• Menos seek

• Mais throughput

• Menos latência

📌 Em mainframe:

Performance não é pico, é constância.

---

IBM HD 3390

4️⃣ Modelos clássicos de DASD IBM (história viva)

📦 IBM 2311 / 2314

• Anos 60 / 70

• Discos removíveis

• Origem dos conceitos de cilindro

📦 IBM 3330 – “Merlin”

• Gigante físico

• Primeiro “big storage”

📦 IBM 3380

• Alta densidade

• Base para sistemas bancários dos anos 80

📦 IBM 3390 (o eterno)

• Padrão até hoje (logicamente)

• Modelos:

  • 3390-3 (~2,8 GB)

  • 3390-9 (~8,4 GB)

• Referência de cálculo de tracks/cilindros

📦 DS8000 (atual)

• Storage virtualizado

• Cache massivo

• Flash

• Mas… emula 3390
  😏

O mainframe moderniza sem quebrar o passado.

---

5️⃣ Evolução: do ferro ao virtual (sem perder o controle)

Hoje:

• Não existe mais “disco girando” como antes

• Temos:

  • Cache

  • Flash

  • Virtualização

  • Striping interno

Mas o z/OS continua falando em:

• Track

• Cilindro

• Extent

💡 Por quê?

Porque:

• SMF mede I/O em tracks

• WLM calcula impacto por volume

• SMS aloca espaço físico previsível

• Batch depende disso

---

6️⃣ Alocação no dia a dia (JCL raiz)

Exemplo clássico:

//ARQ1 DD DSN=MEU.ARQUIVO,
//         DISP=(NEW,CATLG,DELETE),
//         SPACE=(CYL,(10,5),RLSE),
//         DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)

📌 Tradução para o padawan:

• 10 cilindros primários

• 5 cilindros secundários

• Espaço real

• Custo previsível

• Impacto conhecido

---

7️⃣ Performance: onde o mainframe humilha

Linux / Unix:

• Você pede “10 GB”

• O filesystem decide tudo

• Fragmentação invisível

• Latência variável

Mainframe:

• Você define:

  • Onde

  • Quanto

  • Como cresce

• O sistema sabe:

  • Quantos seeks

  • Quantos tracks

  • Quanto I/O será gerado

📊 Resultado:

• SLA calculável

• Batch que termina no horário

• Sistema que envelhece bem

---

8️⃣ Uso prático: quem realmente se beneficia disso?

🏦 Bancos
✈️ Companhias aéreas
🏛️ Governos
💳 Clearing e pagamentos
📊 BI batch massivo

Onde:

• Erro não é opção

• Retry não existe

• Previsibilidade é rei

---

9️⃣ Curiosidades e Easter Eggs de mainframer

🧠 Você sabia?

• SPACE=(TRK,…) ainda é usado em sistemas críticos

• VSAM define espaço em CI/CA, mas mapeia para tracks

• SMF Type 42 mede EXCP por dataset

• EAV permite volumes gigantes, mas o cálculo continua físico

• O termo DASD é mais velho que “storage” 😄

---

🔚 Conclusão Bellacosa Mainframe ☕

Falar de tracks e cilindros não é nostalgia.
É respeito à física, engenharia de verdade e responsabilidade operacional.

“Mainframe não abstrai o problema.
Ele encara o problema de frente.”

E é por isso que, décadas depois,
ele ainda roda o mundo.

---