☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta z os. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta z os. 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." 🚀💣🔥

 

domingo, 24 de maio de 2026

☕🖥️ A GRANDE ORQUESTRA DO IBM MAINFRAME — QUEM SÃO OS GUARDIÕES DO DATACENTER MAIS PODEROSO DO MUNDO? 🔥

 

Bellacosa Mainframe e a grande orquestra do IBM Mainframe

☕🖥️ A GRANDE ORQUESTRA DO IBM MAINFRAME — QUEM SÃO OS GUARDIÕES DO DATACENTER MAIS PODEROSO DO MUNDO? 🔥

A imagem mostra algo que muita gente fora do universo mainframe nunca entende direito:

👉 um ambiente IBM Mainframe NÃO funciona apenas com “programadores COBOL”.

Ele é praticamente uma cidade tecnológica viva.

Cada profissional controla uma parte crítica do ecossistema.
Quando tudo funciona… ninguém percebe.
Quando algo falha… bancos, governos, seguradoras, cartões, aeroportos e bolsas de valores podem literalmente parar.

Vamos entrar no “datacenter secreto” no estilo Bellacosa Mainframe. ☕💾


🧠 VISÃO GERAL DA EQUIPE MAINFRAME

Na prática, um grande ambiente IBM Z possui:

  • Operadores

  • SysProg

  • SysAdmin

  • Segurança RACF

  • Redes VTAM/TCPIP

  • Performance/Capacity

  • Automação

  • Gerentes do Computer Center

  • Desenvolvedores COBOL/PLI/Natural/Assembler

  • DBA DB2

  • Storage

  • Scheduler

  • Disaster Recovery

  • Middleware

Cada um possui poderes específicos.

E SIM…
há guerras silenciosas entre áreas. 😅


🧑‍💼 1. COMPUTER CENTER MANAGER

☕ “O Maestro do Datacenter”

É o comandante operacional.

Ele não necessariamente configura tudo…
mas coordena TUDO.


🎯 Conhecimento Básico

Precisa entender:

  • Mainframe architecture

  • SLA

  • Incident management

  • Capacity

  • Segurança

  • Auditoria

  • Gestão de crises

  • Escala 24x7

  • ITIL

  • Continuidade


🔥 Principais Atividades

  • Coordenar mudanças

  • Aprovar deploys críticos

  • Gerenciar incidentes severos

  • Controlar equipes

  • Planejar capacidade

  • Coordenar DRP (Disaster Recovery)


🛠️ Ferramentas

  • ServiceNow

  • Control-M

  • Omegamon

  • z/OSMF

  • Jira

  • CA7

  • Tivoli


📋 Responsabilidades

  • Garantir disponibilidade

  • Evitar indisponibilidade bancária

  • Controlar janelas batch

  • Aprovar mudanças críticas


🧨 Easter Egg

Em muitos bancos:

“Se o gerente do datacenter ligar de madrugada…
alguém vai perder o sono.”

😅


🤖 2. AUTOMATION ADMINISTRATOR

☕ “O Senhor dos Robôs do z/OS”

Esse cara automatiza o caos.

Sem ele:
o operador enlouquece.


🎯 Conhecimento Básico

  • REXX

  • NetView

  • System Automation

  • OPS/MVS

  • JES2

  • Console automation

  • SDSF


🔥 Principais Atividades

  • Automatizar mensagens

  • Reiniciar tasks automaticamente

  • Monitorar jobs

  • Criar respostas automáticas

  • Reduzir intervenção humana


🛠️ Ferramentas

  • IBM System Automation

  • CA OPS/MVS

  • NetView

  • REXX

  • SDSF


📋 Exemplo Real

Mensagem:

IEC161I DATA SET FULL

A automação pode:

  1. Detectar erro

  2. Abrir alerta

  3. Alocar novo volume

  4. Reiniciar processo

  5. Avisar operador

Tudo sozinho.

🔥


🧨 Curiosidade

Alguns ambientes possuem:

  • MAIS DE 100 MIL REGRAS AUTOMÁTICAS

Sim…
um “mini cérebro artificial” antes da IA moderna.


👨‍💻 3. SYSTEM PROGRAMMER (SYSPROG)

☕ “O Feiticeiro Supremo do Mainframe”

Esse é o mago negro do IBM Z.

Pouquíssimas pessoas chegam nesse nível.


🎯 Conhecimento Básico

Precisa dominar:

  • z/OS

  • JES2/JES3

  • IPL

  • PARMLIB

  • PROCLIB

  • VTAM

  • SMP/E

  • RACF

  • Dump analysis

  • APF

  • LPA

  • Catalog

  • Unix System Services

E muitas vezes:
Assembler.

😳


🔥 Principais Atividades

  • Instalar produtos IBM

  • Aplicar PTFs

  • Fazer IPL

  • Resolver abends sistêmicos

  • Ajustar performance

  • Gerenciar subsistemas


🛠️ Ferramentas

  • SMP/E

  • IPCS

  • SDSF

  • RMF

  • Omegamon

  • ISPF

  • HCD

  • z/OSMF


📋 Passo a Passo Real — IPL

Cenário:

Atualização crítica do z/OS.

Passos:

  1. Validar PARMLIB

  2. Verificar APF libraries

  3. Aplicar maintenance SMP/E

  4. Fazer backup

  5. Agendar janela

  6. Derrubar subsistemas

  7. Executar IPL

  8. Validar JES2

  9. Subir CICS/DB2

  10. Liberar produção


🧨 Easter Egg SysProg

Os SysProgs antigos dizem:

“Se você nunca derrubou um LPAR em produção…
você ainda é júnior.”

💀


🌐 4. NETWORK ADMINISTRATOR

☕ “O Guardião Invisível da VTAM”

Sem rede…
o terminal 3270 vira decoração.


🎯 Conhecimento Básico

  • VTAM

  • TCP/IP

  • SNA

  • OSA

  • HiperSockets

  • TN3270

  • FTP

  • MQ


🔥 Atividades

  • Configurar conectividade

  • Resolver timeout

  • Ajustar rotas

  • Integrar distribuído

  • Configurar criptografia


🛠️ Ferramentas

  • NETSTAT

  • VTAM commands

  • TCPIP stack

  • Wireshark

  • Omegamon Network


📋 Exemplo

Usuários não conseguem acessar CICS.

Investigação:

  1. TESTAR TN3270

  2. Verificar VTAM ACTIVE

  3. Validar TCPIP

  4. Conferir porta

  5. Analisar firewall

  6. Validar certificado TLS


🧨 Curiosidade

Muitos ambientes antigos ainda possuem:

  • SNA rodando em produção em 2026.

SIM.
Tecnologia dos anos 70 ainda movendo bilhões.

🔥


🔐 5. SECURITY ADMINISTRATOR

☕ “O Mestre do RACF”

Esse profissional controla:
quem pode tocar no quê.


🎯 Conhecimento Básico

  • RACF

  • ACF2

  • TopSecret

  • SAF

  • MFA

  • PassTickets

  • Digital Certificates


🔥 Atividades

  • Criar acessos

  • Auditar usuários

  • Segregar funções

  • Investigar violações

  • Configurar MFA


🛠️ Ferramentas

  • RACF commands

  • SMF

  • zSecure

  • CARLa

  • MFA Server


📋 Exemplo Passo a Passo

Novo analista COBOL:

  1. Criar USERID

  2. Associar GROUP

  3. Liberar TSO

  4. Liberar dataset

  5. Liberar CICS

  6. Validar DB2

  7. Ativar MFA


🧨 Easter Egg RACF

O maior medo de um sysprog:

ICH408I USER NOT AUTHORIZED

😅


📊 6. PERFORMANCE/CAPACITY SPECIALIST

☕ “O Economista do Mainframe”

Ele controla:
CPU = dinheiro.


🎯 Conhecimento

  • RMF

  • SMF

  • WLM

  • CPU tuning

  • IO tuning

  • Paging

  • Buffer pools


🔥 Atividades

  • Analisar gargalos

  • Planejar crescimento

  • Ajustar WLM

  • Reduzir MIPS/MSU

  • Evitar sobrecarga


🛠️ Ferramentas

  • RMF

  • MXG

  • Omegamon

  • Mainview

  • IntelliMagic


📋 Exemplo

Batch noturno atrasou.

Investigação:

  1. CPU saturation?

  2. IO contention?

  3. EXCP elevado?

  4. DB2 lock?

  5. Paging?

  6. Canal congestionado?


🧨 Curiosidade

Em bancos:

1% de otimização

milhões economizados.

💀


🖥️ 7. OPERATOR

☕ “O Piloto da Nave Mainframe”

Muita gente subestima o operador.

ERRO GRAVE.

Ele é quem mantém a operação viva 24x7.


🎯 Conhecimento Básico

  • JES2

  • SDSF

  • Console

  • Batch

  • CICS

  • IPL básico

  • Recovery

  • Procedures


🔥 Principais Atividades

  • Monitorar jobs

  • Responder mensagens

  • Controlar spool

  • Reiniciar tasks

  • Executar comandos

  • Acionar suporte


🛠️ Ferramentas

  • SDSF

  • HMC

  • Omegamon

  • NetView

  • Console z/OS


📋 Exemplo Real — Job Preso

Situação

Job travado há 4 horas.


Operador faz:

1. Verifica SDSF

ST
DA
QUEUE

2. Analisa mensagem

IEC501A

3. Descobre fita offline


4. Aciona storage


5. Monta volume


6. Responde console

R xx,YES

7. Job continua

🔥


🧨 Easter Egg Operador

Operador veterano consegue:

  • identificar problema “pelo barulho do console”.

Sim…
isso existe. 😅


👨‍💻 E OS DEVELOPERS?

☕ “Os Arquitetos do Negócio”

Os developers criam:

  • COBOL

  • PLI

  • Assembler

  • Natural

  • JCL

  • CICS

  • DB2


🎯 Conhecimento

  • Regras bancárias

  • Batch

  • Online

  • VSAM

  • SQL

  • APIs

  • MQ

  • Web Services


🔥 Atividades

  • Criar programas

  • Corrigir abends

  • Fazer tuning SQL

  • Integrar APIs

  • Modernizar legado


🛠️ Ferramentas

  • IDz

  • Endevor

  • Changeman

  • File-AID

  • Abend-AID

  • DB2 SPUFI


📋 Exemplo Real

PIX falhando.

Developer:

  1. Analisa logs

  2. Verifica MQ

  3. Confere DB2

  4. Debuga COBOL

  5. Ajusta timeout

  6. Faz bind DBRM

  7. Libera produção


💀 A VERDADE QUE NINGUÉM CONTA

No mainframe:

  • SysProg culpa rede

  • Rede culpa segurança

  • Segurança culpa developer

  • Developer culpa DB2

  • Operador culpa automação

  • Automação culpa mensagem IBM

  • IBM culpa maintenance faltando

😅


☕ O ECOSSISTEMA REAL

Um grande IBM Mainframe pode ter:

  • milhares de jobs/hora

  • petabytes

  • milhões de transações CICS

  • uptime absurdo

  • processamento financeiro global

E tudo depende dessa equipe funcionando como uma orquestra.


🧨 O MAIOR EASTER EGG DO MAINFRAME

A maioria das pessoas acha que:

“mainframe morreu.”

Enquanto isso…

  • bancos

  • cartões

  • bolsa

  • governos

  • aviação

  • seguradoras

continuam rodando em IBM Z silenciosamente.

💀🖥️☕

domingo, 17 de maio de 2026

☕🖥️ O SYSprog z/OS NÃO É “SÓ MAIS UM PROFISSIONAL DE TI” — É O ENGENHEIRO QUE IMPEDE O MUNDO DE PARAR ☕🖥️

 

Bellacosa Mainframe ilustra a importancia do Sysprog Mainframe

☕🖥️ O SYSprog z/OS NÃO É “SÓ MAIS UM PROFISSIONAL DE TI” — É O ENGENHEIRO QUE IMPEDE O MUNDO DE PARAR ☕🖥️

Existe uma frase silenciosa no universo corporativo que pouca gente fora do mainframe entende:

“Quando o mainframe para, a empresa inteira descobre que ele existia.”

E é exatamente aí que entra uma das profissões mais raras, mais complexas e mais subestimadas da tecnologia moderna:

o z/OS System Programmer.

Muita gente imagina TI como:

  • frontend colorido,
  • startup hype,
  • app mobile,
  • container,
  • influencer de LinkedIn falando “cloud-native”.

Enquanto isso…

em algum datacenter refrigerado absurdamente caro:

  • bilhões de transações financeiras continuam passando,
  • cartões continuam autorizando,
  • PIX continua existindo,
  • companhias aéreas continuam operando,
  • seguradoras continuam processando,
  • governos continuam funcionando.

E frequentemente tudo isso está apoiado em:

IBM Z + z/OS.


☕ O MAINFRAME NÃO MORREU. ELE VIROU INFRAESTRUTURA CIVILIZACIONAL.

O erro mais comum do iniciante é imaginar o mainframe como:

“computador velho dos anos 70”.

Na prática?

O IBM Z moderno possui:

  • criptografia por hardware,
  • IA embarcada,
  • Linux,
  • containers,
  • OpenShift,
  • APIs REST,
  • automação,
  • integração cloud híbrida,
  • throughput monstruoso,
  • uptime absurdo.

O mainframe não compete com notebook.

Ele compete com:

PARAR O MUNDO.


☕ O QUE UM z/OS SYSTEM PROGRAMMER REALMENTE FAZ?

O sysprog não é apenas “administrador”.

Ele é:

  • engenheiro operacional,
  • arquiteto de disponibilidade,
  • especialista em recuperação,
  • analista de performance,
  • guardião de segurança,
  • cirurgião de infraestrutura crítica.

É o profissional que:

  • instala,
  • mantém,
  • corrige,
  • automatiza,
  • protege,
  • recupera,
  • ajusta
    o z/OS.

Se um desenvolvedor cria a aplicação…

o sysprog garante:

que a infraestrutura continue respirando.


☕ EXEMPLO REAL — O CAOS QUE UM SYSprog EVITA

Imagine:

  • um banco internacional,
  • Black Friday,
  • milhões de acessos,
  • PIX em massa,
  • cartões autorizando em tempo real.

Agora imagine:

  • uma falha de storage,
  • perda de path FICON,
  • congestionamento WLM,
  • JES spool lotado,
  • RACF falhando autenticação.

O usuário final só verá:

“Aplicativo indisponível”.

Mas nos bastidores:

  • operadores entram em emergência,
  • sysprogs analisam RMF,
  • storage teams validam control units,
  • dumps começam a ser coletados,
  • IPLs são discutidos,
  • GDPS talvez seja ativado.

E é exatamente nessas horas que nasce o verdadeiro valor do sysprog.


☕ O MAIOR ERRO DO INICIANTE

O novato geralmente pensa:

“Vou aprender COBOL e pronto.”

Não.

O universo enterprise é MUITO maior.

O profissional moderno precisa entender:

  • sistema operacional,
  • segurança,
  • storage,
  • automação,
  • redes,
  • recuperação,
  • tuning,
  • workflows,
  • APIs,
  • cloud híbrida.

O z/OS moderno virou:

uma plataforma enterprise gigantesca.


☕ A TRILHA REAL PARA VIRAR SYSprog

Aqui está algo que pouca gente fala claramente:

Você NÃO vira sysprog em:

  • 2 semanas,
  • bootcamp mágico,
  • vídeo motivacional.

É uma construção gradual.


☕ FASE 1 — APRENDER A “LÍNGUA” DO MAINFRAME

Antes de tudo:

  • TSO/ISPF,
  • JCL,
  • SDSF,
  • datasets,
  • VSAM,
  • catálogo,
  • JES2.

Sem isso o aluno fica perdido.

É como tentar virar piloto sem entender painel de avião.


☕ DICA DE OURO

Muita gente tenta estudar apenas teoria.

Erro fatal.

Mainframe precisa:

laboratório.

Mesmo usando:

  • Hercules,
  • TK4/TK5,
  • zPDT,
  • ADCD,
  • ambientes educacionais,

o importante é:

  • errar,
  • quebrar,
  • restaurar,
  • analisar.

Sysprog nasce no troubleshooting.


☕ O VERDADEIRO TERROR: SMP/E

Todo sysprog veterano respeita uma entidade quase mística chamada:

SMP/E.

O sistema de manutenção do z/OS.

E aqui o iniciante descobre:

  • coexistência,
  • target zones,
  • distribution zones,
  • HOLDDATA,
  • APPLY,
  • ACCEPT,
  • regressões.

Um patch errado pode:

  • quebrar IPL,
  • destruir JES,
  • afetar RACF,
  • causar outage enterprise.

Por isso:

quem domina SMP/E vira ouro no mercado.


☕ RACF — A MURALHA DO IMPÉRIO

Hoje:

  • LGPD,
  • PCI,
  • compliance,
  • auditoria,
  • segurança bancária

são prioridades absolutas.

E no mainframe:

RACF é religião.

O sysprog moderno precisa entender:

  • perfis,
  • grupos,
  • permissões,
  • datasets,
  • certificados digitais,
  • SAF,
  • auditoria.

Porque segurança enterprise não aceita improviso.


☕ O SYSprog MODERNO PRECISA APRENDER PYTHON

Aqui vem o choque cultural.

Muita gente pensa:

“Mainframe é só COBOL.”

Errado.

Hoje o sysprog moderno usa:

  • Python,
  • APIs,
  • automação,
  • Ansible,
  • z/OSMF,
  • REST,
  • OpenShift.

O mundo mudou.

O profissional preso apenas em:

  • painel verde,
  • comandos manuais,
  • operação artesanal

começa a ficar para trás.


☕ O FUTURO É AUTOMAÇÃO

Antigamente:

  • sysprog fazia tudo manualmente.

Hoje:

  • pipelines automatizados,
  • workflows,
  • Infrastructure as Code,
  • provisionamento automático,
  • automação operacional

viraram tendência forte.

Por isso a IBM empurra:

  • Ansible for IBM Z,
  • z/OSMF,
  • OpenShift,
  • integração híbrida.

☕ WLM — O “CÉREBRO INVISÍVEL” DO z/OS

Uma das áreas mais fascinantes do mainframe moderno é o:

Workload Manager.

O WLM decide:

  • quem recebe CPU,
  • prioridade,
  • resposta,
  • throughput,
  • metas de serviço.

Enquanto sistemas distribuídos frequentemente brigam com escalabilidade…

o z/OS já fazia gerenciamento inteligente de workload há décadas.


☕ O UNIVERSO HARDCORE: IODF, IOCDS E FICON

Aqui chegamos no território lendário dos sysprogs veteranos.

Essa é a camada:

  • hardware,
  • canais,
  • control units,
  • topologia física,
  • storage enterprise.

Pouquíssimos profissionais dominam profundamente:

  • HCD,
  • IODF,
  • IOCDS,
  • FICON,
  • channel subsystem.

Quando alguém domina isso:

o mercado inteiro percebe.


☕ O FUTURO PROFISSIONAL PRECISA ENTENDER UMA VERDADE

Mainframe NÃO é tecnologia do passado.

Mainframe é:

tecnologia da continuidade operacional.

E isso muda completamente a mentalidade.

Enquanto startups pensam:

“deploy rápido”.

O mainframe pensa:

“não podemos parar”.


☕ A MENTALIDADE CERTA PARA CRESCER

O profissional que evolui no mainframe normalmente possui:

  • disciplina,
  • curiosidade,
  • paciência,
  • lógica,
  • gosto por troubleshooting,
  • gosto por documentação,
  • responsabilidade.

Porque:

ambiente enterprise não perdoa improviso.


☕ O QUE ESTUDAR HOJE?

Se eu aconselhasse alguém começando AGORA:

Base obrigatória

  • z/OS
  • TSO/ISPF
  • JCL
  • JES2
  • SDSF

Depois

  • RACF
  • SMP/E
  • USS
  • TCP/IP
  • SMS

Avançado

  • WLM
  • RMF
  • Sysplex
  • GDPS
  • HCD/IOCDS

Modernização

  • Python
  • REXX
  • Ansible
  • z/OSMF
  • APIs REST
  • OpenShift

☕ A IMPORTÂNCIA DO ZXPLORE

O ZXPLORE é extremamente forte porque organiza:

  • trilhas,
  • progressão,
  • fundamentos,
  • especializações.

Ela ajuda o aluno a:

  • não estudar aleatoriamente,
  • construir base sólida,
  • entender arquitetura enterprise.

E no mainframe:

base sólida vale mais que modinha tecnológica.


☕ CONCLUSÃO — O SYSprog É O “ENGENHEIRO CIVIL” DA COMPUTAÇÃO ENTERPRISE

Se o desenvolvedor constrói aplicações…

o sysprog sustenta:

  • a fundação,
  • a energia,
  • a segurança,
  • a continuidade,
  • a estabilidade.

Ele é o profissional que trabalha silenciosamente para garantir:

  • disponibilidade,
  • resiliência,
  • recuperação,
  • performance,
  • segurança.

E talvez essa seja a parte mais fascinante do universo IBM Z:

Enquanto o mundo inteiro fala sobre inovação…

o mainframe continua:

  • processando trilhões,
  • protegendo bancos,
  • sustentando governos,
  • mantendo infraestruturas críticas vivas.

Como diria no estilo Bellacosa Mainframe:

“Cloud impressiona em apresentações.
Mainframe impressiona quando o caos começa.” ☕🖥️

terça-feira, 7 de outubro de 2025

🔥☕ O MAINFRAME JÁ ERA CLOUD ANTES DA CLOUD EXISTIR 💾🏛️🌐

 

Bellacosa Mainframe apresenta o CICS Structure Intercomunication

🔥☕ O MAINFRAME JÁ ERA CLOUD ANTES DA CLOUD EXISTIR — A VERDADE QUE TODO SYSprog JUNIOR DESCOBRE QUANDO ENTENDE CICS STRUCTURE & INTERCOMMUNICATION 💾🏛️🌐



Durante anos, muita gente ouviu frases como:

  • “Mainframe é centralizado”

  • “CICS é legado”

  • “IBM Z é tecnologia antiga”

  • “Cloud substituiu o mainframe”

E então o padawan começa a estudar:

🔥 CICS Structure and Intercommunication.

Nesse momento acontece algo curioso.

Ele percebe:

💣 o IBM CICS já fazia computação distribuída enterprise MUITO antes da internet moderna, dos microsserviços, do Kubernetes e da cloud híbrida virarem moda.

E isso muda completamente sua visão sobre o mundo IBM Z.


☕ O ERRO CLÁSSICO DE QUEM ESTÁ COMEÇANDO

O iniciante normalmente imagina o CICS assim:

Usuário → COBOL → VSAM

Algo simples.
Linear.
Monolítico.

Mas o ambiente enterprise real é mais próximo disso:

Usuário
   ↓
TOR
   ↓
MRO / IRC
   ↓
AORs distribuídos
   ↓
Db2 / MQ / VSAM
   ↓
CICSPlex
   ↓
Sysplex
   ↓
Recovery / Routing / Balancing

E nesse instante o sysprog junior percebe:

🔥 o CICS é um ecossistema distribuído monstruosamente sofisticado.


🏛️ O CICS NÃO É “UM PROGRAMA”

Esse é o primeiro choque.

O CICS moderno:

💣 não é uma única região.

Ele pode possuir:

  • dezenas de regiões

  • múltiplos hosts

  • múltiplas LPARs

  • workloads distribuídos

  • failover automático

  • roteamento dinâmico

Tudo funcionando:

⚡ simultaneamente.


☕ O QUE É UMA REGIÃO CICS?

Uma região CICS:

🔥 é um address space do z/OS.

Ou seja:

  • possui memória própria

  • tasks próprias

  • recursos próprios

  • controle próprio

E roda:

💾 como Started Task ou Batch Job.


☕ O SYSprog JUNIOR DESCOBRE UMA VERDADE IMPORTANTE

O CICS:

❌ não é o sistema operacional.

Ele roda:

🏛️ SOBRE o z/OS.

Assim como:

  • Db2

  • MQ

  • JES2

  • VTAM

  • TCP/IP


💾 O CICS É “APENAS” MAIS UM WORKLOAD DO z/OS

Só que esse “workload”:

💣 movimenta o planeta financeiro.


🔥 TOR, AOR E FOR — A SEPARAÇÃO QUE MUDOU TUDO

Aqui começa a engenharia enterprise de verdade.


☕ TOR — TERMINAL OWNING REGION

Responsável por:

  • receber conexões

  • controlar sessões

  • entrada de usuários

  • roteamento

O TOR funciona como:

🚦 controlador de tráfego.


☕ AOR — APPLICATION OWNING REGION

Aqui mora:

  • COBOL

  • regras de negócio

  • Db2

  • MQ

  • VSAM

O AOR:

⚡ executa o trabalho pesado.


☕ FOR — FILE OWNING REGION

Especializada em:

  • VSAM

  • locking

  • controle de arquivos

  • integridade


💣 ISSO É GENIAL

Porque:

  • workload pode ser distribuído

  • funções podem ser separadas

  • gargalos podem ser evitados

  • escalabilidade aumenta absurdamente


🌐 MRO — O “SERVICE MESH INVISÍVEL” DO CICS

Quando o padawan aprende MRO:

🔥 sua mente explode.


☕ O QUE É MRO?

🌐 Multiregion Operation

Permite:

  • comunicação entre regiões CICS

  • dentro do mesmo z/OS

  • ou dentro do mesmo Sysplex


💾 O MAIS IMPRESSIONANTE

O MRO usa:

⚡ IRC — Interregion Communication.


☕ O IRC É A JOIA ESCONDIDA DO CICS

Porque:

  • comunicação é interna

  • não precisa TCP/IP

  • não precisa SNA

  • não precisa VTAM


💣 RESULTADO?

✅ baixa latência

✅ throughput monstruoso

✅ comunicação ultra rápida

✅ escalabilidade massiva


☕ O MRO É BASICAMENTE:

🔥 um “service bus interno” criado décadas antes da cloud moderna.


🌎 ISC — QUANDO O CICS APRENDEU A FALAR COM O MUNDO

Depois vem:

🌐 ISC — Intersystem Communication.


☕ O ISC CONECTA:

  • hosts diferentes

  • sistemas remotos

  • datacenters

  • ambientes distribuídos

Usando:

🔥 SNA / APPC / LU6.2


💾 ISSO ERA A “INTERNET IBM”

Muito antes:

  • APIs REST

  • HTTP moderno

  • cloud hybrid


☕ O ISC PERMITIU:

✅ ATMs nacionais

✅ agências distribuídas

✅ bancos globais

✅ processamento remoto

✅ integração CICS ↔ IMS


💣 COMPUTAÇÃO DISTRIBUÍDA REAL

Nos anos 80 e 90.
Quando muita gente ainda nem entendia redes corporativas direito.


🌐 IPIC — O CICS ENTRA NA ERA TCP/IP

O mundo mudou.
O TCP/IP venceu.
E o CICS evoluiu.

Nasce:

🔥 IPIC — IP Interconnectivity.


☕ AGORA O CICS CONVERSA VIA:

✅ TCP/IP

✅ APIs

✅ Linux

✅ OpenShift

✅ cloud

✅ microsserviços


💾 O CICS NÃO MORREU

Ele:

⚡ se modernizou.


🌉 CICS TRANSACTION GATEWAY — A PONTE ENTRE O PASSADO E O FUTURO

Agora entra:

🔥 CTG — CICS Transaction Gateway.


☕ O CTG É O “TRADUTOR”

Entre:

  • Java

  • .NET

  • aplicações web

  • APIs REST

e:

💾 o mundo CICS/COBOL.


☕ FLUXO MODERNO REAL

App Mobile
   ↓
API REST
   ↓
Java Spring
   ↓
CTG
   ↓
CICS
   ↓
COBOL
   ↓
Db2

💣 O USUÁRIO NÃO FAZ IDEIA

Que:

  • um COBOL de décadas atrás

  • respondeu sua operação bancária em milissegundos.


🏛️ CICSPLEX — O “KUBERNETES” QUE EXISTIA ANTES DO KUBERNETES

Quando o ambiente cresce absurdamente:

  • dezenas de regiões

  • múltiplos hosts

  • milhões de transações

entra:

🌐 CICSPlex.


☕ O CICSPLEX TRANSFORMA:

Múltiplos CICS:

⚡ em um único ambiente lógico.


💾 O CPSM FAZ:

✅ workload balancing

✅ failover

✅ gerenciamento centralizado

✅ roteamento dinâmico

✅ monitoramento


💣 ISSO É ORQUESTRAÇÃO ENTERPRISE

Muito antes:

  • Kubernetes

  • OpenShift

  • cloud orchestration


☕ O SYSprog JUNIOR COMEÇA A ENTENDER

Que o IBM Z:

❌ nunca foi “parado no tempo”.

Na verdade:

🔥 ele estava anos à frente.


🌐 O CICS JÁ FAZIA:

✅ clusterização

✅ workload balancing

✅ comunicação distribuída

✅ middleware enterprise

✅ failover automático

✅ integração híbrida

✅ service orchestration

✅ APIs corporativas

Décadas antes:

  • da cloud moderna

  • dos microsserviços

  • do service mesh

  • do Kubernetes


💾 O GRANDE SEGREDO DO MAINFRAME

O mundo moderno reinventou conceitos que:

🏛️ o IBM Z já dominava há décadas.


☕ ENQUANTO MUITOS SISTEMAS MODERNOS:

  • quebram facilmente

  • perdem consistência

  • sofrem downtime

  • escalam mal

O CICS continua:

⚡ processando bilhões de transações silenciosamente.


💣 O PADAWAN FINALMENTE ENTENDE

O CICS:

❌ não é apenas EXEC CICS SEND MAP.

Ele é:

🌐 uma plataforma transacional distribuída de missão crítica.


🏛️ CONCLUSÃO BELLACOSA MAINFRAME™

Quando um sysprog junior realmente entende:

  • MRO

  • IRC

  • ISC

  • IPIC

  • CTG

  • CICSPlex

  • regiões CICS

ele percebe algo impressionante:

🔥 o mainframe nunca ficou para trás.

Na verdade:

💾 o restante da indústria passou décadas tentando reinventar conceitos que o IBM Z já utilizava silenciosamente desde muito antes da explosão da computação cloud moderna.

quarta-feira, 18 de setembro de 2024

AIOps : Quando um Programador Embarca no Seaview e Descobre que o Verdadeiro Monstro do Oceano Não é um Polvo Gigante.

Bellacosa Mainframe apresenta o aiops

☕ Um Café no Bellacosa Mainframe

AIOps sem Mistérios para Programadores COBOL

Quando um Programador Embarca no Seaview e Descobre que o Verdadeiro Monstro do Oceano Não é um Polvo Gigante... É uma Anomalia de Performance Escondida Entre Milhões de Métricas

"Profundidade: 8.000 metros."

"Pressão externa: centenas de atmosferas."

"Silêncio absoluto."

No fundo do oceano não existe espaço para improvisação.

Não existe Ctrl+C.

Não existe reboot.

Não existe "vamos tentar novamente amanhã".

Uma pequena falha...

...e toda a missão termina.

Curiosamente, é exatamente assim que funciona um IBM Z.

Enquanto milhões de pessoas compram, transferem dinheiro, usam cartões, fazem PIX, reservam passagens e movimentam bolsas de valores, o mainframe continua trabalhando silenciosamente nas profundezas da infraestrutura mundial.

É justamente aí que nasce o universo do AIOps, do Performance Management e do Capacity Planning.

Prepare seu uniforme da Marinha Nelson Institute, embarque no USS Seaview, comandado pelo Almirante Harriman Nelson e pelo Capitão Lee Crane, porque hoje faremos uma viagem ao fundo do mar... das métricas do IBM Z.


Capítulo 1 — O Oceano Invisível do Mainframe

Todo iniciante imagina que um computador executa apenas programas.

Na realidade, um IBM Z executa milhares de atividades simultaneamente.

Enquanto seu programa COBOL faz um simples:

READ CLIENTES

o sistema inteiro está trabalhando.

Nos bastidores existem:

  • Dispatcher

  • PR/SM

  • WLM

  • zIIP

  • RMF

  • SMF

  • CICS

  • Db2

  • MQ

  • JES2

  • VSAM

  • RACF

  • DFSMS

  • Coupling Facility

  • IOS

  • Channel Subsystem

Todos gerando estatísticas.

Imagine centenas de sensores espalhados pelo casco do Seaview.

Cada sensor mede:

  • pressão

  • temperatura

  • velocidade

  • combustível

  • profundidade

  • oxigênio

  • consumo elétrico

Agora multiplique isso por dezenas de milhares.

É isso que o IBM Z mede continuamente.


Easter Egg nº 1

Na série Viagem ao Fundo do Mar, o Seaview parecia navegar calmamente.

Mas na sala de máquinas havia dezenas de oficiais monitorando centenas de instrumentos.

No IBM Z acontece exatamente o mesmo.

Você vê apenas uma tela 3270.

Por trás dela existe um oceano inteiro de telemetria.


Capítulo 2 — O erro que muita gente está cometendo

Com a chegada dos LLMs surgiu uma ideia perigosa.

"Agora basta perguntar para uma IA."

Será?

Imagine entrar no Seaview e perguntar:

— IA, estamos seguros?

Resposta:

— Sim.

Fim.

Mas...

E se existir uma microfissura no casco?

E se um sonar estiver apresentando ruído?

E se uma bomba hidráulica estiver começando a vibrar?

A IA respondeu.

Mas não analisou.

Essa é exatamente a diferença entre um chatbot e uma plataforma especializada como o IBM Z IntelliMagic Vision.


Informação não é conhecimento

Uma IA pode responder:

"A CPU está em 82%."

Ótimo.

Mas isso é bom?

Ruim?

Esperado?

Anormal?

Ela não sabe.

Porque falta contexto.

O especialista pergunta:

  • qual CPC?

  • qual LPAR?

  • qual horário?

  • qual workload?

  • qual Service Class?

  • qual política WLM?

  • houve IPL?

  • mudou o firmware?

  • houve novo package Db2?

  • apareceu nova aplicação Java?

  • aumentou MQ?

  • mudou o peso PR/SM?

É outro nível de investigação.


Capítulo 3 — O verdadeiro tesouro do oceano chama-se SMF

Poucos iniciantes conhecem o SMF.

Mas ele talvez seja o recurso mais valioso do z/OS.

SMF significa:

System Management Facility

Pense nele como o diário de bordo do Seaview.

Tudo é registrado.

Tudo.

Quem usou CPU.

Quem fez I/O.

Quem abriu datasets.

Quem executou CICS.

Quem acessou Db2.

Quem consumiu zIIP.

Quem gerou paging.

Quem alterou configuração.

Décadas de história ficam registradas.

Sem SMF...

não existe análise histórica.


Curiosidade

Muitas empresas possuem anos de dados SMF armazenados.

Algumas conseguem comparar o comportamento atual com períodos de cinco ou dez anos atrás.

É como comparar uma expedição submarina atual com os registros originais do Almirante Nelson.


Capítulo 4 — Uma imagem vale mais que mil RMFs

O artigo comenta algo extremamente importante.

Uma figura vale mais que mil palavras.

Observe mentalmente a topologia apresentada.

Diversos:

CPC

LPARs

Sysplex

Tudo conectado.

Em segundos o especialista entende:

Quem pertence a quem.

Quem compartilha recursos.

Quem faz parte do mesmo Sysplex.

Quem utiliza determinado processador.

Nenhum texto consegue transmitir isso tão rapidamente.


Easter Egg nº 2

No Seaview existia uma enorme mesa de navegação.

Ninguém decorava o oceano.

Eles olhavam o mapa.

O IntelliMagic faz exatamente isso.

Ele desenha o mapa do seu mainframe.


Capítulo 5 — O poder do Change Detection

Imagine esta situação.

Segunda-feira:

Tudo perfeito.

Terça-feira:

Usuários reclamando.

O que mudou?

Essa pergunta pode consumir dias de investigação.

Mas o IntelliMagic compara automaticamente períodos diferentes.

Ele verifica:

  • CPU

  • zIIP

  • Dispatch Time

  • Busy

  • Eligible Work

  • Utilização

  • Tendências

  • Desvios

Não apenas mostra valores.

Mostra mudanças.

E mais importante...

Mostra mudanças relevantes.


O segredo do desvio padrão

Imagine um sonar.

O ruído normal fica entre:

10 e 15 decibéis.

Hoje apareceu:

Nada mudou.

Agora imagine:

Tem algo enorme vindo na direção do submarino.

Foi isso que o desvio padrão detectou.

Mudanças realmente fora do comportamento esperado.

Não basta aumentar.

Precisa aumentar de forma estatisticamente significativa.


Capítulo 6 — Health Rating

Talvez a funcionalidade mais fascinante.

Imagine o painel do Seaview.

Luzes verdes.

Luzes amarelas.

Luzes vermelhas.

Você não precisa ler milhares de sensores.

Basta olhar o painel.

No IntelliMagic ocorre exatamente isso.

Cada sistema recebe indicadores como:

  • Dispatch Time

  • MVS Busy

  • LPAR Busy

  • zIIP

  • IOSQ

  • Pending

  • Connect

  • Interrupt

  • Page-ins

Em poucos segundos o especialista sabe onde investigar primeiro.


Dica Bellacosa

Nunca olhe apenas um indicador.

Performance é correlação.

CPU alta pode ser consequência.

Não a causa.


Capítulo 7 — Tendência vale mais que fotografia

Uma fotografia mostra um instante.

Um gráfico mostra uma história.

É por isso que Capacity Planning utiliza séries históricas.

Não interessa apenas saber:

Hoje = 70%.

Interessa descobrir:

Janeiro:

65%

Fevereiro:

67%

Março:

69%

Abril:

72%

Maio:

75%

Junho:

78%

Agora existe uma tendência.

Sem histórico...

não existe previsão.


Capítulo 8 — Capacity Planning

Aqui muitos iniciantes cometem outro erro.

Pensam:

Capacity Planning = CPU.

Não.

CPU é apenas uma peça.

O especialista observa:

CPU

Memória

I/O

Storage

Channels

Paging

Network

zIIP

MSU

Software

CICS

Db2

MQ

IMS

Batch

Online

WLM

Tudo ao mesmo tempo.

Porque gargalos raramente aparecem isolados.


Curiosidade

Em muitos ambientes o problema nunca foi CPU.

Foi um único volume DASD saturado.

Ou uma fila MQ crescendo.

Ou uma política WLM mal definida.

Ou uma consulta SQL sem índice.


Capítulo 9 — O verdadeiro papel do especialista

O artigo fala algo maravilhoso.

O maior problema não é coletar dados.

É interpretá-los.

Hoje qualquer ferramenta coleta milhões de métricas.

Mas poucas conseguem responder:

O que realmente importa?

Imagine o Seaview.

Existem dez mil instrumentos.

Mas apenas um oficial experiente percebe que pequenas vibrações significam falha futura.

É exatamente isso que faz um especialista em performance.


Capítulo 10 — Explainability

Uma IA responde.

O especialista explica.

Existe enorme diferença.

Imagine um diretor perguntando:

"Por que precisamos comprar outro CPC?"

Você responde:

"Porque a IA sugeriu."

A reunião termina.

Agora imagine responder:

  • crescimento médio de 18% ao ano;

  • tendência confirmada em 36 meses;

  • workloads Batch crescendo;

  • consumo zIIP estabilizado;

  • pico de MSU chegando ao limite contratual;

  • risco para SLA da aplicação bancária;

  • previsão estatística de saturação em oito meses.

Agora existe evidência.


Easter Egg nº 3

No Seaview, o Almirante Nelson nunca dizia apenas:

"Vamos mergulhar."

Ele mostrava:

  • cartas náuticas;

  • sonar;

  • profundidade;

  • corrente marítima;

  • combustível;

  • pressão.

Isso é explainability.


Capítulo 11 — IA não substitui Analytics

Esse talvez seja o maior ensinamento do artigo.

A IA facilita perguntas.

O IntelliMagic produz respostas confiáveis.

Pense assim.

ChatGPT é como um excelente oficial de comunicações.

Ele conversa.

Resume.

Explica.

O IntelliMagic é o centro de controle do submarino.

Recebe milhares de sinais.

Correlaciona.

Detecta anomalias.

Calcula riscos.

Prevê problemas.

Ambos trabalham juntos.

Jamais um substitui o outro.


Passo a passo de uma investigação de performance

Imagine que um gerente liga dizendo:

"O sistema ficou lento."

Como um especialista procede?

Passo 1 — Confirmar o sintoma

Foi CPU?

I/O?

Rede?

Storage?

Aplicação?


Passo 2 — Comparar com a baseline

Como era ontem?

Semana passada?

Mesmo horário?


Passo 3 — Procurar mudanças

Novo deploy?

Novo package?

Nova política WLM?

Novo firmware?

Novo microcódigo?


Passo 4 — Correlacionar métricas

CPU alta.

Mas também houve:

  • aumento de I/O;

  • queda no cache;

  • crescimento do MQ;

  • aumento de locks Db2.

Agora aparece a verdadeira causa.


Passo 5 — Avaliar impacto

Quem sofreu?

Clientes?

PIX?

Internet Banking?

Cartão?

Folha?

Ou apenas um batch interno?


Passo 6 — Recomendar ações

Redistribuir workload.

Aumentar zIIP.

Reconfigurar WLM.

Otimizar SQL.

Criar índices.

Mover datasets.

Alterar prioridades.


O futuro

A próxima geração de ferramentas será híbrida.

Imagine conversar com a plataforma:

"Quais sistemas apresentaram crescimento anormal?"

A IA responde.

Mas por trás dela existe um motor especializado analisando:

  • milhares de métricas;

  • estatísticas;

  • tendências;

  • Health Insights;

  • correlações;

  • previsões.

É exatamente essa união que o artigo chama de:

AI + Analytics.


Curiosidades Bellacosa

✅ Um único IBM Z pode produzir milhões de registros SMF por dia.

✅ O WLM ajusta prioridades automaticamente centenas de vezes por segundo para manter os objetivos de serviço.

✅ O zIIP pode descarregar grande parte do processamento elegível de Db2, XML, Java, criptografia e workloads analíticos, reduzindo custos de software em muitos cenários.

✅ Um problema aparentemente "de CPU" pode, na verdade, ser consequência de filas de I/O, contenção em locks Db2, espera por MQ ou políticas WLM inadequadas.

✅ Ferramentas como o IBM Z IntelliMagic Vision incorporam décadas de conhecimento de especialistas em performance, automatizando análises que antes exigiam anos de experiência.


Conclusão — A Verdadeira Viagem ao Fundo do Mar

Ao final da missão, o USS Seaview emerge lentamente das profundezas. A tripulação sobreviveu não porque tinha o sonar mais bonito ou o rádio mais moderno, mas porque soube interpretar corretamente cada sinal vindo do oceano.

No IBM Z acontece exatamente o mesmo.

Os gráficos, mapas de Sysplex, indicadores de saúde, detecção automática de mudanças e análises históricas são os "sonares" do mundo corporativo. Eles transformam bilhões de amostras de desempenho em conhecimento acionável.

A IA generativa representa o novo oficial de comunicações: traduz perguntas complexas para linguagem natural, resume informações e acelera o acesso ao conhecimento. Já plataformas como o IBM Z IntelliMagic Vision são o cérebro analítico do navio, capazes de correlacionar milhares de métricas, detectar riscos antes que se tornem incidentes e justificar cada conclusão com evidências.

Para o programador COBOL iniciante, a maior lição é simples: escrever um bom programa não significa apenas fazer a lógica funcionar. Significa entender como esse programa consome CPU, acessa VSAM e Db2, utiliza CICS, aproveita zIIP, respeita as metas do WLM e influencia todo o ecossistema do mainframe.

No universo Bellacosa Mainframe, o código é apenas a ponta do iceberg.

A verdadeira aventura começa quando você aprende a enxergar o oceano invisível que existe sob cada EXEC CICS, cada SELECT no Db2, cada mensagem no MQ e cada READ em um dataset. É nesse oceano que vivem os maiores desafios da engenharia de performance — e também onde se encontram os maiores tesouros de conhecimento para quem deseja se tornar um verdadeiro Mestre Jedi do Mainframe.

segunda-feira, 26 de junho de 2023

JSON no COBOL Mainframe : O Guia Definitivo para um Programador Padawan Entender Como o IBM Z Conversa com o Mundo Moderno

 

Bellacosa Mainframe e o json no cobol

☕ Um Café no Bellacosa Mainframe

JSON no COBOL Mainframe

O Guia Definitivo para um Programador Padawan Entender Como o IBM Z Conversa com o Mundo Moderno

"O COBOL nunca teve dificuldade em processar dados. O desafio sempre foi aprender novos idiomas. JSON é apenas mais um idioma."


Introdução

Durante décadas, o mundo Mainframe conversou utilizando formatos extremamente bem definidos.

Arquivos VSAM.

Registros fixos.

Copybooks.

Layouts COBOL.

MQ.

CICS COMMAREA.

IMS.

Tudo extremamente organizado.

Enquanto isso, o restante do mercado passou a utilizar um formato muito mais simples para troca de informações:

JSON (JavaScript Object Notation).

Hoje praticamente toda API REST utiliza JSON.

Aplicativos móveis.

Sites.

Microsserviços.

Open Banking.

Pix.

Cloud.

Inteligência Artificial.

ChatGPT.

IBM watsonx.

Todos utilizam JSON.

E é justamente por isso que um programador COBOL moderno precisa dominar este formato.

A boa notícia?

Desde o Enterprise COBOL V6, a IBM adicionou suporte nativo através dos comandos:

  • JSON PARSE

  • JSON GENERATE

Sem bibliotecas externas.

Sem escrever um parser manual.

Sem sofrimento.


O que é JSON?

JSON é simplesmente uma forma de representar dados usando pares:

nome : valor

Exemplo:

{
   "cliente": "João",
   "idade": 35,
   "saldo": 1250.75,
   "ativo": true
}

Perceba que ele lembra um registro COBOL.

No COBOL escreveríamos:

01 CLIENTE.
   05 NOME        PIC X(30).
   05 IDADE       PIC 9(3).
   05 SALDO       PIC 9(7)V99.
   05 ATIVO       PIC X.

A diferença é apenas o formato.


JSON x Copybook

Um copybook descreve campos.

JSON descreve informações.

Copybook:

05 NOME PIC X(30).

JSON

"nome":"Maria"

A IBM simplesmente faz o mapeamento entre ambos.


Estrutura básica

Um objeto:

{
   "nome":"Maria",
   "idade":28
}

Um vetor

{
   "telefones":[
      "1111",
      "2222"
   ]
}

Objeto dentro de objeto

{
   "cliente":{
      "nome":"Carlos",
      "cidade":"São Paulo"
   }
}

Tudo isso pode ser representado em COBOL.


Como declarar no COBOL

01 WS-CLIENTE.

   05 WS-NOME          PIC X(30).
   05 WS-IDADE         PIC 999.
   05 WS-SALDO         PIC 9(7)V99.
   05 WS-ATIVO         PIC X.

Agora um campo contendo o JSON.

01 WS-JSON.

   05 WS-DADOS PIC X(5000).

Este será o buffer utilizado para leitura ou gravação.


Lendo JSON

Imagine receber:

{
   "nome":"Luke",
   "idade":22,
   "saldo":1500.50,
   "ativo":"S"
}

Basta executar:

JSON PARSE WS-DADOS
     INTO WS-CLIENTE
END-JSON

Pronto.

A IBM faz todo o trabalho.

Após isso:

WS-NOME = LUKE

WS-IDADE = 22

WS-SALDO = 1500.50

WS-ATIVO = S

Sem IF.

Sem UNSTRING.

Sem parser.


Programa exemplo de leitura

IDENTIFICATION DIVISION.
PROGRAM-ID. JSONREAD.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-JSON.
   05 WS-DADOS PIC X(500).

01 WS-CLIENTE.
   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.
   05 WS-SALDO PIC 9(7)V99.
   05 WS-ATIVO PIC X.

PROCEDURE DIVISION.

MOVE
'{"nome":"Luke","idade":22,"saldo":1500.50,"ativo":"S"}'
TO WS-DADOS

JSON PARSE WS-DADOS
    INTO WS-CLIENTE
END-JSON

DISPLAY WS-NOME
DISPLAY WS-IDADE
DISPLAY WS-SALDO
DISPLAY WS-ATIVO

STOP RUN.

Como funciona internamente

O parser da IBM:

  1. lê caractere por caractere

  2. identifica as chaves

  3. procura o campo correspondente

  4. converte texto para número

  5. grava nas variáveis COBOL

Tudo automaticamente.


Gravando JSON

O caminho inverso também existe.

Suponha:

MOVE "ANA" TO WS-NOME

MOVE 30 TO WS-IDADE

MOVE 999.99 TO WS-SALDO

MOVE "S" TO WS-ATIVO

Agora:

JSON GENERATE WS-DADOS
    FROM WS-CLIENTE
END-JSON

Resultado:

{
   "nome":"ANA",
   "idade":30,
   "saldo":999.99,
   "ativo":"S"
}

Programa exemplo de geração

IDENTIFICATION DIVISION.
PROGRAM-ID. JSONWRITE.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-DADOS PIC X(1000).

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.
   05 WS-SALDO PIC 9(7)V99.
   05 WS-ATIVO PIC X.

PROCEDURE DIVISION.

MOVE "ANA" TO WS-NOME

MOVE 30 TO WS-IDADE

MOVE 1500.75 TO WS-SALDO

MOVE "S" TO WS-ATIVO

JSON GENERATE WS-DADOS
    FROM WS-CLIENTE
END-JSON

DISPLAY WS-DADOS

STOP RUN.

Gravando em arquivo

Após gerar o JSON basta gravá-lo normalmente.

WRITE REGISTRO-SAIDA

ou

STRING

WS-DADOS

DELIMITED BY SIZE

INTO REGISTRO

END-STRING

WRITE REGISTRO

Pode ser salvo em:

  • Sequential File

  • VSAM ESDS

  • UNIX USS

  • MQ

  • FTP

  • API REST

  • Kafka

  • IBM MQ

  • z/OS Connect


Tratando erros

Nunca assuma que o JSON está correto.

Utilize:

JSON PARSE
...
ON EXCEPTION

DISPLAY "JSON INVALIDO"

NOT ON EXCEPTION

DISPLAY "SUCESSO"

END-JSON

Isso evita que dados inválidos sejam processados.


Exemplo completo

JSON PARSE WS-DADOS

INTO WS-CLIENTE

ON EXCEPTION

MOVE "ERRO" TO WS-STATUS

NOT ON EXCEPTION

MOVE "OK" TO WS-STATUS

END-JSON

Arrays

JSON

{
 "produtos":[
   "Mouse",
   "Teclado",
   "Monitor"
 ]
}

COBOL

05 PRODUTO OCCURS 10 TIMES.

   10 NOME PIC X(30).

A IBM faz o relacionamento automaticamente quando os nomes e a estrutura são compatíveis.


Objetos aninhados

JSON

{
 "cliente":{
   "nome":"Carlos",
   "cidade":"Campinas"
 }
}

COBOL

01 CLIENTE.

   05 DADOS.

      10 NOME PIC X(30).

      10 CIDADE PIC X(20).

Valores opcionais

Nem sempre todos os campos existirão.

Exemplo

{
   "nome":"Pedro"
}

Sem idade.

Sem saldo.

Os campos COBOL permanecerão com seus valores iniciais (SPACES, ZEROS ou VALUE), por isso é importante inicializar a estrutura antes do JSON PARSE, geralmente com:

INITIALIZE WS-CLIENTE

Campos numéricos

Muito cuidado.

JSON

"idade":"ABC"

Jamais poderá alimentar

PIC 999

O parser gerará exceção.


Decimais

JSON

123.45

COBOL

PIC 9(5)V99

O ponto decimal é interpretado automaticamente conforme as regras do compilador e da representação numérica.


Booleanos

JSON

true
false

COBOL não possui um tipo booleano tradicional.

Uma prática comum é utilizar:

05 ATIVO PIC X.
   88 CLIENTE-ATIVO VALUE "S".
   88 CLIENTE-INATIVO VALUE "N".

Ou mapear para indicadores específicos conforme o padrão da aplicação.


Controle de tamanho

Um erro comum dos iniciantes.

Criar

PIC X(100)

para um JSON de

500 caracteres.

Resultado?

Truncamento.

Sempre dimensione com folga ou utilize áreas compatíveis com o tamanho esperado.


Performance

O parser da IBM é extremamente eficiente.

Mesmo assim:

  • Evite gerar JSON gigantescos.

  • Não faça PARSE repetidamente da mesma informação.

  • Reutilize áreas de trabalho.

  • Inicialize apenas quando necessário.

  • Evite cópias desnecessárias do buffer.


Armadilhas

Nomes diferentes

JSON

customerName

COBOL

CLIENTE-NOME

Não haverá correspondência automática sem mecanismos de mapeamento.


Campos obrigatórios

Nem sempre existirão.

Sempre valide.


Tipos incompatíveis

Número enviado como texto.

Texto enviado como número.

Boolean enviado como string.

São causas clássicas de erro.


Caracteres especiais

JSON utiliza UTF-8 com frequência.

Aplicações tradicionais em z/OS podem utilizar EBCDIC.

Em integrações, pode ser necessário converter a codificação antes do JSON PARSE ou após o JSON GENERATE.


Riscos

Os maiores riscos não estão no JSON.

Estão nos dados.

Por exemplo:

  • JSON malformado.

  • Dados incompletos.

  • Campos inesperados.

  • Tamanho excessivo.

  • Conteúdo malicioso.

  • Falhas de conversão de caracteres.

  • Exposição de informações sensíveis em logs.

Valide sempre a entrada e registre apenas o necessário.


Vantagens

Utilizar JSON no Mainframe oferece inúmeras vantagens:

  • integração simples com APIs REST;

  • comunicação natural com aplicações Java, .NET, Python e Node.js;

  • suporte a microsserviços;

  • facilidade de integração com nuvem;

  • menor necessidade de conversões proprietárias;

  • manutenção mais simples;

  • suporte nativo do Enterprise COBOL;

  • excelente desempenho quando comparado a parsers desenvolvidos manualmente.


Onde ele é utilizado?

Hoje praticamente em todos os projetos modernos.

  • Open Banking

  • PIX

  • Internet Banking

  • Aplicativos Mobile

  • APIs REST

  • IBM z/OS Connect

  • IBM API Connect

  • IBM MQ

  • Kafka

  • Cloud

  • Inteligência Artificial

  • IBM watsonx

  • Integrações híbridas entre IBM Z e plataformas distribuídas


Boas práticas

Um Padawan COBOL deve criar alguns hábitos desde o primeiro dia:

  • Inicialize as estruturas antes do processamento (INITIALIZE).

  • Utilize ON EXCEPTION e trate todos os erros.

  • Dimensione corretamente o buffer JSON.

  • Valide obrigatoriedade e formato dos campos.

  • Documente o layout esperado.

  • Mantenha os nomes consistentes entre JSON e estrutura COBOL sempre que possível.

  • Evite expor informações confidenciais em arquivos de log.

  • Teste com JSONs válidos, inválidos, incompletos e com dados extremos.


Conclusão

Durante muito tempo existiu o mito de que o Mainframe "não falava JSON". Isso deixou de ser verdade há anos. O Enterprise COBOL trouxe comandos nativos que simplificam enormemente a leitura e a geração desse formato, permitindo que aplicações escritas há décadas conversem com APIs modernas, serviços em nuvem, aplicações móveis e plataformas de Inteligência Artificial.

Para um Programador Padawan, aprender JSON significa abrir uma porta para o futuro sem abandonar os fundamentos que fazem do COBOL uma das linguagens mais confiáveis do mundo. Quem domina registros, copybooks e validação de dados aprenderá JSON rapidamente. A diferença está apenas na forma de representar a informação.

O verdadeiro desafio não é escrever JSON PARSE ou JSON GENERATE. É compreender a estrutura dos dados, validar corretamente o conteúdo recebido, tratar exceções, garantir compatibilidade de tipos e proteger informações sensíveis. Esses princípios sempre fizeram parte do desenvolvimento em Mainframe e continuam válidos na era das APIs.

No fim das contas, JSON não substitui o COBOL. Ele amplia sua capacidade de comunicação. E um IBM Z que conversa com o mundo moderno continua fazendo aquilo que sempre fez melhor: processar dados com segurança, desempenho e confiabilidade.


segunda-feira, 6 de fevereiro de 2023

Entendendo Mainframe Datasets (PS, PDS e PDSE)

 

Bellacosa Mainframe e os datasets ps pds e pdse no z/os

Entendendo Mainframe Datasets (PS, PDS e PDSE)

Uma análise aprofundada para desenvolvedores COBOL Jr.

A imagem resume um dos conceitos mais importantes do ecossistema z/OS: datasets. Se você está iniciando em COBOL, JCL, DB2, CICS ou suporte Mainframe, compreender datasets não é apenas importante — é obrigatório.

Muitos iniciantes vêm do mundo Windows, Linux ou Cloud e tentam enxergar o Mainframe usando a lógica de diretórios, arquivos e pastas tradicionais. Esse é um dos primeiros erros.

No Mainframe, a unidade fundamental de armazenamento não é o arquivo ("file"), mas sim o dataset.


1. O que é um Dataset?

Um dataset é uma estrutura lógica utilizada para armazenar informações dentro do z/OS.

Ele pode conter:

  • Programas COBOL

  • Fontes Assembler

  • Membros JCL

  • Procedures

  • Relatórios

  • Arquivos de entrada

  • Arquivos de saída

  • Dados transacionais

  • Bibliotecas de Load Modules

Em ambientes distribuídos você pensa:

Windows/Linux

Diretório
 ├── arquivo1.txt
 ├── arquivo2.txt
 └── arquivo3.txt

No Mainframe:

Dataset

ou

Dataset
 ├── membro1
 ├── membro2
 └── membro3

Dependendo do tipo.


2. Por que o Mainframe usa Datasets?

Quando o OS/360 foi criado nos anos 60, não existia o conceito moderno de sistemas de arquivos hierárquicos como conhecemos hoje.

O Mainframe foi projetado para:

  • Processamento em lote (Batch)

  • Alta performance

  • Baixo overhead

  • Grandes volumes de dados

Por isso surgiu o conceito de datasets.

Até hoje ele continua porque funciona extremamente bem.


3. Os Três Tipos Fundamentais

A imagem apresenta:

PS

Physical Sequential

PDS

Partitioned Dataset

PDSE

Partitioned Dataset Extended

Esses três tipos aparecem diariamente em qualquer ambiente corporativo.


4. PS – Physical Sequential Dataset

Imagine uma folha de papel.

Você escreve:

Linha 1
Linha 2
Linha 3
Linha 4

Você lê exatamente nessa sequência.

Isso é um PS.


Estrutura

Registro 1
Registro 2
Registro 3
Registro 4
Registro 5

Sem divisões internas.

Sem membros.

Sem pastas.

É um único bloco de informação.


Analogia Bellacosa

Imagine um PDF.

Você abre.

Existe apenas um documento.

Não existe:

Capítulo como arquivo separado

Tudo está dentro dele.

PS é exatamente isso.


Exemplos reais

Arquivo de clientes:

CLIENTES.DIARIO

Arquivo de vendas:

VENDAS.MENSAL

Relatório batch:

RELATORIO.FINANCEIRO

Arquivo de entrada:

INPUT.ARQ001

5. Como um programa COBOL lê um PS?

Exemplo:

SELECT CLIENTES
ASSIGN TO CLIENTES.

FD:

FD CLIENTES.

01 REG-CLIENTE.
   05 ID-CLIENTE PIC 9(5).
   05 NOME       PIC X(30).

O COBOL irá:

Read registro 1
Read registro 2
Read registro 3
...
EOF

Sequencialmente.


6. Características do PS

Vantagens

Muito rápido.

Baixo overhead.

Excelente para batch.

Menos controle interno.


Desvantagens

Não possui membros.

Difícil organizar múltiplos objetos.

Pouca flexibilidade.


7. Onde um COBOL Jr vê PS?

Todos os dias.

Arquivos:

INPUT
OUTPUT
SORTWK
EXTRACT
REPORT

Normalmente são PS.

Exemplo JCL:

//INFILE DD DSN=USER.CLIENTES,
// DISP=SHR

Esse dataset costuma ser PS.


8. PDS – Partitioned Dataset

Agora imagine um armário de arquivos.


Estrutura:

Armário
 ├── Gaveta A
 ├── Gaveta B
 ├── Gaveta C

O armário é o dataset.

As gavetas são membros.


Estrutura real

USER.COBOL.SOURCE

Contendo:

PROG001
PROG002
PROG003
PROG004

Cada membro é um programa.


Analogia Bellacosa

Imagine uma pasta Windows:

COBOL
 ├── PROG001.CBL
 ├── PROG002.CBL
 └── PROG003.CBL

No Mainframe:

USER.COBOL.SOURCE

com membros:

PROG001
PROG002
PROG003

9. O Diretório do PDS

O segredo do PDS está no diretório.

Ele mantém a lista dos membros.

Exemplo:

PROG001
PROG002
PROG003
PROG004

Toda vez que você abre:

USER.COBOL.SOURCE

o sistema consulta esse diretório.


10. O Problema Histórico do PDS

Aqui aparece uma questão clássica de entrevista.

O PDS sofre com:

Directory Full

ou

Space Fragmentation


Imagine:

PROG001
PROG002
PROG003

Você apaga:

PROG002

O espaço não é totalmente reaproveitado.

Com o tempo:

Espaço livre espalhado

começa a existir dentro do dataset.


Consequências:

  • desperdício de espaço

  • lentidão

  • necessidade de manutenção


11. Compress do PDS

Por isso surgiu o famoso:

IEBCOPY COMPRESS

ou

3.1 Compress

no ISPF.


O processo reorganiza:

Membro 1
Membro 2
Membro 3

removendo os buracos.


Analogia:

Desfragmentação de disco.


12. Onde o PDS é usado?

Muito comum para:

JCL

USER.JCL

COBOL Sources

USER.COBOL

PROC Libraries

USER.PROCLIB

Copybooks

USER.COPYLIB

13. Como acessar um membro?

Sintaxe:

USER.COBOL(PROG001)

Dataset:

USER.COBOL

Membro:

PROG001

14. JCL utilizando membro

//SYSIN DD DSN=USER.JCL(MYJOB),
 // DISP=SHR

ou

EXEC PROC=PROC001

onde:

USER.PROCLIB(PROC001)

contém a procedure.


15. PDSE – A Evolução do PDS

IBM percebeu:

"PDS gera manutenção demais."

Resultado:

PDSE.

Partitioned Dataset Extended.


O que mudou?

Praticamente tudo internamente.

Externamente parece igual.


Você continua acessando:

USER.COBOL(PROG001)

Mas internamente o gerenciamento mudou completamente.


16. PDSE é um Sistema Inteligente

PDS:

Gerenciamento manual

PDSE:

Gerenciamento automático

Analogia Bellacosa:

PDS:

Arquivo de aço dos anos 80

PDSE:

Google Drive

17. Eliminação do Compress

Maior vantagem.

PDS:

Compress obrigatório

PDSE:

Compress não existe

O próprio sistema gerencia.


18. Espaço Dinâmico

PDS:

Diretório fixo

PDSE:

Diretório expansível

Isso resolve:

Directory Full

19. Melhor Performance

PDSE utiliza estruturas modernas.

Possui cache.

Melhor gerenciamento interno.

Menor contenção.


Em ambientes grandes:

Milhares de acessos simultâneos

a diferença é perceptível.


20. PDSE para Load Libraries

Muito importante.

Bibliotecas de programas compilados:

LOADLIB
STEPLIB
LINKLIB

normalmente são PDSE.


Exemplo:

USER.LOADLIB

Membros:

PROGA
PROGB
PROGC

Cada membro é um módulo executável.


21. Geração de Objetos COBOL

Fluxo clássico:

Source
 ↓
Compile
 ↓
Object
 ↓
Link Edit
 ↓
Load Module

Onde ficam?

Source:

PDS/PDSE

Objeto:

PDS/PDSE

Load:

PDSE

22. Fluxo Completo de Desenvolvimento COBOL

Imagine:

USER.COBOL

Membro:

PGMCLI01

Compilação:

IGYCRCTL

gera:

USER.OBJLIB

Depois:

USER.LOADLIB

Finalmente:

EXEC PGM=PGMCLI01

executa o módulo armazenado na LOADLIB.


23. O que um Dev COBOL Jr precisa decorar?

PS

Pergunta:

"Possui membros?"

Resposta:

Não

PDS

Pergunta:

"Precisa compress?"

Resposta:

Sim

PDSE

Pergunta:

"Precisa compress?"

Resposta:

Não

PDS

Pergunta:

"Directory fixo?"

Resposta:

Sim

PDSE

Pergunta:

"Directory expansível?"

Resposta:

Sim

24. Perguntas Clássicas de Entrevista

Qual a diferença entre PDS e PDSE?

Resposta curta:

PDS utiliza diretório fixo e requer compressão periódica. PDSE possui gerenciamento automático de espaço, diretório dinâmico e não necessita compressão.


O que é um membro?

Resposta:

Uma subdivisão lógica dentro de um PDS ou PDSE.


Um PS possui membros?

Resposta:

Não.


Como referenciar um membro?

Resposta:

DSN(MEMBER)

Exemplo:

USER.COBOL(PROG001)

Onde ficam os fontes COBOL?

Resposta:

Normalmente:

PDS ou PDSE

25. Visão Arquitetural que Poucos Iniciantes Entendem

A maioria dos juniores pensa:

PS = ruim
PDS = melhor
PDSE = moderno

Mas isso é simplificação excessiva.

A verdade é:

Cada um resolve um problema diferente.


PS

Especialista em:

Grande volume sequencial

PDS

Especialista em:

Organização de membros

PDSE

Especialista em:

Organização moderna de membros

Portanto:

PS ≠ PDS
PDS ≠ PDSE

Eles não competem diretamente.


26. Como enxergar isso como um profissional Mainframe

Visualize uma aplicação bancária:

Fontes COBOL
     ↓
USER.COBOL (PDSE)

Copybooks
     ↓
USER.COPYLIB (PDSE)

Objetos
     ↓
USER.OBJLIB (PDSE)

Executáveis
     ↓
USER.LOADLIB (PDSE)

Arquivo de clientes
     ↓
CLIENTE.MESTRE (PS)

Arquivo de transações
     ↓
TRANSACOES.DIA (PS)

Relatório
     ↓
RELATORIO.FINAL (PS)

Perceba a lógica:

  • Código → PDS/PDSE

  • Dados → PS

Essa separação é um dos pilares da arquitetura Mainframe.


Conclusão

A imagem apresenta apenas a superfície do assunto. Para um desenvolvedor COBOL Jr., o entendimento profundo é que datasets são a espinha dorsal do z/OS. Quase tudo que você fará no Mainframe envolverá abrir, criar, catalogar, alocar, ler, gravar, copiar, compactar ou referenciar datasets.

Guarde a regra mental mais importante:

PS   = Arquivo único (Single File)

PDS  = Biblioteca com membros (Folder)

PDSE = Biblioteca inteligente (Smart Folder)

E, no dia a dia profissional:

Dados de negócio     → PS
Fontes COBOL         → PDSE
Copybooks            → PDSE
JCLs                 → PDSE
PROCs                → PDSE
Load Modules         → PDSE

Quando você dominar datasets, começará a enxergar o Mainframe da forma correta: não como um "Linux antigo", mas como um sistema operacional projetado para processar bilhões de transações com confiabilidade, organização e desempenho que continuam sendo referência mundial décadas depois de sua criação.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...