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”


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

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

 

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

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.

 

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