Translate

Mostrar mensagens com a etiqueta mqseries. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta mqseries. Mostrar todas as mensagens

quinta-feira, 28 de maio de 2026

☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN

Bellacosa Mainframe apresenta um checklist de RCA para sysprog junior


☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN

Como Evoluir de Apagador de Incêndios para Caçador de Causas Raiz

A maioria dos Sysprogs juniores aprende primeiro a resolver incidentes.

Poucos aprendem a impedir que eles aconteçam novamente.

O objetivo deste checklist é desenvolver a mentalidade de investigação que transforma um operador técnico em um verdadeiro engenheiro de confiabilidade.


🔍 NÍVEL 1 — FUNDAMENTOS DO INVESTIGADOR

Conhecer a arquitetura do ambiente

☐ Entender o fluxo completo da aplicação

☐ Conhecer as LPARs existentes

☐ Entender Sysplex

☐ Conhecer JES2/JES3

☐ Entender CICS

☐ Entender DB2

☐ Entender MQ

☐ Conhecer Storage Management

☐ Entender WLM

☐ Conhecer SDSF profundamente

Objetivo

Parar de enxergar componentes isolados e começar a enxergar o ecossistema.


📋 NÍVEL 2 — COLETA DE EVIDÊNCIAS

Antes de agir:

☐ Registrar horário exato do incidente

☐ Identificar quem reportou

☐ Verificar impacto

☐ Capturar mensagens de erro

☐ Salvar logs

☐ Salvar SYSLOG

☐ Salvar JESMSGLG

☐ Salvar JESJCL

☐ Salvar JESYSMSG

☐ Registrar alterações recentes

☐ Verificar deploys recentes

Regra de ouro

Nunca altere o ambiente antes de coletar evidências.


🔥 NÍVEL 3 — ANÁLISE JES2

☐ Verificar initiators

☐ Verificar classes

☐ Verificar backlog

☐ Verificar spool

☐ Verificar HOLDs

☐ Verificar jobs looping

☐ Verificar jobs aguardando recursos

☐ Verificar ENQ contention

☐ Verificar mensagens $HASP

Pergunta obrigatória

O problema começou no JES2 ou chegou até ele?


💾 NÍVEL 4 — STORAGE E MEMÓRIA

☐ Verificar CSA

☐ Verificar ECSA

☐ Verificar SQA

☐ Verificar ESQA

☐ Verificar Private Area

☐ Procurar storage leaks

☐ Analisar crescimento anormal

☐ Verificar mensagens IEA e IEF

☐ Consultar RMF

Atenção

Muitos "problemas de sistema" são apenas vazamentos de memória.


⚡ NÍVEL 5 — PERFORMANCE

☐ Verificar CPU

☐ Verificar I/O

☐ Verificar Paging

☐ Verificar DASD

☐ Verificar Coupling Facility

☐ Verificar WLM

☐ Verificar gargalos

☐ Comparar com baseline

☐ Analisar tendências

Objetivo

Entender se a degradação é sintoma ou causa.


🖥️ NÍVEL 6 — RCA EM CICS

☐ Verificar transações lentas

☐ Verificar tasks pendentes

☐ Verificar Short On Storage

☐ Verificar TD Queues

☐ Verificar TS Queues

☐ Verificar DB2 Attach

☐ Verificar MQ Attach

☐ Verificar abends

☐ Verificar dumps

☐ Analisar traces

Nunca conclua

"CICS está lento"

sem descobrir:

"POR QUE está lento?"


🗄️ NÍVEL 7 — RCA EM DB2

☐ Verificar deadlocks

☐ Verificar lock escalation

☐ Verificar SQLCODEs

☐ Verificar buffer pools

☐ Verificar índices

☐ Procurar full table scan

☐ Verificar RUNSTATS

☐ Verificar REORG pendente

☐ Verificar crescimento de tabelas

Regra

Muitos problemas de CICS são, na verdade, problemas de DB2.


📬 NÍVEL 8 — RCA EM MQ

☐ Verificar Queue Depth

☐ Verificar canais

☐ Verificar backlog

☐ Verificar consumidores

☐ Verificar produtores

☐ Verificar DLQ

☐ Verificar mensagens presas

☐ Verificar timeouts

Lembre-se

Fila cheia normalmente é consequência.

Raramente é a causa raiz.


📊 NÍVEL 9 — OBSERVABILIDADE

☐ Utilizar OMEGAMON

☐ Utilizar RMF

☐ Utilizar SMF

☐ Utilizar NetView

☐ Utilizar Sysview

☐ Criar dashboards

☐ Definir baseline

☐ Identificar anomalias

☐ Correlacionar eventos

Meta

Parar de reagir.

Começar a prever.


🔎 NÍVEL 10 — TÉCNICAS DE INVESTIGAÇÃO

Five Whys

☐ Aplicar os 5 Porquês


Timeline Analysis

☐ Construir linha do tempo


Event Correlation

☐ Correlacionar eventos


Impact Analysis

☐ Medir impacto real


Trend Analysis

☐ Procurar recorrência


🤖 NÍVEL 11 — AUTOMAÇÃO E PREVENÇÃO

☐ Automatizar alertas

☐ Automatizar coleta de evidências

☐ Automatizar correções simples

☐ Criar scripts REXX

☐ Criar procedimentos de recuperação

☐ Integrar com SA z/OS

☐ Integrar com NetView

☐ Criar runbooks

Objetivo

Não resolver mais rápido.

Resolver menos vezes.


📚 NÍVEL 12 — CONHECIMENTO HISTÓRICO

☐ Manter base de incidentes

☐ Documentar RCA

☐ Criar Wiki interna

☐ Registrar lições aprendidas

☐ Catalogar soluções

☐ Criar biblioteca de dumps

☐ Registrar padrões recorrentes

Ouro do Sysprog

Experiência documentada vale mais que memória.


🧠 NÍVEL 13 — MENTALIDADE DE MESTRE

Antes de qualquer ação pergunte:

☐ O que aconteceu?

☐ Quando aconteceu?

☐ Quem foi impactado?

☐ O que mudou?

☐ Isso já aconteceu antes?

☐ O que os logs mostram?

☐ O que os dados mostram?

☐ Estou tratando sintoma ou causa?

☐ Como impedir recorrência?

☐ O que aprendi hoje?


🏆 CHECKLIST FINAL DO SYSprog MESTRE

Quando um incidente ocorrer:

❌ Não reinicie imediatamente

❌ Não assuma conclusões

❌ Não culpe usuários

❌ Não culpe desenvolvedores

❌ Não culpe infraestrutura

✅ Colete evidências

✅ Analise dados

✅ Correlacione eventos

✅ Pergunte "por quê?"

✅ Encontre a causa raiz

✅ Elimine a recorrência

✅ Documente a descoberta

✅ Compartilhe conhecimento


☕ Regra Suprema do Bellacosa Mainframe

"O Padawan reinicia o CICS.

O Sysprog investiga o dump.

O Mestre encontra a causa raiz.

O Arquiteto faz o problema desaparecer para sempre." 🚀💣🔥

 

terça-feira, 29 de julho de 2025

Os Principais Aplicativos do z/OS: Um Guia para padawans.

 

Bellacosa Mainframe apresenta os principais softwares no z/OS

Os Principais Aplicativos do z/OS: Um Guia para padawans.

4,424 followers

Salve jovem padawan, inspirado em meu Quiz sobre Z/OS para iniciantes, resolvei dar uma ajudinha com mais material de apoio, este artigo tem como objetivo apresentar com um pouco mais de rigor tecnico. O famoso Z/OS o sistema operacional dos sistemas operacionais. O conjunto de softwares, que tornam realidade toda a velocidade da Alta Plataforma, cuidado da segurança, continuedade e potência no processamento de Dados para milhões de pessoas ao redor do Globo.

No coração do mainframe IBM, o z/OS é o sistema operacional que sustenta algumas das infraestruturas mais críticas do mundo — bancos, governos, seguradoras, grandes varejistas, entre outros. Mas o que faz do z/OS um sistema tão poderoso não é apenas sua robustez, mas também o conjunto de aplicativos e subsistemas que o compõem.

Neste artigo, caro padawan compartilho os principais aplicativos do z/OS, com breves resumos, exemplos de uso e curiosidades históricas. Existem outros softwares, porém não serão listados neste artigo.


1. JES2 – Job Entry Subsystem

Resumo: Gerencia o fluxo de jobs batch no sistema.

História: Desde os primórdios do MVS, os subsistemas JES foram criados para organizar a fila de trabalhos enviados por JCL.

Exemplo: Quando você submete um job (SUBMIT JOB01.JCL), o JES2 é quem o recepciona, enfileira, imprime, armazena no spool e direciona para execução.

📝 Curiosidade: O JES3, com controle centralizado, foi amplamente usado por grandes data centers até ser descontinuado no z/OS 2.5 (RIP).


2. ISPF – Interactive System Productivity Facility

Resumo: Interface interativa em tela 3270 para navegação, edição e gerenciamento de arquivos. Para o terror da geração icones, cores e musiquinhas o 3270, normalmente se apresenta em Tela Negra com Caracteres verdes ao melhor estilo Matrix.

História: Criado nos anos 60 para melhorar a produtividade dos programadores. É uma IDE em linha de comando, apesar de nos atuais Emuladores 3270 é possivel usar o Mouse para apontar e clicar, servindo de atalho as ferramentas.

Exemplo: Editar um programa COBOL, visualizar um dataset, compilar, submeter jobs – tudo via ISPF Panels.

🎨 Curiosidade: Muitos o consideram o “Windows” do mainframe – mas em modo texto! Em grande verdade o Windows foi inspirado no MVS, na epoca do MS-DOS e seus comandos de linha.


3. TSO/E – Time Sharing Option / Extensions

Resumo: Permite aos usuários interagir com o z/OS em sessões simultâneas.

História: Introduzido como uma maneira de utilizar o sistema em modo interativo, antes apenas possível por batch e cartões perfurados. Graças a criação do Disco Rigido pela IBM e dos arquivos VSAM, permitindo muito mais navegabilidade no Sistema.

Exemplo: Digitar comandos como LISTC, ALLOCATE, RENAME diretamente no prompt do TSO.


4. SDSF – System Display and Search Facility

Resumo: Interface para visualizar spool de jobs, status, saída, logs, mensagens do sistema. Trabalha em conjunto com o JES2, numa anologia simples, pense no avô do Gerenciador de Tarefas do Windows na versão linha de comando.

Exemplo: Acompanhar a execução de um job, ler mensagens do JES, verificar uso de CPU.

🔍 Curiosidade: SDSF é indispensável para qualquer operador ou programador acompanhar jobs em tempo real, uso de memoria, programas em execução na CPU e espaço nos discos.


5. RACF – Resource Access Control Facility

Resumo: Sistema de controle de segurança de usuários, recursos e permissões no z/OS. O grande Xeriff do Mainframe, graças a ele, nossos dados são protegidos contra ataques Hacker.

História: Criado nos anos 60 como resposta à necessidade de controle mais rígido de acesso e evitar visitantes não convidados.

Exemplo: Definir que o usuário SILVA pode acessar o dataset FINA.APRIL.REPORT apenas em leitura.

🔐 Curiosidade: O RACF virou sinônimo de segurança em Mainframe, mesmo havendo outros como ACF2 e Top Secret.


6. DB2 for z/OS

Resumo: Banco de dados relacional robusto e altamente escalável.

História: Lançado em 1983, foi um dos primeiros RDBMS comerciais baseados no modelo relacional de Codd.

Exemplo: Aplicações bancárias acessam dados de contas via SQL: SELECT * FROM CLIENTES WHERE ID=123.

💡 Curiosidade: DB2 é um dos pilares da modernização no z/OS, integrando com APIs REST, Java e analytics. Existem versões para todas as outras plataformas, considerado o REI dos Bancos de Dados Relacionais.


7. CICS – Customer Information Control System

Resumo: Gerenciador de transações online de altíssima performance (OLTP).

História: Criado em 1969 para atender bancos e seguradoras, usa arquivos VSAM como apoio fundamental.

Exemplo: Sistema bancário de agência que consulta saldo ou realiza transferências em tempo real.

Curiosidade: É possível expor uma transação COBOL/CICS como um Web Service REST hoje com CICS TS.


8. VTAM – Virtual Telecommunications Access Method

Resumo: Controla a comunicação entre terminais 3270 e aplicações Mainframe.

História: Introduzido com o advento da computação distribuída e redes SNA.

Exemplo: Gerencia a sessão entre uma tela TN3270 no PC e o CICS no z/OS.


9. OMVS / USS – Unix System Services

Resumo: Permite ao z/OS executar comandos, scripts e programas no estilo Unix (POSIX).

História: Introduzido nos anos 90 com o objetivo de integrar melhor o mundo z/OS ao Unix/Linux.

Exemplo: Executar um shell script ou instalar um Java SDK no Mainframe.

🐧 Curiosidade: Muitos sistemas modernos (Node.js, Python, Git, z/OSMF) funcionam dentro do OMVS!


10. z/OSMF – z/OS Management Facility

Resumo: Interface web para administração, provisionamento e automação do z/OS.

História: Criado pela IBM para facilitar a administração gráfica e moderna do z/OS.

Exemplo: Criar workflows, administrar usuários RACF, provisionar ambientes CICS via navegador.

🌐 Curiosidade: Você pode administrar z/OS pelo navegador, inclusive integrando com Jenkins!


11. JCL – Job Control Language

Resumo: Linguagem que comanda a execução de programas no z/OS.

Exemplo: Um job típico chama um programa COBOL, redireciona entrada/saída, especifica parâmetros. Este exemplo é bem simples, sendo apenas ilustrativo, em breve apresentarei um Quiz sobre JCL e mais detalhes da sua escrita e funcionamento.

Explicando por cima, ele é um cartão job com apenas um Step, chamando um arquivo de entrada para leitura e gerando SYSOUT no Spool do SDSF.

//JOB1    JOB 1,'EXEMPLO',
//        CLASS=A,MSGCLASS=X
//STEP1   EXEC PGM=PROGCALC
//INFILE  DD   DSN=ENTRADA.DADOS,DISP=SHR
//OUTFILE DD   SYSOUT=*
//SYSOUT  DD   *

📜 Curiosidade: Embora antigo, o JCL é insubstituível no controle fino do ambiente, uma linguagem de programação interpreta, em formato de script, presente nos Mainframe desde a sua liberação no seculo passado.


Conclusão

Por ora, caro padawan chegamos ao final de nossa jornada para conhecer o z/OS, guarde isso na memoria, o ZOS não é apenas um "sistema operacional", mas um ecossistema robusto, onde cada aplicativo tem um papel essencial no processamento de dados em larga escala, com segurança, performance e confiabilidade.

Para o analista mainframe, conhecer esses aplicativos é como conhecer o seu campo de batalha. E quanto mais você entende como esses componentes se relacionam, mais se destaca como profissional.

Espero ter ajudado e caso surjam duvidas, não tenha receio, pergunte nos comentarios, que vamos enriquecendo este artigo. Ele é um trabalho em curso, vez por outro, revisarei e acrescentarei emendas e mais detalhes.

segunda-feira, 9 de janeiro de 2012

🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito



 🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito




1️⃣ Introdução: quando o monólito saiu da jaula

Mainframer raiz conhece bem o monólito confiável: CICS firme, DB2 consistente, batch noturno pontual como relógio suíço. Durante décadas, aplicação distribuída era vista como “coisa de Unix instável” ou “modinha client-server”.

Mas o mundo girou. A web cresceu, o mobile explodiu, a nuvem virou padrão e, de repente, o monólito começou a ser fatiado em serviços. Nasciam as aplicações distribuídas — e com elas, novos problemas… e velhos conceitos que o mainframe já conhecia muito bem.

💡 Easter egg: se você já lidou com VTAM, MQSeries e sysplex, você já entendeu aplicações distribuídas… só não sabia o nome moderno disso.



2️⃣ O que são aplicações distribuídas (sem buzzword)

Uma aplicação distribuída é aquela em que:

  • O processamento ocorre em vários nós

  • Cada parte da aplicação pode rodar em máquinas, containers ou regiões diferentes

  • A comunicação acontece por rede, não por memória compartilhada

Exemplos modernos:

  • Microservices em Kubernetes

  • APIs REST + filas (Kafka, MQ, RabbitMQ)

  • Frontend web → backend → banco → cache → serviços externos

No fundo, é o velho conceito de desacoplamento, agora amplificado.


3️⃣ Paralelos diretos com o mundo mainframe 🧠

Mundo MainframeMundo Distribuído
CICS TransactionMicroservice
MQSeriesEvent Streaming
SysplexCluster
SMF / RMFTelemetria / Observabilidade
AbendException distribuída
Batch encadeadoPipelines assíncronos

👉 Conclusão Bellacosa: mainframers não estão atrasados — estão adiantados há 30 anos.


4️⃣ Principais desafios (spoiler: não são novos)

🔹 Latência

No mainframe, o gargalo era I/O.
No distribuído, é rede + serialização + hops excessivos.

🔹 Falhas parciais

No mundo distribuído:

“Se algo pode falhar, vai falhar, mas só um pedaço.”

Isso lembra:

  • Regiões CICS indisponíveis

  • LPAR isolada

  • Subsystem down às 03:12 😈

🔹 Consistência

Aqui entra o famoso CAP Theorem — mas mainframer chama isso de:

“Escolher entre disponibilidade e integridade quando o caldo entorna.”


5️⃣ Conceitos essenciais que todo mainframer deve dominar

✔️ Comunicação síncrona vs assíncrona

  • Síncrona: REST, RPC (espera resposta)

  • Assíncrona: filas, eventos, fire-and-forget
    👉 MQ old school total.

✔️ Escalabilidade horizontal

  • Escalar mais instâncias, não máquinas maiores
    (trauma de quem pedia upgrade de MIPS aprovado em comitê 😅)

✔️ Observabilidade

  • Logs

  • Métricas

  • Traces distribuídos

📌 Curiosidade: SMF foi o avô do tracing moderno.


6️⃣ Passo a passo mental para entender qualquer sistema distribuído

1️⃣ Identifique quais serviços existem
2️⃣ Veja como eles se comunicam
3️⃣ Descubra onde estão os pontos de falha
4️⃣ Analise latência e dependências
5️⃣ Verifique quem é o dono do dado
6️⃣ Observe como o sistema se comporta quando algo cai

🧨 Dica Bellacosa: desligue mentalmente um serviço e pergunte
“O que quebra primeiro?”


7️⃣ Guia de estudo para mainframers curiosos 📚

Conceitos

  • Microservices vs Monólito

  • Event-driven architecture

  • Observabilidade

  • Resiliência e retries

Ferramentas modernas (com alma antiga)

  • Instana / Dynatrace → RMF da nuvem

  • Prometheus → SMF open source

  • Kafka → MQSeries com esteroides

  • Kubernetes → Sysplex com YAML


8️⃣ Aplicações práticas no dia a dia

  • Integrar mainframe com APIs modernas

  • Expor transações CICS como serviços

  • Monitorar ambientes híbridos

  • Diagnosticar falhas ponta a ponta

  • Atuar como tradutor cultural entre legado e cloud

🎯 Mainframer que entende distribuído vira peça-chave.


9️⃣ Comentário final (meia-noite, café frio ☕)

Aplicações distribuídas não são o fim do mainframe.
São apenas o mesmo problema antigo, rodando em mais lugares, com nomes novos e menos disciplina.

Quem sobreviveu a:

  • Batch quebrado em fechamento

  • Deadlock às 02h

  • Região CICS instável em dia útil

…tem todas as credenciais para dominar o mundo distribuído.

🖤 El Jefe Midnight Lunch aprova:
legado não é atraso — é memória de guerra.