☕🔥 “O Dia em que o Mainframe Aprendeu Big Data — e o Mundo Percebeu que Sempre Foi Assim”

Apache Spark no z/OS: quando a inteligência vai até o cofre

Durante anos venderam a ideia de que Big Data nasceu fora do mainframe.

Hadoop. Cloud. Clusters baratos. Data Lakes infinitos.

Enquanto isso, silenciosamente, o IBM Z continuava processando:

• Transações globais

• Sistemas bancários

• Seguros

• Cartões

• Governos inteiros

Então veio um momento histórico:

E se o motor de analytics moderno rodasse dentro do mainframe?

Nascia o Spark no z/OS.

---

🧠 O que é o Apache Spark (de verdade)

Ele revolucionou o processamento distribuído porque:

• Trabalha em memória (in-memory computing)

• Executa pipelines complexos via DAG

• Suporta SQL, streaming e machine learning

• Escala horizontalmente

Hoje é um dos pilares da engenharia de dados moderna.

Mas sua verdadeira transformação começou quando encontrou o mainframe.

---

🏛 Quando Spark encontrou o z/OS

O z/OS é o sistema operacional que roda nos computadores mais resilientes já construídos.

No mundo real, os dados mais valiosos vivem aqui:

• Db2 for z/OS

• IMS

• CICS

• VSAM

• SMF

• Logstreams

Mover esses dados para fora sempre foi caro, lento e arriscado.

Spark no z/OS muda o paradigma:

Não leve o dado ao analytics.
Leve o analytics ao dado.

---

📅 História e Release

A plataforma IBM z/OS Platform for Apache Spark foi anunciada oficialmente em 2016.

Foi um movimento estratégico da IBM para:

• Modernizar analytics no mainframe

• Integrar IA ao core transacional

• Evitar exfiltração massiva de dados

• Preparar o Z para a era Data-Driven

Foi também um reconhecimento implícito:

O mainframe nunca deixou de ser o maior data platform do mundo.

---

⚙️ Como o Spark roda no z/OS

Spark executa no z/OS via:

• USS (Unix System Services)

• JVM (Java é obrigatório)

• Deployment Standalone

• Processos distribuídos entre LPARs (Sysplex)

Arquitetura típica:

Master daemon  → Cluster Manager
Slave daemon   → Worker Node
Executors      → Processamento paralelo
MDSS           → Ponte para dados MVS

O MDSS (Mainframe Data Service for Apache Spark) é a peça secreta.

Sem ele, Spark só vê dados “tipo Linux”.
Com ele, enxerga o coração do z/OS.

---

🔐 A arma secreta: processar dados sem movê-los

Em ambientes distribuídos tradicionais:

1. Extrai dados do mainframe

2. Copia para Data Lake

3. Processa

4. Reimporta resultados

Cada passo aumenta:

• Latência

• Custos

• Risco de vazamento

• Complexidade operacional

Com Spark no z/OS:

O processamento acontece no mesmo ambiente seguro.

RACF, criptografia e auditoria continuam protegendo tudo.

---

🧩 O papel do MDSS

O Mainframe Data Service for Apache Spark permite acessar dados clássicos como:

• VSAM

• Sequential datasets

• IMS

• SMF

• Logstream

Ele roda como started task, controlado por ISPF ou Data Service Studio.

Sem ele, Spark não entende formatos MVS.

Com ele, Spark enxerga décadas de história corporativa.

---

🚀 Funcionalidades herdadas do Spark padrão

z/OS Spark mantém praticamente todas as capacidades modernas:

✔ Spark SQL
✔ Machine Learning (MLlib)
✔ Graph processing (GraphX)
✔ Streaming
✔ Integração JDBC
✔ APIs REST
✔ Execução distribuída

A principal exceção histórica:

👉 Não suporta desenvolvimento em R.

---

🤝 Integração com programas tradicionais

Uma das features mais impressionantes:

Spark pode conversar com aplicações escritas em:

• COBOL

• PL/I

• Assembler

• Natural

Inclusive acessar dados e programas via CICS.

Isso cria um cenário único:

Machine Learning moderno dialogando com sistemas escritos há 40 anos — em produção global.

---

🧠 Curiosidades que pouca gente conta

🟡 O mainframe sempre foi Big Data

Antes de “Big Data” existir como buzzword, o Z já processava volumes gigantes.

🟡 zIIP pode reduzir custo do analytics

Workloads Java e analytics podem ser offloadados.

🟡 Parallel Sysplex = cluster de verdade

Sem SPOF, com disponibilidade absurda.

🟡 Segurança nativa imbatível

Copiar dados para fora frequentemente reduz segurança.

---

🥚 Easter Eggs arquiteturais

👉 Spark foi criado para clusters baratos distribuídos
👉 O IBM Z é o oposto: um supercomputador vertical

Quando os dois se encontram, surge algo raro:

Escala horizontal + potência vertical

É como colocar um motor de foguete num trem blindado.

---

🧠 Casos reais de uso

• Fraud detection em tempo real

• Análise de comportamento transacional

• Capacity planning via SMF

• Detecção de anomalias operacionais

• Analytics regulatório

• Scoring de crédito instantâneo

---

☕ Comentário Bellacosa

Durante anos disseram:

“Para inovar, saia do mainframe.”

Hoje a mensagem é outra:

“Se você quer inovar sem quebrar o core do negócio, traga a inovação para o mainframe.”

Spark no z/OS não é nostalgia.

É pragmatismo.

---

🎯 Conclusão

Apache Spark no z/OS representa algo maior do que tecnologia.

Representa uma mudança de mentalidade:

✔ O mainframe não é legado — é fundação
✔ Big Data não substitui o Z — complementa
✔ Segurança e analytics podem coexistir
✔ O futuro não é cloud ou mainframe — é híbrido

---

☕ Frase final de boteco mainframe

O mundo tentou levar os dados para a nuvem.

O IBM Z respondeu:

“Tragam a nuvem até mim.”

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.

SMP/E for z/OS Workshop : ACCEPT Processing

 

Bellacosa Mainframe SMP/E accept processing

SMP/E for z/OS Workshop

ACCEPT Processing

O momento em que o código vira história oficial

Se o APPLY é onde o código começa a rodar,
o ACCEPT é onde ele ganha certidão de nascimento.

Depois do ACCEPT, não tem mais desculpa:

“isso aqui já faz parte do produto”

---

O papel real do ACCEPT no SMP/E

O ACCEPT command é responsável por:

• Instalar os elementos dos SYSMODs nas Distribution Libraries (DLIBs)

• Atualizar a Distribution Zone (DZONE)

• Definir o nível oficial e permanente do software

📌 Em termos simples:

Zona	Papel
Target	Código que roda
Distribution	Código que define o produto

👉 Nunca se executa código direto das DLIBs
(Se você já viu alguém tentar… você sabe o nível do problema 😬)

---

Target vs Distribution – a verdade nua e crua

🔹 Target Libraries

• Load modules executáveis

• Macros e source (para assembly)

• Ambiente vivo

• Pode mudar

🔹 Distribution Libraries

• Elementos “puros”

• Backup oficial

• Base para RESTORE

• Não deveriam mudar toda hora

💡 Easter egg #1

Quem aceita PTF direto em DLIB de produção sem clone
não gosta de dormir tranquilo.

---

ACCEPT é parecido com APPLY?

Sim. E isso é proposital.

A IBM fez o ACCEPT ser quase um APPLY com outro destino:

• Mesmos critérios de seleção

• Mesmas opções:

  • CHECK

  • BYPASS

  • REDO

  • COMPRESS

• Mesma lógica de dependência

• Mesma validação de HOLDDATA

A diferença é onde o SMP/E escreve.

---

Pré-requisitos para um ACCEPT saudável

Antes de aceitar qualquer coisa, o SMP/E verifica:

✅ SYSMOD foi aplicado?

Por padrão:

• SIM → pode aceitar

• NÃO → rejeitado

Se quiser aceitar sem aplicar (caso raro):

BYPASS(APPLYCHECK)

💡 Easter egg #2

BYPASS(APPLYCHECK) é como sudo root
só use se você realmente souber o que está fazendo.

---

✅ Não existem HOLDs pendentes?

O ACCEPT verifica no Global Zone:

• SYSTEM HOLD

• USER HOLD

• ERROR HOLD

Se existir HOLD:

• ACCEPT para

• Você resolve primeiro

---

Como os HOLDs são resolvidos no ACCEPT

🟡 SYSTEM / USER HOLD

• Execute a ação descrita no REASON

• Depois use:

BYPASS(HOLDSYSTEM)

🔴 ERROR HOLD

• Resolvido automaticamente

• Quando o APAR/PTF corretivo é instalado

• Ou um superseding PTF é aceito

📌 Boa prática:

Nunca aceitar PTF com ERROR HOLD ativo.

💡 Easter egg #3

Quem ignora ERROR HOLD
aprende RESTORE na prática.

---

Seleção de elementos no ACCEPT

(a parte que poucos entendem)

O ACCEPT não copia elemento “no grito”.
Ele garante que nenhum nível seja regredido.

Ele compara:

• FMID

• RMID

• UMID

• PRE / SUB no ++VER

Regras básicas:

• Elementos substitutos devem PRE ou SUB

• UPD (SRC, MAC, ZAP) devem respeitar UMID

• Se não respeitar:

  • ACCEPT pode até continuar

  • Mas emite warning

  • E você acabou de assumir o risco

💡 Easter egg #4

Warning ignorado hoje
vira incidente amanhã.

---

O que o ACCEPT faz de verdade (por dentro)

Quando tudo está validado, o SMP/E:

1️⃣ Busca os elementos em:

• SMPPTS

• SMPTLIBs

• LKLIB / TXLIB

2️⃣ Invoca utilitários:

• IEBCOPY

• IEBUPDTE

• LINKEDIT (quando aplicável)

3️⃣ Instala nas DLIBs corretas
(via DISTLIB=)

4️⃣ Atualiza a Distribution Zone:

• Cria entradas de SYSMOD

• Atualiza FMID / RMID

• Remove UMIDs antigos

• Registra ZAPs e UPDs

---

Limpeza pós-ACCEPT (o “lixo controlado”)

Por padrão, o ACCEPT:

• Remove SYSMOD entry do Global Zone

• Apaga MCS do SMPPTS

• Deleta SMPTLIBs associados

• Remove backups (SMPCDS)

Tudo isso acontece porque:

O SYSMOD agora virou baseline

⚠️ Se quiser manter tudo:

NOPURGE

💡 Easter egg #5

Quem usa NOPURGE sem motivo
costuma ficar sem espaço em disco.

---

Relatórios do ACCEPT

Depois do ACCEPT, sempre revise:

• Accept Summary Report

• Element Change Report

• Utility Output

• Deleted SYSMOD Report (quando aplicável)

📌 Se você não leu o report:

O ACCEPT não aconteceu de verdade.

---

ACCEPT em uma frase (Bellacosa style)

RECEIVE traz o pacote
APPLY faz o sistema rodar
ACCEPT transforma mudança em padrão
RESTORE ensina respeito

---

Checklist Bellacosa – ACCEPT seguro

✔ ACCEPT sempre em DLIB clone
✔ BACKUP antes de produção
✔ Nenhum HOLD pendente
✔ APPLY feito (ou BYPASS consciente)
✔ Relatórios lidos
✔ Espaço em disco conferido

---

Conclusão

O ACCEPT é o último passo da cadeia SMP/E.
Depois dele:

• O código vira referência

• O produto muda de nível

• O RESTORE passa a depender disso

Quem domina ACCEPT:

• Entende gestão de software

• Não só instalação

💡 Easter egg final

System programmer bom instala.
System programmer experiente aceita.
System programmer sábio sabe quando não aceitar.