domingo, 5 de setembro de 2010

🧠 Uma visão Padawan Storage Engineer, sente-se.

 

Bellacosa Mainframe fala sobre Storage 
Engineer em ibm mainframe zos

🧠 Uma visão Padawan Storage Engineer, sente-se.

Hoje o papo é sério, profundo e cheio de easter eggs:
Monitoramento de Disco em Ambiente IBM Mainframe (z/OS)
(ou: como evitar que o DASD te acorde às 02:37 da manhã)

📜 História rápida (porque storage tem memória longa)

Antes de “elastic storage”, já existia DASD.
E não era luxo: era engenharia.

No mundo mainframe:

  • Disco sempre foi caro

  • I/O sempre foi crítico

  • Planejamento sempre foi obrigatório

Por isso o z/OS nasceu obcecado por controle:

  • Trilhas

  • Cilindros

  • Extents

  • Catálogo

  • Alocação
    Nada é por acaso. Nada é “default inocente”.

💿 DASD – não é disco, é contrato

DASD (Direct Access Storage Device) não é só mídia.
É um modelo lógico estável há décadas.

Mesmo que hoje o storage seja:

  • Flash

  • NVMe

  • Storage definido por software

  • DS8K com magia negra dentro

👉 Para o z/OS, continua sendo 3390.

🧠 Easter Egg clássico:

Você pode trocar todo o storage físico…
…mas o JCL de 1999 continua funcionando.

🧱 3390 – o idioma nativo do z/OS

Estrutura lógica

  • Track

  • Cylinder

  • Volume

  • Extent

Tipos mais comuns:

  • 3390-3 → o feijão com arroz

  • 3390-9 → mais conforto

  • 3390-27 / 54 → ambientes grandes

  • EAV (EAS) → milhões de cylinders

⚠️ Padawan alerta:
EAV resolve espaço, não resolve desorganização.

👀 Por que monitorar disco não é opcional?

Porque no mainframe:

  • Disco cheio não avisa

  • Fragmentação cobra juros

  • Catálogo corrompido vira outage

  • Storage mal planejado vira reunião com diretoria

📊 O que um Storage Engineer DEVE monitorar

🔢 1. Utilização de Volume

  • < 70% → zen

  • 70–85% → atenção

  • 85% → plano de ação

  • 90% → você já perdeu

🧩 2. Fragmentação

  • Muitos extents = mais I/O

  • Sequential sofre

  • VSAM sofre mais ainda

  • Sort chora em silêncio

🧠 Easter Egg:

Fragmentação não mata hoje.
Ela te mata no pico do fechamento mensal.

🧮 3. Número de extents

  • Dataset com 100+ extents é alerta

  • 200+ extents é cirurgia

  • Extents demais = alocação ruim ou volume saturado

📚 4. Catálogo

  • Catálogo cheio = caos

  • Catálogo fragmentado = lentidão

  • Catálogo sem backup = pedido de demissão indireto

Comandos:

LISTCAT ALL

🧠 5. Storage Groups (DFSMS)

Você monitora:

  • Capacidade total

  • Balanceamento

  • Tendência de crescimento

  • Volume “quente”

Comandos úteis:

D SMS,SG
D SMS,VOL

🛠️ Ferramentas nativas (o mínimo que você deve dominar)

📟 SDSF

  • DA

  • /D U,DASD,ONLINE

Visual rápido, mas não substitui análise.

🧾 IDCAMS

O velho sábio que nunca mente:

LISTCAT VOLUME(VOL001) ALL

Mostra:

  • Extents

  • Datasets órfãos

  • Fragmentação

  • Bagunça histórica

🧪 SMF (onde mora a verdade)

Se você quer ser engenheiro de verdade, vá para:

  • SMF 42 (DFSMS)

  • SMF 78 (Storage)

  • SMF 14/15 (dataset activity)

📌 Hot take Bellacosa™:

Quem não olha SMF, administra no escuro.

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

  • IBM OMEGAMON

  • BMC MainView

  • Broadcom SYSVIEW

Alertas comuns:

  • Volume acima do threshold

  • Storage Group desequilibrado

  • Crescimento anormal

  • Tendência explosiva

🧪 Caso real (história de guerra)

Batch falhando aleatoriamente.
Erro muda todo dia.

Causa real:

  • Volume temporário com 88%

  • Crescimento não monitorado

  • Sort concorrente em pico

Correção:

  • Redistribuição de volumes

  • Aumento de pool

  • Monitoramento de tendência

📌 Moral:
Storage não quebra.
Ele acumula dívida técnica.

🧠 Curiosidades que só storage engineer aprende sofrendo

  • Dataset “temporário” criado em 2003 ainda ativo

  • Volume “de teste” com dado crítico

  • SMS class herdada de outro CPD

  • Storage flash com comportamento de fita (sim, acontece)

🧭 Dicas Bellacosa Mainframe™ para Padawan Storage

✔️ Monitore tendência, não só status
✔️ Espaço livre sem balanceamento é ilusão
✔️ EAV não é desculpa para relaxar
✔️ Catálogo merece carinho diário
✔️ Documente storage group (ninguém faz, todos sofrem)
✔️ Nunca confie em “esse volume sempre foi assim”

☕ Encerrando o café…

Ser Storage Engineer no z/OS não é só administrar disco.
É:

  • Prever

  • Planejar

  • Equilibrar

  • Proteger

  • E evitar que alguém te ligue fora do horário 😄

💬 “No mainframe, storage não é onde os dados moram.
É onde a estabilidade vive.”

Publicada por à(s) Sem comentários:
Etiquetas: , , , , ,

sábado, 4 de setembro de 2010

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:

ZonaPapel
TargetCódigo que roda
DistributionCó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.

 

Publicada por à(s) Sem comentários:
Etiquetas: , , , ,

sexta-feira, 3 de setembro de 2010

☕ BUFF & DEBUFF

Buff e Debuff

 

☕ BUFF & DEBUFF

Quando a vida roda com ou sem prioridade


Tem termos que a gente aprende jogando videogame, assistindo anime… e quando percebe, está usando no trabalho, na vida e até no mainframe. Buff e Debuff são dois desses conceitos mágicos que escaparam do mundo dos RPGs e viraram filosofia prática do dia a dia.

🎮 Origem: dos dados de RPG ao pixel

Buff e debuff nascem lá atrás, no RPG de mesa (Dungeons & Dragons, anos 70).

  • Buff: efeito positivo temporário (força +10, defesa +20, velocidade extra).

  • Debuff: efeito negativo (veneno, lentidão, confusão, medo).

Quando os videogames chegaram, isso virou regra:

  • Final Fantasy

  • Dragon Quest

  • Chrono Trigger

  • MMORPGs como Ragnarok, WoW, Lineage

No Japão, o conceito foi absorvido com gosto — porque combina com estratégia, disciplina e preparação.

📺 Animes: o buff virou roteiro

Nos animes, buff e debuff deixaram de ser só mecânica e viraram narrativa.

Exemplos clássicos:

  • Dragon Ball → Kaioken, Super Saiyajin (BUFF MONSTRUOSO).

  • Naruto → modos Sennin, selos amaldiçoados (buff com debuff embutido).

  • Bleach → Bankai (buff de alto risco).

  • Isekai → status screen, skills passivas, debuffs malditos.

Easter egg clássico:
Todo buff poderoso cobra um preço.
Todo debuff forte ensina humildade.

🖥️ Tradução Bellacosa Mainframe

No meu mundo:

  • Buff = prioridade alta no JES2

  • Debuff = CPU contention às 10h da manhã

Exemplos práticos:

  • Um sistema bem tunado → BUFF

  • Um JCL mal escrito → DEBUFF

  • Índice errado no DB2 → debuff permanente

  • Cache quente, I/O afinado → buff passivo invisível

Na IA?

  • Prompt bem feito → buff cognitivo

  • Dados ruins → debuff silencioso

🧠 Impacto cultural

Buff/debuff moldaram como:

  • pensamos estratégia,

  • aceitamos limites,

  • entendemos consequências.

No Japão, isso conversa com:

  • ikigai (quando seus buffs fazem sentido),

  • shikata ga nai (aceitar debuffs inevitáveis),

  • kintsugi (transformar debuff em aprendizado).

🥚 Curiosidades & easter eggs

  • Muitos jogos escondem buffs secretos por comportamento, não por item.

  • Alguns debuffs só aparecem se o jogador for ganancioso.

  • Em RPGs antigos, status “confusão” era mais perigoso que morte.

Na vida também.

🧓 Nostalgia

Quem viveu os anos 80 e 90 lembra:

  • status em tela preta,

  • números piscando,

  • música 8-bit avisando perigo.

Hoje a gente chama isso de:

  • burnout (debuff),

  • férias (buff temporário),

  • experiência acumulada (buff permanente).

☕ Comentário final do El Jefe

A vida é um RPG mal documentado.

Você não escolhe todos os debuffs,
mas escolhe como se prepara.

  • Estudo é buff.

  • Paciência é buff.

  • Curiosidade é buff raro.

E reclamar demais…
bom, isso é debuff empilhável.

☕
No fim, seja no anime, no game, no mainframe ou na IA:

vence quem sabe gerenciar status.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , ,

quarta-feira, 1 de setembro de 2010

☕🖥️ Suporte à Produção Mainframe — o coração que mantém o z/OS batendo

 

Bellacosa Mainframe apresenta Suporte a Produção

☕🖥️ Suporte à Produção Mainframe — o coração que mantém o z/OS batendo 

Se desenvolvimento é o cérebro, Suporte à Produção Mainframe é o sistema nervoso central do ambiente z/OS. É quem sente a dor antes do usuário ligar, quem age antes do SLA estourar e quem garante que o batch das 23h termine antes do café esfriar ☕.

Vamos destrinchar esse tema com história, funcionamento, aplicações práticas, dicas de guerra, curiosidades, easter eggs e aquela fofoquice técnica que só mainframer raiz conhece.

🕰️ Origem & História — de Operador de Sala ao Analista de Produção

Nos primórdios do mainframe:

  • Existia a sala de máquinas

  • Operadores ficavam de olho em luzes piscando, fitas rodando e impressoras cantando

  • Um abend era quase um evento social 😅

Com a evolução:

  • Chegaram MVS, JES2, SDSF, CICS online

  • Depois z/OS, DB2, MQ, WebSphere, Integration Bus

  • E o operador virou Analista de Suporte à Produção, com visão técnica, analítica e estratégica

👉 Hoje, Suporte à Produção não é “apagar incêndio”, é prevenção, análise e controle do ecossistema.

🎯 O que é Suporte à Produção Mainframe?

É a área responsável por:

  • Acompanhar processamento batch e online

  • Analisar incidentes, falhas e degradação

  • Atuar em eventos críticos de produção

  • Garantir disponibilidade, performance e integridade

  • Usar ferramentas do z/OS para diagnóstico rápido e preciso

💡 Resumo Bellacosa:

Suporte à Produção é quem garante que o sistema funcione mesmo quando tudo conspira contra.

🎓 O que deve aprender para trabalhar em Suporte à Produção Mainframe

Esse programa de capacitação é praticamente um manual de sobrevivência do ambiente produtivo IBM Mainframe.

📚 Estrutura Geral

  • Artigos

  • Exercicios

  • Videos

  • Manuais IBM

👉 Ideal para quem quer pensar como Produção, não só executar comandos.

🧠 Objetivo Real (o que ninguém fala no folder)

Além do texto bonito, o curso prepara o aluno para:

  • Tomar decisão sob pressão

  • Escolher a melhor solução, não a mais óbvia

  • Entender impacto sistêmico

  • Dialogar com desenvolvimento, infraestrutura, segurança e negócio

💬 Frase clássica de produção:

“Pode até funcionar… mas em produção é outra história.”

👥 Público-Alvo (quem sobrevive bem nesse mundo)

  • Profissionais de TI

  • Operadores de Mainframe

  • Analistas em transição para Produção

  • Quem já cansou de ouvir:

    “Na homologação funcionou…”

📌 Pré-requisitos

  • TSO/ISPF

  • SDSF

  • Noções de z/OS

  • Inglês básico (sim, mensagem de erro não vem em português 😄)

🧩 Estrutura Curricular — o arsenal do Suporte à Produção

Vamos ao mapa das armas:

🖥️ z/OS

  • JES2, spool, jobs, STCs

  • WTOR, WTO, mensagens

  • Performance, datasets, enqueues

  • Easter egg: quem nunca decorou mensagem $HASP?

🧠 CICS

  • Regiões online

  • Transações travadas

  • Dumps, abends, filas

  • Curiosidade: CICS raramente “cai”… ele se defende

📬 MQ

  • Filas cheias

  • Mensagens presas

  • Canais parados

  • Dica de ouro: produção ama fila vazia e canal ativo

🔌 Integration Bus (Broker)

  • Integração entre mundos

  • Mensagens XML/JSON

  • Transformações e rotas

  • Fofoquice: quando quebra, ninguém sabe de quem é a culpa 😅

🧪 REXX

  • Automação de tarefas

  • Scripts de monitoramento

  • Ações rápidas em incidentes

  • Easter egg raiz: REXX salva madrugada!

🗄️ DB2 – Utilitários

  • REORG, RUNSTATS, COPY

  • Locks, deadlocks

  • Espaço e performance

  • Dica Bellacosa: DB2 lento quase sempre avisa antes

🌐 WebSphere / Servidores de Aplicação

  • Acesso remoto

  • Integração web

  • Monitoramento de serviços

  • Curiosidade: quando o web cai, o mainframe “leva a culpa”

🔍 Funcionamento na Prática — um dia típico de Produção

  1. Batch inicia

  2. Job abenda

  3. SLA começa a gritar

  4. SDSF aberto

  5. Mensagem analisada

  6. Dataset bloqueado

  7. Lock liberado

  8. Job restartado

  9. Negócio segue

  10. Usuário nem ficou sabendo 😎

👉 Isso é Suporte à Produção bem feito.

💡 Dicas de Ouro (nível Bellacosa Mainframe)

✔️ Aprenda a ler mensagens, não só copiar
✔️ Conheça o impacto do comando antes de executar
✔️ Documente tudo (memória falha às 3h da manhã)
✔️ Produção exige calma, método e sangue frio
✔️ O melhor incidente é o que não vira chamado

🥚 Easter Eggs & Curiosidades

  • Todo ambiente tem um job “maldito”

  • Sempre existe um STC que ninguém sabe para que serve

  • Produção aprende mais em 1 incidente do que em 10 cursos

  • O melhor elogio:

    “Nem percebemos que deu problema.”

☕ Conclusão Bellacosa Mainframe

O Suporte à Produção Mainframe não é apenas uma função — é uma mentalidade.

É entender:

  • Tecnologia

  • Processo

  • Negócio

  • Risco

  • Responsabilidade

Quem passa por Produção:

  • Vira profissional mais completo

  • Aprende a pensar grande

  • Ganha respeito técnico

📌 Em resumo:

Se o mainframe é o coração da empresa,
Suporte à Produção é quem garante que ele nunca pare de bater.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , ,
Subscrever: Comentários (Atom)