domingo, 3 de outubro de 2010

💽 Tracks, Cilindros e DASD no IBM Mainframe

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.




sexta-feira, 1 de outubro de 2010

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz

 

Bellacosa Mainframe apresenta o RACF 

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz 

Se você já perdeu acesso ao próprio TSO, já bloqueou produção com um PERMIT mal dado, ou já ouviu

“foi só uma alteração de RACF…”
então este texto é para você.

Aqui não tem introdução infantil.
Aqui é RACF raiz, técnico, sistêmico e perigoso — do jeito que veterano respeita.


🕰️ História & Origem — por que o RACF nasceu paranoico

O RACF (Resource Access Control Facility) surge nos anos 70, quando a IBM percebeu que:

  • Controle por good behavior não escala

  • Segurança precisava ser centralizada

  • Auditoria não podia ser opcional

RACF foi desenhado para:

  • Negar por padrão

  • Controlar quem, o quê, quando e como

  • Integrar com o núcleo do z/OS

Verdade inconveniente:

RACF não confia nem no SYSADM. E está certo.


🔐 Por onde começar com Segurança (visão de veterano)

Segurança não começa no comando. Começa no modelo mental.

Princípios reais:

  • Least Privilege

  • Segregation of Duties

  • Accountability

  • Auditabilidade

🔥 Easter egg:
Ambiente “funcionando” ≠ ambiente “seguro”.


🏗️ A Estrutura de Grupos — o esqueleto invisível

Grupos RACF não são “organizacionais”.
São domínios de autoridade.

  • Grupos pais controlam filhos

  • OWNER ≠ SUPGROUP

  • Hierarquia mal desenhada vira bomba relógio

📌 Exemplo técnico:

ADDGROUP FINANCE SUPGROUP(SYS1) OWNER(SYS1)
ADDGROUP FINANCE.PAYROLL SUPGROUP(FINANCE)

Comentário ácido:

Grupo mal definido é privilégio eterno.


⌨️ Os Comandos RACF — bisturis, não martelos

  • ADDUSER / DELUSER

  • ADDGROUP / DELGROUP

  • CONNECT / REMOVE

  • PERMIT

  • ALTUSER / ALTGROUP

  • SETROPTS

🔥 Regra de Produção:

Se você não sabe desfazer, não execute.


🗑️ Definindo & Excluindo Grupos RACF

Criar grupo é fácil.
Excluir é trauma.

Antes de um DELGROUP:

  • Usuários conectados?

  • Perfis com OWNER?

  • DATASET PROFILE ownership?

  • Surpresas em ACL herdada?

Fofoquice técnica:
DELGROUP em produção é evento histórico.


👤 Definindo Usuários — mais que um ID

Um usuário RACF é:

  • Identidade

  • Responsabilidade

  • Risco

Campos críticos:

  • SPECIAL / OPERATIONS / AUDITOR

  • PASSWORD interval

  • REVOKE / RESUME

  • OMVS / DFP / CICS

📌 Exemplo:

ADDUSER JOSE NAME('JOSE SILVA') DFLTGRP(FINANCE) PASSDATE(30)

🔥 Easter egg:
Usuário genérico é pecado capital.


🔗 Conectando Usuários a Grupos

CONNECT é onde a segurança realmente acontece.

  • AUTHORITY (USE, READ, CONNECT, JOIN)

  • GROUP-SPECIAL

  • OWNER implícito

Verdade nua:

CONNECT errado é privilégio que ninguém vê.


🗂️ Perfis de Conjunto de Dados (DATASET PROFILES)

O coração do RACF clássico.

  • HLQ como fronteira de poder

  • DISCRETIONARY ≠ MANDATORY

  • UACC mal definido = vazamento

📌 Exemplo:

ADDSD 'FINANCE.PAYROLL.**' OWNER(FINANCE) UACC(NONE)
PERMIT 'FINANCE.PAYROLL.**' ID(PAYUSR) ACCESS(READ)

🔥 Curiosidade:
UACC(READ) já causou mais incidente que bug de COBOL.


🌐 Perfis Gerais de Recursos (CLASS Profiles)

Aqui o RACF vira onipresente:

  • CICS

  • IMS

  • MQ

  • SDSF

  • OPERCMDS

  • FACILITY

El Jefe warning:

Quem ignora classe FACILITY não entende z/OS moderno.


🧨 Recursos Especiais do RACF

  • SPECIAL

  • OPERATIONS

  • AUDITOR

  • TRUSTED

  • WARNING vs FAIL

🔥 Comentário venenoso:
SPECIAL demais é insegurança institucionalizada.


⚙️ O Comando SETROPTS — o painel nuclear

SETROPTS controla:

  • Ativação de classes

  • Auditoria

  • Regras globais

  • Password rules

📌 Exemplo:

SETROPTS CLASSACT(DATASET) RACLIST(DATASET) REFRESH

☕🔥 Regra sagrada:

SETROPTS sem planejamento vira outage invisível.


🔄 RACF Remote Sharing Facility (RRSF)

RACF em modo distribuído:

  • Compartilhamento de identidades

  • Replicação de perfis

  • Confiança entre sistemas

🔥 Curiosidade:
RRSF mal configurado espalha erro em escala industrial.


🔗 RACF e Sysplex — segurança em cluster

No Sysplex:

  • Database compartilhado

  • Consistência obrigatória

  • Propagação imediata

Verdade dura:

No Sysplex, erro local vira problema global.


🧪 Programas Utilitários RACF

Ferramentas para quem não vive no ISPF:

  • IRRDBU00

  • IRRUT200

  • IRRICE

  • unloads para auditoria

  • Análise offline

🔥 Easter egg veterano:
Auditor sério não confia só em LISTUSER.


🧠 Mentalidade de Segurança Mainframe (nível veterano)

✔️ Segurança é processo, não produto
✔️ Tudo que não está definido será explorado
✔️ RACF não protege sistema — protege negócio
✔️ Auditor não é inimigo
✔️ Log é prova histórica


🥚 Easter Eggs & Fofoquices RACF

  • Todo ambiente tem um ID “histórico”

  • Sempre existe um dataset que “ninguém sabe de quem é”

  • Segurança forte incomoda — e é esse o objetivo

  • Incidente sério sempre começa com:

    “Mas esse acesso sempre existiu…”


☕🔥 Conclusão — Manifesto El Jefe RACF

RACF não é:

  • Cadastro

  • Burocracia

  • Entrave

RACF é:

  • Arquitetura de confiança

  • Controle de risco

  • Linha final de defesa do z/OS

☕🔥 Se você domina RACF,
você não protege arquivos —
protege a empresa inteira.

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.”

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.

 

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.

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.

domingo, 15 de agosto de 2010

SMP/E for z/OS Workshop : BUILDMCS, LINK MODULE e LINK LMODS

 

Bellacosa Mainframe apresenta SMP/E buildmcs link lmods e module

SMP/E for z/OS Workshop

BUILDMCS, LINK MODULE e LINK LMODS

Quando o SMP/E deixa de ser manutenção e vira engenharia de produto

Até agora, no mundo SMP/E, falamos muito de rotina operacional:
RECEIVE, APPLY, ACCEPT, RESTORE.
O famoso arroz com feijão do dia a dia.

Mas existe um outro SMP/E.
Menos usado.
Mais poderoso.
Mais perigoso se mal compreendido.

Hoje entramos no território de product build, onde aparecem três comandos que não são para iniciantes:

  • BUILDMCS

  • LINK MODULE

  • LINK LMODS

Aqui o SMP/E deixa de ser só manutenção e passa a ser engenharia reversa, migração e reconstrução de produtos.


SMP/E e a visão estrutural do z/OS

O SMP/E enxerga o z/OS como uma hierarquia:

  • 🔹 Elementos simples (SRC, MAC, MOD, PARM)

  • 🔹 Objetos intermediários (OBJ, módulos)

  • 🔹 Estruturas complexas (LMODs)

  • 🔹 Bibliotecas do sistema (target libraries)

Tanto o APPLY quanto os processos de geração de produto fazem a mesma coisa no fundo:

Pegam módulos, macros, source e dados
e combinam tudo para gerar load modules e bibliotecas executáveis

O segredo está em como o SMP/E entende essa estrutura:
👉 entries e subentries no CSI


Revisão rápida das principais subentries (a base de tudo)

🔹 DISTLIB=

Aponta para a distribution library
(cópia oficial, aceita, segura)

🔹 FMID=

Define o nível funcional

Quem é o dono original do elemento

🔹 RMID / UMID=

Definem o nível de serviço

Última substituição e atualizações

🔹 SYSLIB=

Usado por SRC, MAC, DATA, HFS
Define o DDNAME da target library

🔹 LMOD=

Usado em MODULE entries
Direciona o SMP/E para a estrutura do load module

Sem entender isso, BUILDMCS vira magia negra.


Distribution Zone: conteúdo sem estrutura

Um ponto crítico que muita gente erra:

Na DZONE não existe estrutura de LMOD

Na distribution zone:

  • Existem MOD entries

  • Não existem LMOD= subentries

  • O foco é conteúdo, não link-edit

A estrutura só nasce no target, durante APPLY, GENERATE ou LINK.


BUILDMCS – o “clonar produto” do SMP/E

O que é o BUILDMCS?

O BUILDMCS analisa um target zone ou distribution zone
e gera um SYSMOD funcional completo, contendo:

  • ++FUNCTION

  • ++MOD, ++MAC, ++SRC, ++PARM, ++HFS

  • ++JCLIN completo

  • FROMDS apontando para as DLIBs

📦 Resultado:

Um SYSMOD portátil, capaz de reinstalar um produto inteiro em outro ambiente SMP/E


Para que isso existe no mundo real?

Cenários clássicos:

  • Migração de produto entre ambientes

  • Criação de novo CSI

  • Consolidação de sistemas

  • Produto sem mais mídia oficial

  • Ambientes isolados (sem internet, sem Shopz)

BUILDMCS cria uma imagem funcional completa do produto, incluindo:

  • Função

  • Serviço

  • Usermods já aplicados


O que o BUILDMCS NÃO faz

🚫 Não altera o ambiente original
🚫 Não aplica nem aceita nada
🚫 Não “adivinha” dependências externas

Ele fotografa o estado atual do produto.


Como o BUILDMCS funciona por dentro

1️⃣ Analisa o zone (T ou D)
2️⃣ Reconstrói MCS a partir do CSI
3️⃣ Usa FROMDS para apontar para DLIBs
4️⃣ Gera SYSMOD superseding
5️⃣ Grava tudo no SMPPUNCH

Depois disso:

RECEIVE APPLY ACCEPT

em outro ambiente.


Relatórios gerados pelo BUILDMCS

BUILDMCS não é silencioso. Ele gera:

📄 Function Summary Report

  • FMIDs processados

  • SYSMODs substituídos

📄 Entry Summary Report

  • Todos os elementos do FMID

  • MODs, LMODs, DDDEFs

📄 Subentry Summary Report

  • Detalhe fino de cada entry

Se você não leu esses relatórios, você não sabe o que copiou.


⚠️ Restrições do BUILDMCS (a parte que cai em produção)

BUILDMCS não é para todo produto.

Problemas aparecem quando existem:

❌ Load modules compartilhados

Um LMOD com módulos de mais de um produto

❌ Elementos comuns

Mesmo nome e tipo fornecido por produtos diferentes

❌ VERSION, ASSEM, PREFIX

Essas operações não são recriadas

❌ Informações ausentes no Target Zone

  • LEPARM

  • ALIAS

  • DALIAS

Resultado?
👉 SYSMOD gerado incompleto ou incorreto


LINK MODULE – resolvendo dependência entre target zones

Agora imagine isso:

  • Produto A em TZONE1

  • Produto B em TZONE2

  • Um LMOD precisa de módulos dos dois

Sem reinstalar nada.

👉 LINK MODULE resolve isso


O que o LINK MODULE faz?

  • Reexecuta o link-edit

  • Inclui módulos faltantes

  • Atualiza ambos os target zones

  • Cria relacionamento cruzado (TIEDTO)

Tudo isso sem APPLY, sem ACCEPT.


Como o SMP/E documenta isso?

Após o LINK MODULE:

  • XZMODP no LMOD que foi relinkado

  • XZLMODP nos módulos envolvidos

  • TIEDTO nos dois target zones

Isso garante que o SMP/E:

  • Saiba da dependência

  • Avise (ou relinke automaticamente) no futuro


XZLINK – avisar ou agir?

No TIEDTO ZONE:

  • XZLINK(DEFERRED)
    👉 Apenas avisa possível inconsistência

  • XZLINK(AUTOMATIC)
    👉 SMP/E relinka automaticamente

Escolha errada aqui = surpresa em manutenção futura.


LINK LMODS – o REPORT CALLIBS que deu certo

O LINK LMODS substitui o antigo REPORT CALLIBS.

Ele:

  • Identifica LMODs por nome ou CALLIBS

  • Localiza todos os módulos

  • Executa link-edit direto nas target libraries

  • Tem CHECK mode

  • Tenta recuperação automática (compress + retry)

É APPLY sem SYSMOD.


Resumo Bellacosa Mainframe

ComandoPapel
BUILDMCSClona um produto
LINK MODULEResolve dependência entre zones
LINK LMODSRelinka LMODs diretamente

Frase final (estilo Bellacosa)

RECEIVE instala mídia.
APPLY constrói código.
ACCEPT oficializa.
RESTORE ensina humildade.
BUILDMCS revela quem realmente entende SMP/E.

No próximo módulo, entramos em LIST e REPORT — onde o SMP/E finalmente começa a contar a verdade sobre o seu sistema.