Translate

domingo, 2 de agosto de 2009

🧠☕ Product Vision no Estilo Bellacosa Mainframe

 

Bellacosa Mainframe apresenta product vision com elevator pitch


🧠☕ Product Vision no Estilo Bellacosa Mainframe

Ou: por que até produto moderno precisa de disciplina de mainframe


🧭 Pergunta raiz (a.k.a. “JOB card do Produto”)

The most effective Product Vision format uses what methodology?
Resposta curta, direta e sem IF ELSE desnecessário:

👉 Elevator Speech (ou Elevator Pitch)

Agora segura esse commit, porque vamos explicar como um conceito de produto moderno conversa diretamente com a mentalidade do mainframe — com história, fofoca, easter eggs e aquele tempero “El Jefe” ☕💼.


🏛️ Origem & História (ou: nada nasce em microserviços)

🎤 Elevator Speech

O Elevator Speech nasce no mundo corporativo americano, décadas atrás, com uma premissa simples:

“Se você tivesse apenas o tempo de um elevador para convencer alguém importante, o que você diria?”

📦 Normalmente: 30 a 60 segundos
📌 Público: executivo, investidor, sponsor, board
🎯 Objetivo: clareza absoluta + impacto imediato

👉 No mundo de Product Vision, ele virou padrão porque:

  • Força foco

  • Elimina ruído

  • Obriga o time a saber o que NÃO é o produto

📢 Mainframe feelings:
É o mesmo princípio de explicar um sistema core bancário em 3 frases antes da diretoria mandar “vamos para o próximo assunto”.


🧪 Comparando os formatos (como um bom JCL COMMENT)

❌ Laconic Speech

  • Curto demais

  • Soa vago

  • Parece RACF mal documentado
    📉 “Não dá contexto, só slogan”

❌ Crisp Presentation

  • Bom para slides

  • Ruim para alinhar visão estratégica

  • Vira PowerPoint bonito sem alma
    📉 “Muito SHOW, pouco JOB”

❌ Brief Report

  • Denso

  • Técnico

  • Mata a inspiração
    📉 “É o SMF record do produto”

✅ Elevator Speech (O CAMPEÃO)

  • Simples

  • Direto

  • Memorável

  • Replicável pelo time inteiro
    📈 “Todo mundo consegue repetir no café”


🧩 Estrutura clássica do Elevator Speech (a “COPYBOOK” da Product Vision)

Modelo mais famoso (Geoffrey Moore):

For (target customer)
Who (statement of the need)
The (product name)
Is a (product category)
That (key benefit)
Unlike (primary competitor)
Our product (key differentiator)

📌 Isso é Product Vision executável, não poesia.


🧠 Exemplo prático (com cheiro de datacenter)

For grandes bancos brasileiros
Who precisam processar milhões de transações críticas por segundo
The CorePay Z
Is a plataforma de processamento financeiro
That garante alta disponibilidade, segurança e integridade dos dados
Unlike soluções distribuídas instáveis
Our product roda em IBM Z com confiabilidade de décadas

💥 Se o diretor entendeu isso, o produto vive.


🧨 Fofoca corporativa (porque Bellacosa conta bastidor)

👀 Muitas empresas:

  • Dizem que têm Product Vision

  • Mas na prática só têm roadmap de features

💣 Resultado?

  • Produto sem identidade

  • Squad puxando para lados diferentes

  • “Retrabalho” (o famoso RESTART STEP=) eterno

📌 Times maduros sempre começam com Elevator Speech antes do Jira.


🥚 Easter Eggs (para os atentos)

  • Elevator Speech ≈ Mensagem inicial de um dump

  • Se não explica em 1 minuto, nem o operador vai entender

  • Jeff Bezos proibiu PowerPoint → preferia narrativas curtas e claras

  • Mainframe já fazia isso nos anos 70:

    “Este sistema liquida operações bancárias nacionais com consistência e disponibilidade 24x7”

👑 Isso é Product Vision raiz.


🧠 Comentário “El Jefe”

❝ Se você não consegue explicar seu produto em um elevador,
você não tem um produto — só um monte de código rodando. ❞


🧷 Dicas práticas (para aplicar amanhã)

✔️ Crie o Elevator Speech antes do backlog
✔️ Todo dev deveria saber recitar a visão
✔️ Se cada pessoa descreve diferente → ABEND de visão
✔️ Revise a Product Vision a cada grande mudança estratégica


🏁 Conclusão (RETURN CODE 0)

📌 A metodologia mais efetiva para Product Vision é o Elevator Speech, porque:

  • Cria alinhamento

  • Força clareza

  • Evita desperdício

  • Funciona do board ao data center

☕ E como diria o Bellacosa Mainframe:

Produto bom é aquele que até o mainframe entenderia.


sábado, 1 de agosto de 2009

🧩SMP/E: USERMOD na prática

 

Bellacosa Mainframe apresenta IBM SMP/E

🧩 USERMOD na prática

Poder absoluto nas mãos erradas (ou a salvação do sysprog)

“USERMOD é liberdade.
USERMOD sem controle é tragédia.”


🧠 O que é USERMOD (sem romantizar)

USERMOD é um SYSMOD criado pelo próprio cliente, não pela IBM.

Ele permite:

  • Ajustes locais

  • Correções temporárias

  • Customizações específicas

  • Patches emergenciais

👉 Em Bellacosa claro:

USERMOD é mexer no z/OS sem a IBM te segurar a mão.


🕰️ Origem do USERMOD

USERMOD nasceu da necessidade real:

  • A IBM não entrega tudo pronto

  • Ambientes são únicos

  • Nem toda correção pode esperar um PTF oficial

📌 Mas a IBM sempre deixou claro:

USERMOD é por sua conta e risco.


🧩 Quando USERMOD faz sentido

✔ Ajuste emergencial
✔ Correção temporária
✔ Customização local
✔ Teste de solução
✔ Mitigação até PTF oficial

❌ Substituir manutenção IBM
❌ “Resolver rápido” sem documentação
❌ Correção definitiva


⚠️ Riscos reais do USERMOD

  • Conflito com PTF futuro

  • Perda de suporte IBM

  • Dificuldade em upgrades

  • Dependências invisíveis

  • Esquecimento (o pior de todos)

👉 USERMOD mal documentado vira fantasma.


🧠 USERMOD e SMP/E

USERMOD:

  • É tratado como SYSMOD

  • Tem MCS

  • Usa RECEIVE/APPLY/ACCEPT

  • Entra no CSI

📌 Se não está no SMP/E, não existe.


🧾 Estrutura básica de um USERMOD

Exemplo simples

++USERMOD(UM0001). ++VER(Z038) FMID(HJES770). ++MOD(JES2MOD).

👉 Tradução:

  • USERMOD UM0001

  • Para JES2

  • Modificando módulo específico


🔎 Boas práticas de MCS em USERMOD

Sempre usar:

  • ++VER → versão correta

  • ++IF → controle condicional

  • ++HOLD → alertar risco

  • Comentários claros

💡 Dica Bellacosa:

“USERMOD sem ++VER é roleta russa.”


🧪 APPLY CHECK é obrigatório

Nunca aplique USERMOD direto:

APPLY CHECK.

Avalie:

  • Impacto

  • Conflitos

  • Pré-requisitos

  • PTFs existentes


🔄 USERMOD x PTF futuro

Quando um PTF oficial sai:

  • Ele pode sobrescrever o USERMOD

  • Ele pode falhar por causa do USERMOD

  • Ele pode exigir remoção do USERMOD

📌 Processo saudável:

  1. Identificar USERMOD afetado

  2. RESTORE USERMOD

  3. APPLY PTF

  4. Descartar USERMOD


📦 ACCEPT de USERMOD: pense duas vezes

❗ ACCEPT de USERMOD é perigoso.

Só faça se:

  • For permanente

  • For bem documentado

  • For aprovado formalmente

👉 ACCEPT grava na história.


🧠 Caso real (Bellacosa clássico)

USERMOD criado em 2014
Ninguém lembra por quê
Upgrade falha em 2025
PTF não aplica

📌 Moral:

USERMOD esquecido custa caro.


🎓 Como aprender USERMOD com segurança

  • Estudar MCS

  • Praticar em laboratório

  • Simular conflito

  • Ler Redbooks

  • Usar SMP/E Workshop


🧠 Curiosidades Bellacosa

  • USERMOD já salvou sistemas críticos

  • USERMOD já derrubou produção

  • USERMOD nunca deve ser invisível


🧾 Comentário final – USERMOD

USERMOD é bisturi, não martelo.
Use com precisão.
Documente tudo.

🧩💾🔥


segunda-feira, 6 de julho de 2009

☕⚗️💣 FULLMETAL ALCHEMIST: BROTHERHOOD — O SISTEMA QUE TENTOU EXECUTAR UM RESTORE HUMANO E DESCOBRIU QUE NEM O ADMINISTRADOR DO UNIVERSO TEM AUTORIZAÇÃO PARA ISSO

 

Bellacosa Mainframe e o fullmetal alchemist brotherhood um anime impar


☕⚗️💣 FULLMETAL ALCHEMIST: BROTHERHOOD — O SISTEMA QUE TENTOU EXECUTAR UM RESTORE HUMANO E DESCOBRIU QUE NEM O ADMINISTRADOR DO UNIVERSO TEM AUTORIZAÇÃO PARA ISSO


Dados Técnicos

Título Original: Hagane no Renkinjutsushi: Fullmetal Alchemist

Título Internacional: Fullmetal Alchemist: Brotherhood

Autor da Obra Original: Hiromu Arakawa

Mangá Original: Publicado entre 2001 e 2010

Estúdio de Animação: Bones

Direção: Yasuhiro Irie

Exibição Original: 5 de abril de 2009 a 4 de julho de 2010

Episódios: 64

Gênero:

  • Ação

  • Aventura

  • Fantasia Sombria

  • Drama

  • Militar

  • Filosófico

  • Steampunk

  • Shounen

Classificação Indicativa:
14 a 16 anos dependendo do país devido a violência, temas filosóficos, guerra, experimentos humanos e morte.


O Que É Fullmetal Alchemist: Brotherhood?

Se existe um anime capaz de unir filosofia, alquimia, política, ciência, guerra, religião, ética, amizade e sacrifício em uma única arquitetura narrativa, esse anime é Fullmetal Alchemist: Brotherhood.

Muitos animes contam histórias de heróis.

Brotherhood conta a história de um erro de sistema.

E de tudo o que acontece depois.


A Grande Sinopse

Edward e Alphonse Elric são dois irmãos prodígios da alquimia.

Após perderem a mãe, decidem desafiar a maior regra do universo:

a transmutação humana.

Na prática?

Tentam restaurar um arquivo permanentemente deletado.

O resultado é catastrófico.

Edward perde uma perna.

Alphonse perde o corpo inteiro.

Edward sacrifica um braço para prender a alma do irmão em uma armadura.

A partir daí começa uma jornada para recuperar aquilo que perderam.

Mas o que parecia uma busca pessoal revela uma conspiração capaz de destruir uma nação inteira.


A Diferença Entre Fullmetal Alchemist e Brotherhood

Aqui existe uma curiosidade histórica extremamente importante.

Fullmetal Alchemist (2003)

O anime de 2003 começou quando o mangá ainda estava sendo publicado.

Consequência?

A história alcançou o mangá rapidamente.

O estúdio precisou criar um caminho próprio.

Resultado:

  • Final alternativo

  • Vilões diferentes

  • Temas mais sombrios

  • Desenvolvimento original


Fullmetal Alchemist: Brotherhood (2009)

Brotherhood foi produzido quando o mangá estava próximo do final.

Dessa vez o estúdio Bones adaptou praticamente toda a obra original.

Por isso Brotherhood é considerado a versão definitiva da história.


O Estúdio Bones e Seu Trabalho Monumental

O Studio Bones é um dos gigantes da animação japonesa.

Também produziu:

  • My Hero Academia

  • Mob Psycho 100

  • Bungou Stray Dogs

  • Soul Eater

  • Noragami

Brotherhood é frequentemente citado como uma das maiores realizações técnicas do estúdio.

A animação permanece impressionante mesmo mais de quinze anos após o lançamento.


A História Escondida Por Trás da História

Na superfície vemos alquimia.

Mas por trás dela existem temas muito mais profundos.


Guerra

O massacre de Ishval é uma referência clara a genocídios e guerras do mundo real.

Arakawa explora:

  • Crimes de guerra

  • Obediência militar

  • Culpa coletiva

  • Trauma psicológico

Poucos shounens abordaram esses temas com tanta maturidade.


Ciência Sem Ética

Os experimentos realizados por diversos personagens mostram um debate extremamente atual.

Até onde a ciência pode avançar?

Quando a busca pelo conhecimento ultrapassa limites morais?

Essa discussão lembra:

  • Experimentos nazistas

  • Armas nucleares

  • Engenharia genética

  • Inteligência artificial sem controle


Religião

A série não ataca a religião.

Ela critica o fanatismo.

Diversos personagens acreditam em algo maior.

Mas o anime mostra os perigos de líderes que manipulam a fé para obter poder.


Os Homúnculos: Os Bugs do Sistema Humano

Uma das maiores genialidades da obra.

Os Homúnculos representam os Sete Pecados Capitais.

Cada um simboliza uma falha humana.

Lust

Luxúria.

Manipulação.

Desejo.


Greed

Ganância.

Mas curiosamente se torna um dos personagens mais humanos da série.


Envy

Inveja.

Representa ressentimento e ódio.


Wrath

Ira.

Talvez um dos antagonistas mais assustadores dos animes.


Pride

Orgulho.

A arrogância elevada ao extremo.


Sloth

Preguiça.

A resistência à mudança.

Algo que muitos sistemas legados conhecem muito bem.


Gluttony

Gula.

Consumo sem limite.


Os Personagens Mais Importantes

Edward Elric

O protagonista.

Impulsivo.

Brilhante.

Obcecado por corrigir o próprio erro.

Seu crescimento é um dos melhores já escritos em um anime.


Alphonse Elric

O coração moral da série.

Mesmo após perder tudo, continua acreditando nas pessoas.


Roy Mustang


Provavelmente um dos personagens mais populares da obra.

Estratégico.

Carismático.

Ambicioso.

Mas profundamente marcado pela guerra.


Riza Hawkeye

Lealdade absoluta.

Disciplina.

Consciência moral.

É o "controle de produção" que impede Mustang de cometer erros irreversíveis.


Scar

Um dos personagens mais complexos da história.

Inicialmente parece um vilão.

Depois entendemos que é resultado das tragédias provocadas pelo próprio sistema.


A Grande Mensagem Oculta

A maioria das pessoas acredita que a mensagem principal é:

"Troca equivalente."

Mas não é.

Ao longo da série, essa ideia é desconstruída.

O verdadeiro ensinamento é:

o valor humano não pode ser medido matematicamente.

Nem tudo pode ser calculado.

Nem tudo pode ser trocado.

Nem tudo pode ser recuperado.


O Que Faz Brotherhood Ser Diferente?

Muitos animes possuem:

  • Bons personagens

  • Boa ação

  • Boa animação

Brotherhood possui algo raro:

planejamento.

Quase tudo apresentado nos primeiros episódios volta a ter importância no final.

Pouquíssimas obras conseguem manter essa consistência durante 64 episódios.

É como um sistema legado escrito há décadas que ainda funciona perfeitamente porque foi projetado corretamente desde o início.


Houve Censura?

Sim e não.

O anime preservou a maior parte do material do mangá.

Porém:

  • Algumas cenas violentas foram suavizadas visualmente.

  • Certas imagens de mutilação receberam enquadramentos menos explícitos.

  • Algumas emissoras internacionais editaram cenas envolvendo sangue e violência.

Mesmo assim, Brotherhood continua sendo muito fiel à obra original.


Impacto Cultural

O impacto cultural é gigantesco.

A série:

  • Figura constantemente entre os animes mais bem avaliados da história.

  • Influenciou diversas obras posteriores.

  • Tornou Edward Elric um dos protagonistas mais reconhecidos dos animes.

  • É frequentemente utilizada em discussões filosóficas sobre ética e ciência.

  • Continua atraindo novos fãs mais de uma década após seu encerramento.


Conclusão Bellacosa Mainframe

Se eu tivesse que explicar Fullmetal Alchemist: Brotherhood para um profissional de mainframe, diria o seguinte:

Dois programadores tentaram executar um restore impossível.

O sistema retornou um ABEND catastrófico.

Durante 64 episódios eles percorrem toda a infraestrutura do ambiente tentando descobrir quem alterou as regras do universo.

No processo descobrem corrupção administrativa, falhas de governança, experimentos ilegais, manipulação de usuários, engenharia social, dívida técnica acumulada por séculos e um arquiteto maluco tentando derrubar todo o datacenter da realidade.

E a maior lição permanece válida em 2026:

Nem toda perda pode ser recuperada por backup.

Nem todo erro pode ser corrigido por rollback.

E alguns commits mudam o sistema para sempre.

☕⚗️💣 Fullmetal Alchemist: Brotherhood não é apenas um anime. É uma aula sobre responsabilidade, ética, consequências e a perigosa ilusão de acreditar que existe um atalho para tudo.

domingo, 5 de julho de 2009

🧠 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 DASDDirect 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

TipoCylinders
3390-11.113
3390-33.339
3390-910.017
3390-2732.760
EAVmilhõ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.”

sexta-feira, 3 de julho de 2009

🔷 RUNSTATS no DB2: Mantendo Estatísticas Sempre Frescas

 

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

ConceitoDetalhe
O que éComando para coletar estatísticas sobre tabelas e índices
SintaxeRUNSTATS TABLESPACE ... TABLE(...) AND INDEXES ALL
Quando usarApós grandes mudanças nos dados, ou periodicamente
ImpactoMelhora planos de execução e performance de queries
Dicas BellacosaPriorize 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.

quinta-feira, 2 de julho de 2009

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

 

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

quarta-feira, 1 de julho de 2009

🛡️ 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.

🛡️💾🔥