sexta-feira, 29 de junho de 2012

O NOIVINHO DA QUADRILHA

 


O NOIVINHO DA QUADRILHA — UMA CRÔNICA BELLACOSA MAINFRAME
PARA O EL JEFE MIDNIGHT LUNCH

Vasculhar um arquivo de fotos antigas é como abrir um dataset sentimental: cada imagem é um registro, cada rosto um campo, cada memória um load module carregado direto da infância.
E no meio desse inventário do tempo, você encontrou ela:
a foto épica do noivo da quadrilha, um Vaguinho vestido com toda a elegância que só a década de 1970 conseguia produzir.
Terno remendado branco, gravata vermelha, chapéu de palha torto e aquele sorriso de quem não fazia ideia de que um dia se tornaria o cronista oficial do clã Bellacosa.

E como tudo na sua vida vem com história, essa não seria diferente.





1. A QUADRILHA RAIZ – QUANDO JUNHO ERA REALMENTE FRIO

Antes de o clima enlouquecer, junho era junho de verdade:

  • vento gelado cortando o rosto,

  • moletom grosso,

  • fogueira estalando na calçada,

  • e o cheirinho de milho verde misturado com fumaça.

  • neblina, garoa e geada

Era inverno, gente.
Inverno raiz, de fazer a criançada encostar a mão no caneco de quentão (sem álcool, claro) só pra esquentar os dedos.

As festas juninas vinham direto do DNA português, importada dos Santos Populares —
Santo Antônio, São João e São Pedro,
mas aqui ganharam pitadas afro-brasileiras, italianas, indígenas e imigrantes de todas as latitudes.
O resultado?
Uma mistura única que só o Brasil consegue fazer.



2. A ESCOLINHA DA DEPORTAÇÃO — O PRIMEIRO ESCÂNDALO BELLACOSA

A foto pertence àquela mesma escolinha onde eu, segundo registros pseudo-históricos, apócrifos e de testemunhos maternos, foi deportado por:

  • não parar quieto,

  • ser arteiro,

  • ser criativo demais,

  • ser inquieto,

  • e estar levando Dona Mercedes à beira da insanidade.

Mas após a deportação efetiva, os novos amiguinhos na escola, a disciplina da sala de aula, os primeiros contatos com o abcedário, veio o evento dos eventos, a dança Quadrilha.
E nela, você brilhou como o noivinho oficial do arraial.


3. O CASAMENTO CAIPIRA — A NOVELA DE JUNHO

A quadrilha sempre foi um micro teatro do Brasil profundo:

  • Tinha noivo, noiva, padre,

  • O delegado suspeito, para pegar o noivo fujão

  • os pais da noiva, que estavam ali para garantir o final da cerimonia

  • Convidados animados,

  • Emboscadas e fugas,

  • E aquele momento mágico:
    “É mentiraaaa!”

O roteiro era uma novela rural, uma pequena ópera cômica encenada por crianças com dentes faltando, vestidos floridos e bigode pintado com rolhas queimadas, simulando bigodes e barbas.

Eu ali, no meio, sendo levado até o altar improvisado, cercado de bandeirinhas coloridas, fogueira cenográfica e o olhar orgulhoso (e exausto) da Dona Mercedes, da minha madrinha vó Anna e o vô Pedro, tio Pedrinho, tia Mirian e familia.


4. AS BARRAQUINHAS — O PARQUE DE DIVERSÕES DOS ANOS 70

Junho era também o mês das barraquinhas de quermece:

🎣 Pescaria — com peixinhos de madeira e prêmios que iam de pirulito a dominó.
🎯 Tiro ao alvo — onde sempre tinha um primo que jurava ser “bom de mira”.
Arremesso de bolinha — que jamais derrubava as latas, misteriosamente coladas.
📦 Rifas e correio elegante — o Tinder da época.
🫥 Prisão — onde se pagava para prender o amigo e pagava para soltar.
(engenharia financeira brasileira desde sempre).


5. COMIDAS — O BANQUETE SAGRADO DE JUNHO

E como esquecer o cardápio sagrado?

  • Canjica cremosa,

  • Arroz-doce com canela,

  • Pamonha quentinha,

  • Milho assado,

  • Churrasquinho suspeito,

  • Quentão fumegante,

  • Paçoca e pé de moleque.

  • Vinho quente.

  • Sagu com vinho de São Roque

Cada aroma era um portal para a infância.



6. A FOTO — UM PEDAÇO DE TEMPO CONGELADO

Naquela imagem perdida no meu arquivo, o que vemos não é apenas um menininho vestido de noivo.

Vemos:

  • a escolinha que fez Dona Mercedes descansar um pouco,

  • o Brasil dos anos 70, entre o caos financeiro da ditadura militar e as famílias se virando para sobreviver,

  • a alegria simples das festas de bairro,

  • a energia daquele pequeno Vagner arteiro,

  • e um pedaço da alma Bellacosa que resistiu ao tempo.

A foto é prova de que a memória não é só um arquivo:
é um job que roda eternamente no sistema da gente.


7. EPÍLOGO — O NOIVO QUE SOBREVIVEU AO ARRAIAL E À VIDA

Hoje, adulto, olho essa foto e entendo:

Aquele noivinho da quadrilha é um símbolo.
Um lembrete do que sempre fui:

  • sonhador,

  • imaginativo,

  • inquieto,

  • criador de histórias,

  • e dono de uma alma que, mesmo deportada,
    sempre encontra caminho para continuar pulando fogueiras.

Porque  aprendi a dançar a quadrilha da vida…
aprendi também a desviar do delegado, da ponte quebrada, da cobra, do tombo, das armadilhas e dos sustos —
e ainda dar risada no caminho.




segunda-feira, 18 de junho de 2012

💥 Chaos Engineering explicado para quem já derrubou produção sem querer

 


💥 Chaos Engineering explicado para quem já derrubou produção sem querer



03:18 — Introdução: quando o caos não era planejado

Se você é mainframer e já derrubou produção “sem querer”, parabéns:
você praticou Chaos Engineering na forma primitiva, dolorosa e não documentada.

A diferença entre o passado e hoje é simples:

  • Antes: o caos acontecia quando dava ruim

  • Agora: o caos é induzido de propósito, com método, horário marcado e rollback

Chaos Engineering não é vandalismo técnico.
É engenharia preventiva para sistemas distribuídos.


 

1️⃣ O que é Chaos Engineering (sem bravata)

Chaos Engineering é a prática de:

Introduzir falhas controladas em produção
para verificar se o sistema realmente aguenta o que diz aguentar.

Objetivo:

  • Descobrir fragilidades antes do cliente

  • Validar resiliência

  • Reduzir surpresas às 03h da manhã

📌 Tradução mainframe:

“Vamos simular a queda da LPAR… mas com aviso e plano.”


2️⃣ Um pouco de história (sim, isso tem pedigree)

  • Conceito popularizado pela Netflix com o Chaos Monkey

  • Nasceu porque microsserviços + cloud = falha inevitável

  • Inspirado em práticas antigas de engenharia de confiabilidade

😈 Easter egg histórico:
Mainframe já fazia “chaos” quando:

  • Testava DR

  • Simulava queda de região

  • Desligava link para validar contingência

Só não chamava assim.


3️⃣ Por que caos é obrigatório em aplicações distribuídas 🧠

Aplicações distribuídas:

  • Dependem de rede

  • Dependem de serviços externos

  • Escalam horizontalmente

  • Têm falhas parciais

👉 Nada falha inteiro. Falha em pedaços.

📎 Mainframer sabe:
Falha parcial é pior que parada total — porque engana.


4️⃣ Tipos de caos (todos você já viveu)

🔥 Infraestrutura

  • Nó cai

  • Disco some

  • CPU satura

🔥 Rede

  • Latência aumenta

  • Pacote some

  • Timeout aleatório

🔥 Aplicação

  • Serviço responde lento

  • Erro intermitente

  • Consumo de memória crescente

😈 Easter egg:
Quando alguém rodou batch pesado fora da janela… foi caos não planejado.


5️⃣ O erro clássico: “isso nunca vai acontecer” 😬

Toda tragédia começa com:

  • “Esse serviço é estável”

  • “A rede nunca cai”

  • “Esse nó é redundante”

  • “Nunca deu problema”

Chaos Engineering responde:

“Então vamos provar.”


6️⃣ Passo a passo para fazer Chaos Engineering sem ser demitido

1️⃣ Defina o comportamento normal
2️⃣ Escolha uma hipótese
“Se o nó cair, o sistema continua”
3️⃣ Prepare observabilidade
4️⃣ Limite o escopo
5️⃣ Introduza a falha
6️⃣ Observe
7️⃣ Documente
8️⃣ Corrija
9️⃣ Repita

💣 Dica Bellacosa:
Sem rollback, não é engenharia — é suicídio profissional.


7️⃣ Guardrails: o que mainframer já sabe fazer

  • Janela controlada

  • Comunicação clara

  • Monitoramento ativo

  • Plano de reversão

  • Registro pós-teste

📌 Curiosidade:
Change Management não atrapalha caos.
Ele evita caos desnecessário.


8️⃣ Guia de estudo para mainframers curiosos 📚

Conceitos-chave

  • Chaos Engineering

  • Falha parcial

  • Resiliência

  • Error Budget

  • Blast Radius

Ferramentas modernas

  • Chaos Monkey

  • Gremlin

  • LitmusChaos

  • Testes de DR


9️⃣ Aplicações práticas no mundo real

  • Validar arquitetura distribuída

  • Testar autoscaling

  • Avaliar alertas

  • Treinar times

  • Evitar incidentes reais

🎯 Mainframer que domina caos vira arquiteto respeitado.


🔟 Curiosidades que só veterano entende 👀

  • Sistema que nunca falhou é suspeito

  • Falha pequena salva de falha grande

  • Testar em produção dói menos que incidente real

  • Confiança sem teste é fé, não engenharia

😈 Easter egg final:
O melhor teste de caos é aquele que ninguém percebeu, mas tudo continuou funcionando.


11️⃣ Comentário final (05:59, sol nascendo)

Chaos Engineering não é destruir.
É ensinar o sistema a sobreviver.

Se você já:

  • Derrubou produção sem querer

  • Aprendeu mais com falha do que com sucesso

  • Criou workaround às pressas

Então você já entendeu o espírito.

🖤 El Jefe Midnight Lunch conclui:
Quem não testa o caos, vira vítima dele.

 

domingo, 17 de junho de 2012

Crônica – O Carrinho de Rolemã Que Não Tinha Rolimã

 


Crônica – O Carrinho de Rolemã Que Não Tinha Rolimã

Pirassununga foi um sopro.
Poucos meses, talvez poucos mais de um ano… mas suficiente para virar uma galáxia inteira dentro da cabeça de um garoto de nove anos. Daquelas memórias que não pedem licença: simplesmente voltam, se instalam e acendem a luz.


Eu sempre digo que vivi pouco ali, mas vivi o suficiente para ser moldado.

E como molda uma cidade assim!
Chega a ser engraçado: falo, falo, falo… e sempre acho que “foi pouco tempo”. Mas olha só o tanto de coisa que me atravessou naquela época. Tudo novo, tudo grande, tudo mágico. Uma infância acelerada, sem aviso e sem manual.

E entre essas lembranças, tem uma que sempre volta com cheiro de óleo queimado: o carrinho de rolimã que não tinha rolimã.

Porque, veja bem… apesar de eu viver pendurado em desmanche, ferro-velho, oficina, sucata — sempre acompanhando meu pai, Seu Wilson — nunca conseguimos montar um carrinho de madeira com rodinhas de rolamento como as outras crianças tinham. Talvez por falta dos rolamentos, talvez porque a vida resolveu improvisar.



E improviso era com meu pai mesmo.

Um dia, no meio dos restos de metal que eram quase uma extensão natural da nossa casa, ele encontra uma carcaça de carro infantil, de ferro, pesada, torta, mas com alma. Bastou um olhar entre nós dois para começar o ritual: martelar, lixar, soldar, pintar, alinhar, conversar, rir — aquelas oficinas de fundo de quintal que eram mais escola do que qualquer sala de aula.

E assim nasceu meu bólido.
Meu foguete de ladeira.
Meu carrinho sem rolamentos, mas com personalidade.

Na rua onde vivíamos — última rua da cidade, terminando num campinho de futebol meio improvisado — as tardes ganhavam um brilho especial. Era uma ladeira que parecia Everest para o menino que eu era: íngreme, cheia de pequenas vitórias e tombos.

Entre uma descida e outra, havia ainda um bônus cinematográfico: vez ou outra pousava um helicóptero militar no campo. Para um menino de nove anos, aquilo era simplesmente o fim do mundo — no melhor sentido possível. O vento levantando poeira, o barulho das hélices, o cheiro de querosene, os soldados descendo…
Eu olhava aquilo e pensava: um dia vou pilotar um desses.

Mas voltava para o meu carrinho de ferro.
Porque o dever chamava: a ladeira me esperava.

E lá ia eu, empurrando o trambolho ladeira acima, suando, rindo, tropeçando. E depois, ladeira abaixo, voando, vibrando, às vezes capotando — mas sempre feliz. O campo de futebol servia de freio natural: ou eu caía estatelado, ou parava triunfante, rei de um mundo que só existia até o pôr do sol.

Era simples.
Era rústico.
Era perfeito.

E hoje, olhando pra trás, eu entendo: não era só um carrinho.
Era liberdade recém-adquirida, era o primeiro projeto pai e filho, era uma aula de vida, era a emoção crua de ser criança nos anos 80.

E talvez por isso Pirassununga dure tão pouco no calendário, mas tanto na alma.



A memória falha, mas acho que a rua se chamava Alzira e ficava no jardim Pinheiro...

sábado, 16 de junho de 2012

Aquario de Genova Parque da Expo

Parque da Expo em Génova

Historicamente Génova foi a capital de uma republica marítima que durante muitos anos, dominou esta parte do Mar Mediterraneo, com um grande porto é actualmente uma das cidades mais ricas da Itália.

Em 1992 foi escolhida para abrigar a EXPO, foi então criado um parque com diversas atracões que fariam parte desta exposição: dessa iniciativa surgiram o Submarino Museu U 518 Nazário Sauro, o museu marítimo, o navio pirata Neptuno, o aquário de Génova e varias outras pequenas iniciativas.



Para quem ama ver peixes, este aquário é fantástico construído na forma de um barco, anda-se por diversos ambientes, vendo de forma didática aquários com espécies representativas do globo todo.
.

sábado, 5 de maio de 2012

Bellacosa Mainframe: Série DevOps e Modernização no IBM Z

 

Bellacosa Mainframe apresenta DEVOPS e Modernização IBM Z

Bellacosa Mainframe: Série DevOps e Modernização no IBM Z


1️⃣ DevOps no IBM Z – Pipeline E2E com GitLab e DBB

Origem:
O pipeline end-to-end no mainframe integra GitLab, IBM DBB, IDz, UrbanCode Deploy e ADDI. Ele automatiza desde o coding até o monitoring, garantindo qualidade e velocidade na entrega.

Exemplo:

  • Desenvolvedor altera um módulo COBOL

  • DBB identifica dependências

  • Jenkins compila apenas os módulos impactados

  • UrbanCode Deploy publica o artefato nos ambientes de teste/prod

  • IZOA (IBM Z Operational Analytics) monitora métricas em tempo real

Dicas:

  • Use build incremental do DBB para reduzir tempo

  • Crie repositórios de componentes separados para acelerar deploys

  • Monitore cada fase com dashboards GitLab/IDz

Curiosidades & Easter Eggs:

  • Em grandes bancos, pipelines E2E reduzem meses de entrega para semanas

  • Alguns times chamam o DBB de “o Sherlock Holmes do COBOL” por identificar dependências invisíveis

Fofoquices:

  • Equipes que adotam CI/CD moderno relatam menos reuniões de emergência às sextas-feiras.


2️⃣ Migrando z/OS para Git – Code Page & Copybooks

Origem:
A migração de código z/OS para Git envolve conversão de code pages (EBCDIC → ASCII) e gestão de copybooks compartilhados.

Exemplo:

  • Migrar 1000 módulos COBOL

  • DBB inicializa metadados de dependências

  • Copybooks são publicados via UrbanCode Deploy garantindo compatibilidade

Dicas:

  • Configure triggers de publicação de copybooks no pipeline

  • Use repos Git separados para código x copybooks

  • Automatize conversão de code pages para evitar erros silenciosos

Curiosidades & Easter Eggs:

  • Alguns copybooks têm nomes que datam da década de 80 – um verdadeiro “Fósseis do COBOL”

  • Git permite versionar copybooks e gerar histórico de mudanças detalhado, algo impossível no Changeman

Fofoquices:

  • Times antigos choram quando veem um merge automático de copybooks funcionando perfeitamente — “parece mágica”.


3️⃣ Branching e Release-Based Development

Origem:
Modelos de branching em mainframe podem ser complexos. O uso de Feature, Development e Release branches permite controle fino e CI/CD confiável.

Exemplo:

  • Branch Feature: desenvolvedor adiciona nova função

  • Branch Development: integração com outros módulos

  • Branch Release: build completo e deploy controlado

Dicas:

  • Não use branch única em produção

  • Faça merges frequentes para reduzir conflitos

  • Adote release-based workflow para previsibilidade

Curiosidades & Easter Eggs:

  • Alguns times chamam o branch de Release de “a linha da vida”, porque qualquer erro ali pode travar todo o mainframe

  • Git no Z permite trazer práticas modernas para décadas de código legado

Fofoquices:

  • Programadores mais antigos ainda guardam planilhas de branches antigas “para o caso de emergência”


4️⃣ IBM ADDI – Business Rule Discovery e Integração CI/CD

Origem:
ADDI permite descobrir regras de negócio ocultas em sistemas legados, mapear dependências e alimentar pipelines CI/CD.

Exemplo:

  • Projeto de exemplo gera workbook de regras de negócio

  • Keywords são mapeadas e inventário de termos é criado

  • Pipeline Jenkins lê essas informações para validar mudanças

Dicas:

  • Integre ADDI antes do build para shift-left

  • Gere inventário de pacotes de negócio para rastreabilidade

  • Use ADDI junto com DBB para builds inteligentes

Curiosidades & Easter Eggs:

  • Alguns nomes de regras vêm de decisões dos anos 70 – dá para descobrir a história da empresa!

  • Ferramenta ajuda a revelar “regra oculta” que ninguém sabia que existia

Fofoquices:

  • Times chamam ADDI de “detective de regras”. Quando falha, todo mundo olha para o DBA como se fosse culpado.


5️⃣ Azure DevOps + Wazi as a Service no IBM Z

Origem:
Com Wazi aaS e Azure DevOps, é possível provisionar instâncias z/OS na nuvem e integrá-las em pipelines modernos.

Exemplo:

  • IDz conectado a Wazi aaS

  • Git + Azure DevOps Pipeline executa build e deploy

  • Time remoto pode trabalhar sem precisar acessar LPAR físico

Dicas:

  • Wazi aaS acelera onboarding de novos desenvolvedores

  • Padronize pipelines híbridos para mainframe + cloud-native

  • Aproveite isolamento de ambientes para testes seguros

Curiosidades & Easter Eggs:

  • O nome Wazi vem do termo “simplicidade” em alguns dialetos africanos

  • Times contam que criar instância z/OS em nuvem é mais rápido que abrir café no mainframe físico

Fofoquices:

  • Novos devs acham mágico ver COBOL compilando em cloud, achando que o mainframe “viajou no tempo”.


6️⃣ Testes Unitários e Code Coverage no IBM Z

Origem:
O uso de zUnit e Code Coverage integrado ao CI/CD é essencial para qualidade e confiabilidade.

Exemplo:

  • zUnit executa testes unitários

  • DBB identifica módulos impactados

  • Code Coverage gera métricas e falha o build se critério mínimo não for atendido

Dicas:

  • Configure build incremental para testes rápidos

  • Versione testes no Git como qualquer outro código

  • Combine zUnit + DBB + Jenkins para pipeline robusto

Curiosidades & Easter Eggs:

  • COBOL unit tests eram considerados “impossíveis” até alguns anos atrás

  • Alguns times chamam zUnit de “pequeno herói silencioso”, porque pega bugs que ninguém percebe

Fofoquices:

  • Equipes que adotam testes unitários relatam menos reuniões de emergência às sextas-feiras (repetido, mas verdadeiro!).


7️⃣ Packaging e Deployment Modernos

Origem:
Para CI/CD moderno, é crucial desacoplar build, packaging e deploy, usando repositórios de artefatos e componentização.

Exemplo:

  • Build → Package → Deploy em pipeline desacoplado

  • Artifact Repository armazena pacotes prontos para múltiplos ambientes

  • UrbanCode Deploy realiza deploy controlado e rastreável

Dicas:

  • Crie artefatos versionados

  • Mantenha build independente do deploy

  • Adoção de padrões reduz falhas em produção

Curiosidades & Easter Eggs:

  • Alguns times chamam artefatos versionados de “legado moderno”

  • Pipeline desacoplado permite experimentar deploy em paralelo sem arriscar produção

Fofoquices:

  • Desenvolvedores que criam pipelines desacoplados ganham fama de “magos do COBOL” no time


Resumo do Estilo Bellacosa Mainframe

O que aprendemos nesta série:

  1. Pipelines E2E + GitLab + DBB aumentam produtividade e confiabilidade

  2. Migração para Git requer atenção a code pages e copybooks

  3. Branching e release-based workflows tornam CI/CD previsível

  4. ADDI descobre regras de negócio e alimenta pipelines

  5. Wazi aaS + Azure DevOps traz mainframe para a nuvem

  6. zUnit + Code Coverage garante qualidade e shift-left

  7. Build, packaging e deploy desacoplados promovem flexibilidade

Curiosidades gerais:

  • Alguns copybooks têm mais de 40 anos

  • Pipelines modernos reduzem meses de entrega para dias

  • Ferramentas modernas tornam mainframe mais “cool” para novos devs

Easter Eggs & Fofoquices:

  • Times chamam DBB de Sherlock Holmes

  • ADDI de detective de regras

  • zUnit de herói silencioso

  • Artefatos versionados de “legado moderno”


sexta-feira, 4 de maio de 2012

🔥 Como extrair listagens SMF no IBM mainframe z/OS (sem romantizar, sem mistério)

 


🔥 Como extrair listagens SMF no IBM mainframe z/OS (sem romantizar, sem mistério)


Conhecimento básico sobre aplicações distribuídas explicado para quem confia em SMF mais do que em dashboard bonito





☕ 01:37 — Antes de existir “observabilidade”, já existia verdade

No mundo cloud, observabilidade é:

  • moda

  • ferramenta

  • assinatura mensal

No mainframe, observabilidade sempre foi:

SMF ou nada

Se você quer entender aplicações distribuídas, mensageria, performance e incidentes, aprender a extrair, ler e interpretar SMF é obrigação moral de todo mainframer.


1️⃣ Breve história: SMF não foi feito para te agradar 🧬

O System Management Facility (SMF) nasceu para:

  • auditoria

  • capacidade

  • cobrança

  • performance

  • verdade operacional

📌 Comentário Bellacosa:
SMF não explica.
SMF prova.


2️⃣ Onde os dados SMF ficam no z/OS 🗂️

Formas comuns de armazenamento:

1️⃣ Datasets sequenciais ativos

  • SYS1.MANx (MAN1, MAN2, MAN3)

  • Gravados continuamente

  • Reutilizados em rotação

2️⃣ SMF em log stream (z/OS moderno)

  • Via System Logger

  • Mais seguro

  • Mais escalável

📌 Easter egg:
Quem ainda lê MANx direto está vivendo perigosamente.


3️⃣ Tipos de SMF mais usados (tradução prática)

Tipo SMFPara quê serve
30Uso de CPU por job
70–78RMF (capacidade, CPU, I/O)
80Segurança
110CICS
116MQ
120WebSphere
122DB2

🔥 Comentário:
Distribuído chama isso de “telemetria”.
Você chama de SMF desde sempre.


4️⃣ Extração clássica: IFASMFDP (o velho confiável) 🛠️

O utilitário padrão para descarregar SMF é o IFASMFDP.

Exemplo básico de JCL para extrair SMF

//SMFDUMP JOB (ACCT),'EXTRAI SMF', // CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //STEP1 EXEC PGM=IFASMFDP //SYSPRINT DD SYSOUT=* //SYSIN DD * DUMP OUTDD(DUMP1,TYPE(116)) /* //DUMP1 DD DSN=USER.SMF.MQ.DUMP, // DISP=(NEW,CATLG), // SPACE=(CYL,(50,10)), // DCB=(RECFM=VB,LRECL=32756)

📌 O que isso faz:
Extrai SMF tipo 116 (IBM MQ) para um dataset legível por programas de análise.

😈 Easter egg:
Esse “DUMP” é mais útil que muito core file moderno.


5️⃣ Extraindo de Log Stream (modo adulto) 🚀

Quando SMF está no System Logger, usa-se:

//STEP1 EXEC PGM=IFASMFDP //SYSIN DD * DUMP FROM(LOGSTREAM) LOGSTREAM(SMF.LOGSTREAM.NAME) OUTDD(DUMP1) TYPE(30,70,116) /*

🔥 Comentário Bellacosa:
Se você usa log stream, você dorme melhor.


6️⃣ Como “baixar” SMF para fora do mainframe 🌍

Depois de extrair para dataset:

Opções clássicas:

  • FTP (modo binary!)

  • SFTP

  • NDM

  • Tools corporativas

📌 Regra sagrada:
Nunca transfira SMF em ASCII.

😈 Easter egg traumático:
SMF convertido errado vira ficção científica.


7️⃣ Como ler SMF (spoiler: não é com os olhos) 👀

SMF não é texto.
Você precisa de:

  • Sort (DFSORT)

  • Programas de leitura

  • Ferramentas (IBM, vendor ou caseiras)

Exemplo simples com DFSORT (filtrando registros)

//SORTSMF EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD DSN=USER.SMF.MQ.DUMP,DISP=SHR //SORTOUT DD DSN=USER.SMF.MQ.FILTRADO, // DISP=(NEW,CATLG), // SPACE=(CYL,(20,5)) //SYSIN DD * SORT FIELDS=COPY /*

📌 Comentário:
Sort é o SQL original do mainframe.


8️⃣ Lendo SMF como observabilidade distribuída 🧠

Mentalidade correta:

  • Não leia registro isolado

  • Monte linha do tempo

  • Correlacione com:

    • batch

    • CICS

    • MQ

    • APIs

🔥 Tradução Bellacosa:
Trace distribuído = SMF correlacionado.


9️⃣ Erros clássicos (não faça isso) ⚠️

❌ Ler SMF sem objetivo
❌ Ajustar sistema sem evidência
❌ Ignorar horário
❌ Confiar só em alertas
❌ Jogar fora dados históricos

😈 Comentário ácido:
Quem não guarda SMF está escolhendo não aprender.


🔟 Guia de estudo para mainframers curiosos 📚

Conceitos

  • SMF architecture

  • RMF

  • Capacity planning

  • Mensageria (MQ)

  • Observabilidade

Exercício Bellacosa

👉 Extraia SMF tipo 116
👉 Monte timeline de PUT/GET
👉 Compare com fila crescendo


🎯 Aplicações reais desse conhecimento

  • Performance tuning

  • Diagnóstico de incidentes

  • Auditoria

  • Integração mainframe-cloud

  • SRE corporativo


🖤 Epílogo — 02:58, tudo explicado

Cloud vende visibilidade.
Mainframe sempre entregou evidência.

El Jefe Midnight Lunch assina:
“SMF não é difícil. Difícil é trabalhar sem ele.”

 

quarta-feira, 2 de maio de 2012

⏰🔥 SRE explicado para quem já foi acordado por batch quebrado

 


⏰🔥 SRE explicado para quem já foi acordado por batch quebrado



02:47 — Introdução: quando o telefone tocava e você já sabia

Antes de existir SRE, já existia plantão.
Antes de “on-call rotation”, já existia pager, telefone fixo e operador nervoso.
Antes de “incident postmortem”, já existia a pergunta clássica:

“O que mudou desde ontem?”

Site Reliability Engineering (SRE) não nasceu no Google.
Nasceu no trauma coletivo de quem precisava manter sistema crítico em pé, custe o que custar.



1️⃣ O que é SRE (traduzido para dialeto mainframe)

SRE é aplicar engenharia para garantir:

  • Disponibilidade

  • Performance

  • Confiabilidade

  • Previsibilidade

Não é suporte.
Não é operação reativa.
É disciplina.

📌 Mainframer entende assim:

“Não apagar incêndio. Evitar que ele comece.”


2️⃣ O mito: SRE é coisa de cloud 😈

Mentira.

Mainframe já fazia SRE com:

  • SLAs rígidos

  • Janelas de batch

  • Planejamento de capacidade

  • Controles de mudança

  • Automação pesada

😈 Easter egg:
ITIL copiou metade disso e deu nome bonito.


3️⃣ SLIs, SLOs e SLAs (ou: como medir sem enganar)

SLI – Indicador

  • Tempo de resposta

  • Taxa de erro

  • Throughput

SLO – Objetivo

  • “99,9% das transações em até X ms”

SLA – Contrato

  • Multa

  • Diretoria

  • Dor

📎 Mainframer traduz:

“Se o fechamento não roda, tem reunião amanhã.”


4️⃣ Error Budget: a parte que o negócio nunca entendeu 💣

Error Budget =
100% − SLO

Se o sistema pode falhar 0,1% do tempo:

  • Você pode inovar

  • Pode mudar

  • Pode arriscar

Se estourar:

  • Congela mudança

  • Estabiliza

  • Arruma casa

😈 Easter egg:
No mainframe isso se chamava “congelamento pré-fechamento”.


5️⃣ Postmortem sem caça às bruxas 🧠

SRE prega:

  • Análise sem culpados

  • Foco no processo

  • Aprendizado real

Mainframer sabe:

“Sistema não quebra sozinho.”

📌 Curiosidade:
Quem caça culpado esconde problema.


6️⃣ Automação: batch, scripts e o futuro 🤖

SRE vive de automação:

  • Deploy automático

  • Rollback

  • Self-healing

  • Escala automática

Mainframe já fazia:

  • JCL

  • Restart automático

  • Schedulers

  • Abends tratados

😈 Easter egg:
JCL é Infrastructure as Code sem marketing.


7️⃣ Passo a passo para pensar como SRE (modo Bellacosa)

1️⃣ Defina o que é “funcionar”
2️⃣ Meça tudo que importa
3️⃣ Crie limites claros
4️⃣ Automatize o repetitivo
5️⃣ Aceite falhas pequenas
6️⃣ Aprenda com cada incidente
7️⃣ Melhore antes da próxima pancada


8️⃣ Guia de estudo para mainframers cansados 📚

Conceitos

  • SRE

  • SLIs / SLOs

  • Error Budget

  • Incident Management

  • Chaos Engineering

Ferramentas modernas

  • Instana

  • PagerDuty

  • Grafana

  • Kubernetes (sim…)


9️⃣ Aplicações práticas no mundo híbrido

  • Redução de chamadas noturnas

  • Menos stress operacional

  • Melhor diálogo com negócio

  • Estabilidade com inovação

  • Arquiteturas mais conscientes

🎯 Mainframer SRE vira pilar da empresa.


🔟 Curiosidades que doem 😬

  • 100% disponível não existe

  • Mudança sem métrica é aposta

  • Automatizar erro escala desastre

  • Confiabilidade custa tempo e dinheiro

📌 Verdade dura:
Sistema crítico exige humildade técnica.


11️⃣ Comentário final (05:31, céu clareando)

SRE não é moda.
É sobrevivência profissional.

Se você já:

  • Dormiu mal por batch quebrado

  • Evitou mudança perto do fechamento

  • Confiou mais em histórico do que em promessa

Então você já era SRE, antes do nome existir.

🖤 El Jefe Midnight Lunch encerra a série:
Confiabilidade não se improvisa. Se constrói.