Translate

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

domingo, 26 de julho de 2026

A Academia Jedi do COBOL: Tudo o Que um Padawan Precisa Saber para Dominar o Mainframe

 

Bellacosa Mainframe e a academia mainframe

 A Academia Jedi do COBOL: Tudo o Que um Padawan Precisa Saber para Dominar o Mainframe

FUNDAMENTOS DO DESENVOLVIMENTO COBOL


1. Conceitos Básicos

Antes de escrever uma linha de código, o aluno precisa entender o que é COBOL.

COBOL significa:

COmmon Business Oriented Language

Criada em 1959 para resolver problemas de negócios.

Enquanto linguagens modernas nasceram para matemática ou sistemas operacionais, COBOL nasceu para:

  • Folha de pagamento

  • Bancos

  • Seguros

  • Governo

  • Contabilidade

  • Controle financeiro

Exemplo:

Imagine um banco processando:

  • 50 milhões de contas

  • 300 milhões de transações por dia

Grande parte disso ainda roda em COBOL.


Estrutura clássica

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

Comparação:

COBOLCasa
IdentificationNome do dono
EnvironmentInfraestrutura
DataMóveis
ProcedureO que acontece dentro

2. Tipos de Programas

Um erro comum é achar que existe apenas um tipo de programa COBOL.

Na prática temos:


Programas Batch

Executados sem interação humana.

Exemplo:

Processamento noturno do banco.

23:00 Início
04:00 Fim

Milhões de registros processados.


Programas Online

Executados pelo usuário.

Exemplo:

Caixa eletrônico.

Saque
Extrato
Transferência

Normalmente via CICS.


Subprogramas

Programas chamados por outros programas.

Exemplo:

CALL 'CALCJURO'

Reutilização de código.


Utilitários

Ferramentas auxiliares.

Exemplo:

  • Conversão de arquivos

  • Formatação

  • Migração de dados


3. Etapas para Desenvolvimento

Aqui o aluno aprende que programar é apenas uma parte do trabalho.


Levantamento de requisitos

Perguntas:

  • O que o usuário quer?

  • Quais entradas existem?

  • Quais saídas são necessárias?


Análise

Transformar regra de negócio em lógica.

Exemplo:

Se idade >= 65
então aposentado

Projeto

Definir:

  • Arquivos

  • Variáveis

  • Fluxo

  • Relatórios


Codificação

Somente agora começa o COBOL.


Testes

Muitos iniciantes pulam esta etapa.

Erro gravíssimo.

Um programa sem testes:

COMPILA ≠ FUNCIONA

4. Terminologia, Conceitos e Recursos

Aqui nasce o vocabulário do programador.


Registro

Uma linha lógica.

Exemplo:

001 João      2500.00

Campo

Parte do registro.

Nome
Salário
CPF

Arquivo

Conjunto de registros.


Programa

Conjunto de instruções.


Job

Execução do programa.

No Mainframe:

//STEP01 EXEC PGM=FOLHA001

☕💣 LÓGICA DE PROGRAMAÇÃO


5. Ferramentas de Planejamento

O pior programador é aquele que abre o editor antes de pensar.

Planejamento economiza horas.


Diagrama de Processo

Entrada
 ↓
Validação
 ↓
Cálculo
 ↓
Saída

Tabela de Decisão

Muito usada em bancos.

Exemplo:

SaldoCrédito
>10000Sim
<10000Não

6. Projeto Estruturado

A filosofia:

Resolver problemas grandes
dividindo em pequenos problemas

Exemplo:

Sistema de Folha

LER FUNCIONÁRIO
CALCULAR SALÁRIO
CALCULAR IMPOSTOS
IMPRIMIR

Cada parte vira um parágrafo.


7. Fluxogramas

Antes do COBOL existia o fluxograma.

Exemplo:

INÍCIO
  |
LER ARQUIVO
  |
FIM DO ARQUIVO?
 /      \
SIM      NÃO
 |         |
FIM      PROCESSA

Benefícios

  • Facilita entendimento

  • Ajuda documentação

  • Facilita manutenção


8. Pseudocódigo

Traduz a regra para linguagem humana.

Exemplo:

LER CLIENTE

SE IDADE >= 18
   APROVAR
SENÃO
   REJEITAR
FIM-SE

Depois converte para COBOL.

IF IDADE >= 18
   MOVE 'S' TO APROVADO
ELSE
   MOVE 'N' TO APROVADO
END-IF.

9. Instruções e Operadores

Comandos básicos.


MOVE

MOVE SALARIO TO SALARIO-ANTIGO

COMPUTE

COMPUTE TOTAL = VALOR + JUROS

ADD

ADD 100 TO SALDO

SUBTRACT

SUBTRACT 50 FROM SALDO

MULTIPLY

MULTIPLY QTDE BY PRECO
    GIVING TOTAL

DIVIDE

DIVIDE TOTAL BY PARCELAS
    GIVING VALOR-PARCELA

10. Estruturas de Controle

O cérebro do programa.


IF

IF SALDO > 0

EVALUATE

Equivalente ao SWITCH.

EVALUATE TIPO
   WHEN 1
      ...
   WHEN 2
      ...
END-EVALUATE

PERFORM

Laços de repetição.

PERFORM 100 TIMES

PERFORM UNTIL

PERFORM UNTIL EOF = 'S'

Muito usado em batch.


☕💣 PADRÕES PROFISSIONAIS


11. Padrões de Nomes

Programador júnior:

01 X.
01 Y.

Programador profissional:

01 WS-SALDO-CLIENTE.
01 WS-LIMITE-CREDITO.

Prefixos comuns

PrefixoSignificado
WSWorking Storage
LKLinkage
FDFile Description
INEntrada
OUTSaída

Parágrafos

Ruim:

1000.

Bom:

1000-LER-CLIENTE.
2000-PROCESSAR-CLIENTE.
3000-EMITIR-RELATORIO.

☕💣 ARQUIVOS E RELATÓRIOS


12. Arquivos Sequenciais

A base histórica do COBOL.

Imagine uma fita magnética.

Leitura:

READ ARQ-CLIENTE

Fluxo clássico:

OPEN INPUT ARQ

PERFORM UNTIL EOF
   READ ARQ
END-PERFORM

CLOSE ARQ

13. Relatórios

Objetivo:

Transformar dados em informação.

Exemplo:

RELATÓRIO DE VENDAS

TOTAL VENDIDO:
R$ 1.500.000

Aspectos importantes:

  • Cabeçalho

  • Detalhes

  • Totais

  • Quebras de controle


Quebra de Controle

Exemplo:

Departamento A
Total A

Departamento B
Total B

Técnica extremamente usada em batch.


☕💣 NÍVEL CORPORATIVO


14. Arquivos Indexados

Aqui o aluno entra no mundo dos bancos e seguradoras.


Sequencial

Procurar conta 9000

1
2
3
4
...
9000

Lento.


Indexado

Índice → Registro

Busca quase instantânea.


Exemplo VSAM KSDS:

READ CLIENTE-KSDS
     KEY IS CPF

15. Tabelas Internas

Equivalente aos arrays modernos.

01 TAB-CLIENTES.
   05 CLIENTE OCCURS 100 TIMES.

Acesso:

CLIENTE(15)

Busca binária:

SEARCH ALL

Tema importantíssimo para entrevistas.


16. Subprogramas

Onde o aluno começa a pensar como arquiteto.


Programa principal:

CALL 'CALCIR'

Subprograma:

LINKAGE SECTION.

Recebe parâmetros.


Benefícios:

  • Reuso

  • Manutenção

  • Modularidade

  • Padronização


O QUE ESTÁ FALTANDO PARA O MERCADO ATUAL?

Se eu fosse enriquecer esse módulo para formar um desenvolvedor COBOL moderno, incluiria também:

Módulo Extra 1 – JCL Básico

  • JOB

  • EXEC

  • DD

  • Condições de execução

  • Return Codes


Módulo Extra 2 – VSAM

  • KSDS

  • ESDS

  • RRDS

  • Alternates Index


Módulo Extra 3 – DB2

  • SELECT

  • INSERT

  • UPDATE

  • CURSOR


Módulo Extra 4 – CICS

  • MAPS

  • COMMAREA

  • Pseudo-conversação


Módulo Extra 5 – Debugging

  • Abend S0C7

  • Abend S0C4

  • FILE STATUS

  • CEEDUMP

  • SYSUDUMP


Módulo Extra 6 – Boas Práticas de Mainframe

  • Naming standards

  • Estrutura de parágrafos

  • Controle de versões

  • Revisão de código

  • Performance

  • Segurança RACF


Visão de carreira do Padawan COBOL

A evolução típica é:

Padawan
 ↓
Programador Júnior
 ↓
Programador Pleno
 ↓
Programador Sênior
 ↓
Analista de Sistemas
 ↓
Arquiteto Mainframe
 ↓
Especialista Corporativo

O segredo não está em decorar comandos COBOL, mas em compreender profundamente processamento de dados, regras de negócio, arquivos, bancos de dados, performance e arquitetura corporativa, pois é exatamente isso que diferencia um simples codificador de um verdadeiro Jedi do Mainframe. ☕💣🚀



domingo, 12 de julho de 2026

O Mainframe Morreu... Pela Vigésima Vez Como a Narrativa do Mercado Ignorou a Engenharia

Bellacosa Mainframe e a milesima morte do mainframe



☕ Um Café no Bellacosa Mainframe

O Mainframe Morreu... Pela Vigésima Vez

Como a Narrativa do Mercado Ignorou a Engenharia — e Por Que o IBM Z Continua Vendendo Mais do que Nunca


Existe uma enorme diferença entre Marketing e Engenharia

A indústria de TI vive de novidades.

Todo ano aparece um novo "salvador da informática".

Foi assim com

  • Cliente-Servidor

  • ERP

  • Java

  • Linux

  • SOA

  • Cloud

  • Containers

  • Kubernetes

  • Blockchain

  • Big Data

  • IA

  • Agentic AI

Cada tecnologia chega acompanhada da mesma promessa:

"Agora tudo vai mudar."

Na prática...

Quase nada muda tão rapidamente.

Porque sistemas críticos não funcionam como aplicativos de celular.


Bellacosa Mainframe desde o projeto apollo a ia 

O problema do Mainframe

O Mainframe sempre sofreu um problema de imagem.

Imagine dois computadores.

Um deles

  • LEDs RGB

  • Docker

  • Kubernetes

  • React

  • Node

  • Linux

Parece moderno.


O outro

  • Tela verde

  • ISPF

  • COBOL

  • JCL

  • CICS

  • VSAM

Parece antigo.

Mas aparência e capacidade não são a mesma coisa.


A maior mentira repetida da TI

Durante quarenta anos ouvimos:

"O Mainframe vai desaparecer."

Curiosamente...

Quem dizia isso normalmente nunca trabalhou em um.

É semelhante a alguém afirmar:

"Os aviões estão ultrapassados."

Porque nunca entrou na cabine de um Boeing.

O dia em que decretaram a morte do mainframe

https://eljefemidnightlunch.blogspot.com/2026/02/o-dia-em-que-decretaram-morte-do.html

COBOL NÃO ESTÁ MORRENDO — ELE ESTÁ ESCONDENDO SEGREDOS QUE SUA EMPRESA NÃO CONSEGUE MAIS ENTENDER

https://eljefemidnightlunch.blogspot.com/2024/12/cobol-nao-esta-morrendo-ele-esta.html

20 ANOS APÓS O BUG DO MILÊNIO (Y2K) — O QUE O MUNDO MAINFRAME REALMENTE APRENDEU

https://eljefemidnightlunch.blogspot.com/2020/01/20-anos-apos-o-bug-do-milenio-y2k-o-que.html


O que realmente acontece dentro de um banco?

Quando você faz um PIX.

Em menos de alguns segundos acontecem dezenas de operações.

Exemplo:

Validação

↓

Autenticação

↓

Consulta de saldo

↓

Bloqueio

↓

Débito

↓

Crédito

↓

Logs

↓

Auditoria

↓

Notificação

↓

Confirmação

Tudo isso precisa acontecer:

  • sem erro

  • sem perda

  • sem duplicidade

  • em milissegundos

Milhões de vezes por minuto.


Isso não é um site

É um sistema transacional.

Existe uma enorme diferença.


Cloud resolve tudo?

Não.

Cloud resolve muitos problemas.

Mas não todos.

Cloud é excelente para:

  • aplicações web

  • microsserviços

  • APIs

  • elasticidade

  • processamento distribuído

  • IA

Mas quando falamos de

  • contas bancárias

  • previdência

  • cartões

  • clearing

  • bolsa de valores

o requisito muda completamente.

Agora entram em cena:

  • ACID

  • Consistência

  • Atomicidade

  • Integridade

  • Recuperação

  • Segurança

É exatamente onde o IBM Z domina.


Por que migrar é tão difícil?

Imagine um banco.

40 anos de software.

Imagine:

  • 80 milhões de clientes

  • 120 bilhões de linhas processadas diariamente

  • milhares de programas COBOL

  • centenas de bases DB2

  • milhares de jobs

  • MQ

  • CICS

  • IMS

Agora alguém diz:

"Vamos migrar tudo."

Parece simples.

Não é.


O iceberg

O código representa apenas a ponta.

Abaixo dele existem

Regras de negócio

+

Integrações

+

Auditoria

+

Compliance

+

Performance

+

Segurança

+

Histórico

Isso levou décadas para ser construído.


O verdadeiro patrimônio

As empresas não pagam bilhões pelo hardware.

Elas pagam pela previsibilidade.

Um banco prefere:

99,999%

todos os dias

do que

100%

durante uma semana
e
80%

na seguinte.


Modernizar ou substituir?

Essa talvez seja a maior mudança dos últimos anos.

Antes:

Replace

Hoje:

Modernize

É completamente diferente.


Modernização não significa abandonar COBOL

Significa adicionar.

Por exemplo:

REST API

↓

z/OS Connect

↓

COBOL

↓

DB2

O COBOL continua existindo.

Mas agora conversa com:

  • Java

  • Python

  • Node

  • Mobile

  • Cloud


IBM percebeu isso antes do mercado

Enquanto muita gente dizia

"o Mainframe morreu"

a IBM fazia outra coisa.

Investia bilhões.


Vieram:

  • Telum

  • Telum II

  • Spyre AI Accelerator

  • Quantum Safe Cryptography

  • zCX

  • OpenShift

  • LinuxONE

  • z/OS Container Extensions

  • AI embarcada

  • Vector Database

  • Hybrid Search

  • Watsonx

  • Zowe

  • Ansible

  • DevOps

Isso não é uma empresa abandonando um produto.

É exatamente o contrário.


O z17

O z17 representa uma mudança importante.

Não é apenas mais CPU.

É uma plataforma de IA.

Imagine um pagamento.

Enquanto a transação acontece...

O acelerador de IA verifica:

  • fraude

  • comportamento

  • risco

  • anomalias

Tudo em tempo real.

Sem enviar dados para outro servidor.


Isso reduz:

  • latência

  • custo

  • risco


Criptografia Pós-Quântica

Outro detalhe ignorado.

Os bancos pensam em décadas.

Não em meses.

Dados criptografados hoje poderão ser quebrados por computadores quânticos no futuro.

O IBM Z já incorpora algoritmos preparados para esse cenário, permitindo uma transição gradual para padrões pós-quânticos conforme evoluem as normas do setor.


Rack Mount

Essa talvez seja uma das notícias mais interessantes.

Durante anos muita gente associou Mainframe a isto:

███████████

Um enorme gabinete
ocupando uma sala inteira.

Hoje isso mudou.

O IBM z17 também passou a ser oferecido em formatos mais compactos, compatíveis com racks padrão, ampliando o acesso a organizações menores e novos cenários de uso.

É uma mudança estratégica.

IBM não diminuiu o Mainframe.

Ela diminuiu a barreira de entrada.


O mito do legado

"Legado" costuma ser usado como crítica.

Mas vamos trocar a palavra.

Em vez de

Legado

use

Patrimônio Digital

Muda completamente.


Imagine um castelo medieval.

Ele tem 700 anos.

Você derruba?

Ou reforma?


É exatamente isso que acontece.


O COBOL continua crescendo

Outro paradoxo.

Enquanto muitos decretavam sua morte,

universidades,

bootcamps,

IBM Z Xplore,

Open Mainframe Project,

Master the Mainframe,

IBM SkillsBuild,

Z Educator Experience,

formam milhares de novos profissionais.

Porque a demanda continua existindo.


A economia explica melhor que a tecnologia

Suponha duas opções.

Opção A

Migrar tudo.

Custo:

US$ 2 bilhões

Tempo:

8 anos

Risco:

Altíssimo


Opção B

Modernizar.

Custo:

20% disso

Resultado:

Mesmo software

Mais APIs

Mais IA

Mais segurança

Mais integração

Qual um CIO escolheria?

A resposta costuma ser evidente.


O efeito "iceberg invisível"

O usuário vê:

PIX realizado.

O Mainframe executou centenas de verificações invisíveis antes da confirmação.

Quando tudo funciona, ninguém percebe.

Esse é o maior elogio que uma infraestrutura crítica pode receber.


O Mainframe virou uma plataforma híbrida

Hoje ele conversa naturalmente com:

  • Kubernetes

  • Docker

  • Linux

  • OpenShift

  • Kafka

  • MQ

  • REST

  • GraphQL

  • Python

  • Java

  • Git

  • Jenkins

  • GitHub Actions

  • Zowe

  • VS Code

  • Ansible

  • Watsonx

  • APIs

  • Microsserviços

O Mainframe moderno não vive isolado; ele é parte central de arquiteturas híbridas.


O verdadeiro motivo do sucesso

Não é nostalgia.

Não é falta de opção.

É engenharia.

Quando uma empresa precisa processar bilhões de transações por dia com disponibilidade próxima de 100%, consistência, rastreabilidade, segurança e baixíssima latência, poucas plataformas oferecem um conjunto tão completo quanto o IBM Z.


O Programador COBOL Padawan

Existe uma grande lição aqui.

Não estude apenas aquilo que está na moda.

Estude aquilo que movimenta a economia.

Frameworks mudam.

Linguagens evoluem.

Clouds surgem.

Mas pagamentos, impostos, previdência, cartões, bolsa de valores e sistemas governamentais continuarão precisando de plataformas confiáveis.

É por isso que COBOL, CICS, Db2, IMS, MQ, z/OS e IBM Z continuam relevantes décadas depois.


O Grande Easter Egg

Há uma frase atribuída a Mark Twain que resume perfeitamente essa situação:

"Os rumores sobre minha morte foram muito exagerados."

Ela poderia ser aplicada ao Mainframe.

Há mais de vinte anos especialistas anunciam seu fim. No entanto, a cada nova geração — z13, z14, z15, z16 e agora z17 — a IBM demonstra que a plataforma continua evoluindo em desempenho, IA, segurança e integração.

Talvez o maior erro tenha sido imaginar que a evolução significaria abandonar o Mainframe. A realidade mostrou exatamente o contrário: o Mainframe evoluiu junto com a nuvem, a IA, os microsserviços e o DevOps, tornando-se um dos pilares da computação híbrida moderna.

Como costumo dizer no Bellacosa Mainframe:

O Mainframe não venceu porque resistiu às mudanças. Venceu porque mudou sem abrir mão daquilo que sempre fez melhor: processar as transações mais críticas do planeta com confiabilidade incomparável.

 

sexta-feira, 10 de julho de 2026

Projeto IBM : APPDEV Final do Projeto 2025/2026

Bellacosa Mainframe e a conclusão do projeto APPDEV

Chegamos ao final de mais uma grande jornada!


Essta semana encerramos oficialmente o Programa APPDEV 2025, um ciclo marcado por muito aprendizado, troca de experiências e crescimento profissional.

Foi uma enorme honra atuar como MSE (Master Subject Expert), conduzindo mais de 30 encontros e 60 horas de treinamentos, compartilhando conhecimento sobre desenvolvimento de aplicações, IBM Z, COBOL e tecnologias corporativas com uma turma extremamente dedicada.

Meu sincero agradecimento à IBM, aos organizadores, coordenadores e a todos que tornaram este programa possível.

Agradeço, principalmente, a cada participante pelo comprometimento, pelas perguntas, pelos desafios e pela vontade constante de aprender. Ensinar é uma das melhores formas de continuar aprendendo.

Parabéns a todos que concluíram esta jornada! Cada certificado representa muito mais do que horas de estudo: representa disciplina, perseverança e o desejo de evoluir profissionalmente.

Que este seja apenas o início de uma longa trajetória de sucesso no ecossistema IBM Z e no desenvolvimento de aplicações corporativas.
Nos vemos nos próximos desafios.

O aprendizado nunca termina.
Parabéns, turma APPDEV 2025!

Foi um privilégio fazer parte dessa história.
#APPDEV2025 #IBM #IBMZ #Mainframe #COBOL #EnterpriseComputing #ApplicationDevelopment #TechEducation #Learning #DigitalTransformation #IBMSkills #OpenMainframe #SystemZ #Gratidão #Parabéns

We are excited to announce the launch of our new project! #newproject

quinta-feira, 25 de junho de 2026

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

 

Bellacosa Mainframe e divida tecnica, engenharia do caos e resiliencia no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

Uma viagem dos cartões perfurados à engenharia de confiabilidade moderna

Existe uma curiosidade interessante sobre o universo Mainframe.

Boa parte dos desenvolvedores mais jovens acredita que sistemas COBOL foram escritos uma única vez, colocados em produção em algum momento dos anos 80 e simplesmente ficaram funcionando até hoje, imutáveis, como fósseis tecnológicos preservados em um museu digital.

A realidade é completamente diferente.

Poucas plataformas de tecnologia evoluíram tanto quanto o ecossistema IBM Z.

O hardware mudou.

O sistema operacional mudou.

Os compiladores mudaram.

As técnicas de desenvolvimento mudaram.

A forma de entregar software mudou.

As exigências regulatórias mudaram.

E os desenvolvedores também precisaram mudar.

Hoje falamos sobre APIs REST, Git, DevOps, Inteligência Artificial, Observabilidade, Chaos Engineering e Cloud Native. Entretanto, curiosamente, os sistemas que movimentam bilhões de dólares por dia continuam sendo executados por programas COBOL escritos há décadas.

Seria isso uma contradição?

Na verdade, não.

Talvez seja justamente uma demonstração de sucesso.

O primeiro legado não foi um erro

Em 1959 nasceu o COBOL.

Naquela época não existiam metodologias ágeis.

Não existia internet.

Não existiam smartphones.

Muitos programas eram escritos em cartões perfurados.

Armazenamento era caro.

Memória era limitada.

CPU era um recurso precioso.

As equipes construíam software pensando em algo muito importante:

Confiabilidade.

A aplicação precisava funcionar.

Sempre.

Mesmo que demorasse algumas horas para processar milhares de contas bancárias durante a madrugada.

Foi nesse ambiente que nasceu uma cultura extremamente disciplinada.

Documentação.

Padrões.

Controle de mudanças.

Testes.

Auditorias.

Processos.

Talvez os desenvolvedores daquela época não soubessem, mas estavam criando alguns dos primeiros conceitos de Engenharia de Confiabilidade.

Technical Debt: a dívida que todos nós fazemos

Em 1992, Ward Cunningham criou uma analogia brilhante.

Ele comparou decisões de desenvolvimento com empréstimos bancários.

Imagine que você precise entregar um sistema até sexta-feira.

Você poderia construir uma solução perfeita.

Ou poderia desenvolver algo funcional, mais simples, entregando rapidamente.

Você ganha velocidade.

Mas assume uma dívida.

E como toda dívida, ela possui juros.

Esses juros aparecem de várias formas.

Mais bugs.

Mais incidentes.

Mais retrabalho.

Maior consumo de CPU.

Maior dificuldade de manutenção.

Menor velocidade de inovação.

No Mainframe isso acontece frequentemente.

Talvez exista um programa COBOL com 25 mil linhas.

Talvez exista um COPYBOOK criado em 1987.

Talvez apenas um profissional conheça determinada aplicação.

Tudo isso representa dívida técnica.

O problema não é possuir dívida.

O problema é não saber que ela existe.

Nem toda dívida é ruim

Muitos desenvolvedores iniciantes acreditam que Technical Debt sempre significa erro.

Não é verdade.

Às vezes ela é estratégica.

Um banco pode precisar adequar sistemas rapidamente para atender uma nova regulamentação do BACEN.

Uma seguradora pode precisar disponibilizar um novo produto imediatamente.

Uma fintech pode lançar um MVP para validar mercado.

Nesses casos, assumir dívida técnica pode ser perfeitamente aceitável.

Desde que exista um plano para pagá-la posteriormente.

E aqui encontramos uma das primeiras lições importantes para um desenvolvedor COBOL júnior:

Escreva código pensando que alguém precisará entendê-lo daqui a dez anos.

Esse alguém pode ser você mesmo.

O mito da reescrita completa

Existe uma frase bastante comum em empresas:

"Precisamos jogar tudo fora."

Geralmente essa frase surge quando o ambiente está muito complexo.

Mas a IBM apresenta uma visão diferente.

Você não precisa substituir quarenta anos de sistemas.

Você pode modernizar gradualmente.

Esse conceito ficou conhecido como Strangler Pattern.

Imagine um sistema COBOL que processa contas correntes.

Ele continua funcionando.

Mas uma nova camada é criada.

z/OS Connect.

APIs REST.

Microserviços.

Containers.

Aplicações Java.

Python.

Inteligência Artificial.

O COBOL permanece processando transações críticas.

As aplicações modernas apenas consomem seus serviços.

A dívida começa a diminuir sem que seja necessário desligar o coração operacional da empresa.

Testes automatizados são seus melhores amigos

Durante muitos anos, testar em Mainframe significava reservar uma janela de homologação.

Executar jobs.

Analisar relatórios.

Esperar dias.

Hoje isso mudou.

Ferramentas como zUnit permitem criar testes automatizados.

Jenkins integra pipelines.

GitHub Actions executa validações.

DBB facilita builds.

Zowe aproxima o mundo Mainframe das práticas DevOps modernas.

Se você está começando em COBOL, desenvolva o hábito de pensar:

"O que acontece se o CPF estiver inválido?"

"E se a data vier vazia?"

"E se houver overflow?"

Programadores experientes não escrevem apenas funcionalidades.

Eles escrevem confiança.

Code Review: aprendendo com outros desenvolvedores

Uma das melhores maneiras de evoluir tecnicamente é revisar código.

Olhar programas COBOL antigos.

Analisar SQL.

Entender JCLs.

Perguntar.

Questionar.

Aprender.

Muitos problemas são identificados antes mesmo de chegar à produção.

Um cursor esquecido.

Um COMMIT ausente.

Um SORT desnecessário.

Uma consulta DB2 sem índice adequado.

Dois pares de olhos normalmente enxergam mais do que um.

Refatoração não significa reescrever

Refatorar é melhorar.

Não é destruir.

Não é começar do zero.

Pequenas melhorias acumuladas ao longo do tempo fazem enorme diferença.

Renomear variáveis.

Extrair rotinas.

Separar módulos.

Eliminar GOTO.

Criar serviços reutilizáveis.

Transformar programas gigantes em componentes menores.

Refatoração contínua é uma das formas mais eficientes de pagar Technical Debt.

Observabilidade: enxergando o que realmente acontece

Existe uma frase bastante conhecida:

Se você não consegue medir, não consegue melhorar.

No mundo IBM Z temos ferramentas extraordinárias.

SMF.

RMF.

OMEGAMON.

Instana.

Grafana.

Elas permitem compreender:

CPU.

I/O.

Latência.

Filas.

Conexões.

Transações.

Antes de corrigir qualquer problema, precisamos enxergá-lo.

Observabilidade é a base da engenharia moderna.

Chaos Engineering: quebrando para aprender

Talvez o conceito mais surpreendente para desenvolvedores COBOL seja Chaos Engineering.

A ideia surgiu popularmente na Netflix.

Mas a IBM mostra que ela pode ser aplicada em praticamente qualquer ambiente.

O princípio é simples.

Não espere uma falha em produção.

Provoque pequenas falhas.

Aprenda.

Corrija.

Teste novamente.

Por exemplo:

O que acontece se o IMS Connect ficar indisponível?

Se a fila MQ atingir 95% de ocupação?

Se um membro do Sysplex parar?

Se o DB2 responder lentamente?

Chaos Engineering não significa desligar servidores aleatoriamente.

É ciência.

Você cria uma hipótese.

Executa um experimento controlado.

Observa.

Aprende.

Melhora.

Repete.

Resiliência é um investimento

A IBM utiliza uma analogia muito interessante.

Imagine um ciclista.

Ele pode sair apenas com a bicicleta.

Ou levar uma bomba de ar.

Kit de reparo.

Câmara reserva.

Pneu reserva.

Carro de apoio.

Mecânico.

Quanto maior a disponibilidade desejada, maior será o custo.

Em tecnologia ocorre exatamente o mesmo.

Alta disponibilidade.

Disaster Recovery.

Cyber Recovery.

Backups.

Replicação.

GDPS.

Sysplex.

Active-Active.

Tudo possui custo.

O objetivo não é atingir disponibilidade infinita.

O objetivo é encontrar equilíbrio entre risco, orçamento e necessidade do negócio.

O desenvolvedor COBOL de 2026

O profissional COBOL moderno não é apenas alguém que conhece MOVE, PERFORM e READ.

Ele entende Git.

Conhece APIs.

Aprende DevOps.

Sabe interpretar métricas.

Participa de revisões.

Automatiza testes.

Compreende observabilidade.

Conhece conceitos de segurança.

Entende resiliência.

Estuda Inteligência Artificial.

E principalmente, continua cultivando algo que sempre esteve presente no universo Mainframe:

Disciplina técnica.

Os sistemas que movimentam bilhões de transações diariamente não permanecem relevantes por acaso.

Eles permanecem relevantes porque existem profissionais dispostos a compreender o passado, melhorar continuamente o presente e testar constantemente o futuro.

E talvez seja exatamente essa a maior lição do Mainframe.

Tecnologia muda.

Ferramentas mudam.

Buzzwords mudam.

Mas excelência em engenharia continua sendo atemporal.

E isso, felizmente, nunca sai de moda.

Até o próximo café.

☕ Bellacosa Mainframe


Bellacosa Mainframe Network

Siga nossas newsletters e comunidades no LinkedIn

quarta-feira, 24 de junho de 2026

Os Guardiões Invisíveis do Reino IBM Z ACEE, SAF e APF – As Três Relíquias que Protegem Trilhões de Dólares Todos os Dias

 

Bellacosa Mainframe e os guardioes do reino ibm z acee saf e apf

☕💥 Um Café no Bellacosa Mainframe

Os Guardiões Invisíveis do Reino IBM Z

ACEE, SAF e APF – As Três Relíquias que Protegem Trilhões de Dólares Todos os Dias

Por Vagner Bellacosa – Bellacosa Mainframe

Existe algo curioso sobre segurança em Mainframe.

Quase todo mundo conhece RACF.

Muitos ouviram falar de SAF.

Poucos sabem explicar o que realmente é um ACEE.

E uma quantidade ainda menor entende por que o APF talvez seja um dos componentes mais importantes de toda a arquitetura do z/OS.

A verdade é que, por trás das telas verdes, dos CICS, dos IMS, dos DB2 e dos bilhões de transações financeiras processadas diariamente, existe um pequeno conjunto de tecnologias silenciosas que trabalha vinte e quatro horas por dia, sete dias por semana, há décadas, praticamente sem reconhecimento.

São os verdadeiros guardiões do Reino IBM Z.

E talvez seja hora de apresentar estes personagens aos novos Padawans do z/OS.

O Reino IBM Z

Gosto bastante de utilizar uma analogia medieval para explicar segurança no Mainframe.

Imagine um enorme castelo.

Existem bibliotecas.

Existe um tesouro.

Existem escribas.

Existem correios.

Existem soldados.

Existe um cartório.

E existe o Rei.

No Reino IBM Z, podemos imaginar algo semelhante.

CICS é a administração do castelo.

IMS é o departamento financeiro.

DB2 é a biblioteca.

MQ é o correio.

USS é o bairro moderno onde vivem os moradores Unix.

SMF é o historiador oficial.

RACF é o cartório real.

O Sysprog é o guardião das chaves.

Mas três personagens trabalham praticamente o tempo inteiro.

SAF.

ACEE.

APF.

Eles são pouco conhecidos pelos desenvolvedores COBOL.

Quase invisíveis para operadores.

E absolutamente fundamentais para os Sysprogs.

SAF – O Porteiro Invisível

Um dos maiores equívocos entre profissionais iniciantes é acreditar que CICS conversa diretamente com RACF.

Ou que DB2 consulta diretamente o RACF.

Ou ainda que MQ valida permissões diretamente no banco de dados de segurança.

Na realidade, quase todos os produtos do z/OS conversam primeiro com o SAF.

SAF significa System Authorization Facility.

Ele pode ser entendido como um grande barramento de segurança.

Ou melhor.

Um porteiro.

Imagine uma recepção sofisticada na entrada do castelo.

Toda pessoa que deseja entrar em uma sala precisa passar pela recepção.

A recepcionista não toma decisões.

Ela apenas consulta o cartório.

Recebe uma resposta.

E libera ou bloqueia a passagem.

SAF funciona exatamente assim.

Aplicação.

SAF.

RACF.

Resposta.

Isso permite que produtos IBM e produtos terceiros utilizem um mecanismo único de autorização.

Foi uma ideia brilhante da IBM.

Caso contrário, CICS precisaria implementar seu próprio sistema de segurança.

IMS teria outro.

DB2 outro.

MQ outro.

USS outro.

Seria praticamente impossível administrar um ambiente corporativo de grande porte.

Hoje, bilhões de solicitações de segurança passam pelo SAF diariamente.

E a maioria das pessoas sequer percebe sua existência.

ACEE – O Crachá Mágico

Outro personagem pouco conhecido é o ACEE.

Access Control Environment Element.

Se o SAF é o porteiro, o ACEE é o crachá.

Imagine um funcionário chegando ao prédio.

No primeiro acesso ele apresenta documentos.

Passa por verificações.

Tem sua identidade validada.

Recebe um crachá.

A partir daquele momento não precisa mostrar documentos novamente.

Basta apresentar o crachá.

O ACEE funciona exatamente desta maneira.

Quando um usuário faz LOGON no TSO.

Ou acessa um CICS.

Ou estabelece uma sessão SSH.

O RACF executa um VERIFY.

Autentica o usuário.

Cria um ACEE.

E entrega esse contexto de segurança para a aplicação.

O ACEE contém informações extremamente importantes.

Userid.

Grupos.

UID Unix.

Certificados.

Labels.

Atributos especiais.

Contexto OMVS.

Permissões.

Flags.

Tudo armazenado em memória.

O objetivo é simples.

Evitar milhões de consultas desnecessárias ao RACF.

Imagine um banco processando cem mil transações por segundo.

Sem ACEE.

Cada autorização consultaria novamente o banco de segurança.

Seria inviável.

Com ACEE.

O sistema apenas consulta estruturas já residentes em memória.

Menos CPU.

Menos I/O.

Menos contenção.

Maior escalabilidade.

Talvez o ACEE seja um dos control blocks com melhor retorno sobre investimento da história da computação corporativa.

APF – O Selo Dourado do Reino

Mas existe algo ainda mais poderoso.

APF.

Authorized Program Facility.

Este é provavelmente o componente mais respeitado por um Sysprog experiente.

E também um dos mais perigosos.

No Reino IBM Z, podemos imaginar APF como um selo dourado concedido pelo Rei.

Nem todos recebem este selo.

Somente programas altamente confiáveis.

Programas autorizados podem executar serviços privilegiados.

Manipular armazenamento protegido.

Executar operações supervisor state.

Realizar chamadas especiais.

Interagir profundamente com o núcleo do sistema.

Mas isso possui um preço.

Um programa autorizado incorretamente pode comprometer toda a integridade do ambiente.

Por isso, APF é tratado com extremo cuidado.

Para que um módulo seja considerado autorizado normalmente dois requisitos precisam ser atendidos.

Primeiro.

O programa deve possuir AC(1).

Segundo.

A biblioteca onde reside deve estar presente na lista APF.

Caso contrário.

Nada feito.

O z/OS simplesmente não concede os privilégios especiais.

E é justamente isso que protege o sistema.

Quando Tudo Dá Errado

Todo Sysprog eventualmente recebe uma ligação de madrugada.

03:17.

Produção parada.

DB2 acusa segurança.

MQ acusa RACF.

USS apresenta Permission Denied.

CICS responde Not Authorized.

E alguém inevitavelmente diz:

"O problema é no RACF."

Talvez.

Mas talvez não.

O profissional experiente sabe que precisa investigar.

Verificar SMF80.

Consultar zSecure.

Analisar mensagens ICH408I.

Abrir IPCS.

Localizar o ACEE.

Examinar o contexto.

Conferir grupos.

Checar FASTAUTH.

Validar APF.

Verificar classes.

Observar RCs.

Interpretar RSNs.

Porque o dump raramente mente.

As pessoas podem se confundir.

Aplicações podem mascarar erros.

Logs podem induzir interpretações equivocadas.

Mas o dump normalmente conta exatamente a história que aconteceu.

O Segredo do IBM Z

A grande beleza do Mainframe não está apenas em processar milhões de transações.

Está em sua arquitetura.

IBM não criou simplesmente ferramentas.

Criou camadas.

Criou isolamento.

Criou mecanismos de desacoplamento.

Criou contexto.

Criou auditoria.

Criou proteção.

SAF desacopla aplicações do mecanismo de segurança.

ACEE desacopla autenticação das verificações constantes.

APF desacopla programas comuns de funções críticas do sistema operacional.

SMF registra tudo.

ICSF protege chaves.

RACF define regras.

E o Sysprog garante que todas essas peças continuem funcionando em perfeita harmonia.

A Lição Final do Padawan

Talvez a principal lição para um Sysprog iniciante seja entender que segurança no z/OS não é apenas RACF.

Segurança é um ecossistema.

Hardware criptográfico.

ICSF.

SAF.

RACF.

SMF.

APF.

ACEE.

Auditoria.

Processos.

Pessoas.

Boas práticas.

Governança.

Monitoramento.

E principalmente conhecimento.

Porque no fim das contas, o verdadeiro Guardião do Reino IBM Z não é aquele que apenas executa comandos.

É aquele que compreende por que cada tecnologia foi criada.

Como ela conversa com as demais.

Como diagnosticar seus problemas.

Como protegê-la.

Como evoluí-la.

E como garantir que, mesmo às três horas da manhã, quando o telefone tocar e alguém disser que o RACF está quebrado, ele consiga abrir um dump, seguir o caminho até o ACEE, verificar o contexto SAF, analisar APF e devolver ao Reino IBM Z aquilo que ele faz melhor há décadas:

Disponibilidade.

Integridade.

Confidencialidade.

E a tranquilidade de saber que trilhões de dólares continuam circulando silenciosamente pelo mundo, protegidos por tecnologias que quase ninguém vê, mas que todo Sysprog deveria conhecer profundamente.

"O RACF conhece as leis. O SAF atende as portas. O ACEE acompanha o viajante. O APF protege os segredos do castelo. E o Sysprog mantém o Reino IBM Z de pé, uma madrugada de cada vez."

Bellacosa Mainframe

 

terça-feira, 23 de junho de 2026

A Saga de Vagner Bellacosa no Reino dos Mainframes

 



☕💥 A Saga de Vagner Bellacosa no Reino dos Mainframes

Ou como um jovem padawan descobriu que COBOL dá mais XP que matar dragões

Bellacosa Mainframe e historias de velhos cpds em mainframe


Salve jovem padawan.

Pegue um café.

Se for diabético, pegue sem açúcar.

Se estiver em produção, pegue dois.

Hoje vou contar uma história.

Não a história de um herói tradicional.

Nada de capa.

Nada de espada mágica.

Nada de armadura lendária.

Nosso protagonista usa crachá corporativo, camisa social amassada, óculos cansados, carrega uma mochila cheia de apostilas IBM dos anos 90 e combate criaturas muito mais perigosas que dragões.

Ele atende pelo nome de Vagner Bellacosa.


O chamado da aventura

Toda jornada começa de maneira inocente.

Alguns encontram um anel.

Outros encontram uma espada cravada numa pedra.

Bellacosa encontrou...

Um terminal 3270.

Tela preta.

Letras verdes.

Cursor piscando.

Silêncio.

Nenhum botão.

Nenhum mouse.

Nenhum TikTok.

Nenhum React.

Nenhum Kubernetes.

Apenas um campo escrito:

LOGON ===>

Naquele instante existiam apenas duas possibilidades.

Primeira:

Desligar o computador e cursar gastronomia.

Segunda:

Digitar o usuário.

Ele digitou.

E nunca mais foi o mesmo.


O primeiro ABEND

Todo herói precisa sofrer.

Luke perdeu a mão.

Frodo quase perdeu a alma.

Bellacosa ganhou seu primeiro:

S0C7.

E descobriu algo curioso.

No Mainframe ninguém fala:

"Tem bug."

Todos falam:

— Deu ABEND.

ABEND parece nome de chefe final.

Você passa oito horas procurando.

Consulta dump.

Abre SYSOUT.

Lê JESMSGLG.

Olha o compile listing.

Chama o colega.

Chama outro colega.

Chama o especialista.

Chama um padre.

E no final descobre:

O campo numérico tinha espaço em branco.

Aí você aprende humildade.


Banco Real, a Terra Média dos Dinossauros Digitais

Existiu uma época gloriosa.

A época em que o Banco Real possuía milhares de programas.

Centenas de analistas.

Adabas.

Natural.

PLI.

JCL.

Control-M.

CICS.

VSAM.

RACF.

E um exército de desenvolvedores sobrevivendo a janelas batch.

Era uma civilização inteira.

Uma espécie de Atlântida tecnológica.

Enquanto a internet ainda fazia:

Piiiiiiiiiiiii....

Krrrttttt...

Biiiiiippp...

O Mainframe já processava milhões de registros.

Sem Kubernetes.

Sem Docker.

Sem palestra motivacional.

Sem coach dizendo:

"Escalone sua vida."

O Mainframe apenas respondia:

— JOB EXECUTADO RC=0000

E seguia trabalhando.


O homem que conversava com os programas Natural

Chegou então o Bug do Milênio.

O apocalipse anunciado.

Consultorias ficaram ricas.

Executivos ficaram nervosos.

Gerentes envelheceram.

Bellacosa teve uma ideia.

Criar um extrator.

Mas não qualquer extrator.

Um monstro.

Um PLI autorecursivo.

Um pequeno T-800 em formato de JCL.

Ele lia.

Interpretava.

Gerava JCL.

Enfileirava jobs.

Chamava a si próprio.

Criava novos filhos.

Extraía fontes.

Analisava objetos.

Preenchia bibliotecas.

E continuava trabalhando.

Sozinho.

Por 48 horas.

Consumindo CPU.

Consumindo spool.

Consumindo a sanidade do operador.

Quando terminou...

Meio milhão de objetos haviam sido catalogados.

Hoje chamaríamos isso de:

Pipeline de DevOps.

Na época chamava-se:

"Coisa do Bellacosa."


O Grande Inquisidor da DAI

Mas nenhum guerreiro evolui sem enfrentar a polícia secreta.

DAI.

Três letras capazes de congelar a alma.

Ser chamado pela DAI era equivalente a ouvir:

"Precisamos conversar."

Você imediatamente pensava:

Meu RACF vazou?

Compilei em produção?

Rodei a Loteca?

Usei a transação proibida?

Não.

Queriam apenas um relatório.

Um relatório pequeno.

Só precisava analisar milhares de logs.

Consultar usuários.

Cruzar tabelas.

Gerar dezenas de milhares de páginas.

Em 72 horas.

Sem errar.

Sem testar direito.

Sem segunda chance.

Bellacosa codificou.

Revisou.

Debugou com caneta.

Rezou.

Entregou.

Funcionou.

E descobriu uma lição importante.

Programador Mainframe não envelhece.

Ele acumula PTSD de produção.


O evangelista improvável

Décadas se passaram.

Muitos colegas migraram.

Viraram arquitetos.

Gerentes.

Executivos.

Consultores.

Alguns abriram startups.

Outros abriram adegas.

Bellacosa resolveu algo diferente.

Contar histórias.

Escrever artigos.

Criar newsletters.

Ensinar COBOL.

Explicar CICS.

Falar sobre VSAM.

Defender o velho gigante preto da IBM.

Transformar dump em entretenimento.

Transformar S0C4 em meme.

Transformar SYSUDUMP em literatura fantástica.

Porque descobriu algo curioso.

O Mainframe nunca foi apenas tecnologia.

Foi amizade.

Foi mentor.

Foi Roseli.

Foi Tokunaga.

Foi auditor assustador.

Foi operador bravo.

Foi colega salvando produção às três da manhã.

Foi café requentado.

Foi pizza fria.

Foi aprender que existem pessoas que realmente se emocionam ao ver um RC=0000.

E tudo bem.

Somos poucos.

Somos estranhos.

Somos os últimos guardiões do EBCDIC.


Epílogo

Hoje existem inteligências artificiais.

Agentes autônomos.

LLMs.

Clouds infinitas.

Quantum Computing.

Promessas de substituir COBOL.

Promessas de desligar Mainframe.

Promessas de reescrever tudo.

Promessas.

Muitas promessas.

Enquanto isso...

Em algum lugar do planeta...

Um CICS iniciado em 1998 continua processando cartões.

Um DB2 continua pagando aposentadorias.

Um VSAM continua guardando informações valiosas.

Um JCL continua rodando.

E um Bellacosa continua tomando café.

Escrevendo artigos.

Chamando leitores de padawans.

Contando histórias.

E lembrando a todos nós que talvez o verdadeiro legado do Mainframe nunca tenha sido o hardware.

Mas as pessoas malucas o suficiente para dedicar a vida inteira a fazê-lo funcionar.

E sinceramente...

Ainda bem que existem esses malucos.

Esse texto ficou bem próximo do tom clássico de "Histórias do Tiozão em Mainframe", misturando autobiografia, nostalgia, cultura pop, autoironia e reverência aos velhos guerreiros do z/OS. (DIO)

segunda-feira, 22 de junho de 2026

☕💥 Quando um Dataset VSAM Corrompe no z/OS: Guia de Sobrevivência para Sysprogs, Desenvolvedores COBOL e Administradores CICS

 

Bellacosa Mainframe uma pequena ajudinha recuperando dataset vsam

☕💥 Quando um Dataset VSAM Corrompe no z/OS: Guia de Sobrevivência para Sysprogs, Desenvolvedores COBOL e Administradores CICS

"Há dois tipos de profissionais de Mainframe: os que já recuperaram um dataset corrompido e os que ainda vão recuperar."


Introdução

Poucas mensagens conseguem acelerar tanto os batimentos cardíacos de um profissional de Mainframe quanto estas:

IDC3302I ACTION ERROR
IDC3351I VSAM OPEN RETURN CODE 168
IEC161I
IEC070I
DFHFC0157

Ou pior ainda:

"O arquivo de clientes não abre em produção."

Silêncio.

O scheduler para.

O CICS começa a emitir mensagens.

Os jobs entram em abend.

O telefone toca.

Alguém pergunta:

"Tem backup?"

E nesse momento percebemos que existe uma grande diferença entre saber programar COBOL, conhecer VSAM e realmente entender o processo de recuperação de corrupção em datasets no z/OS.

Hoje vamos tomar um café e conversar sobre um assunto pouco ensinado em treinamentos, mas extremamente valorizado em bancos, seguradoras, companhias aéreas e órgãos governamentais:

Como recuperar um dataset VSAM corrompido no z/OS.


O que significa um Dataset Corrompido?

Nem toda falha é uma corrupção.

Às vezes é apenas um catálogo inconsistente.

Em outros casos temos problemas muito mais graves.

Exemplos:

  • EOF inconsistente

  • HURBA inválido

  • HARBA incorreto

  • Alternate Index quebrado

  • Cadeia lógica danificada

  • Control Interval inválida

  • Problemas na VTOC

  • SMSVSAM inconsistente

  • CI Split interrompido

  • Erros físicos em disco


Primeira Regra: Pare Tudo

O maior erro que vejo iniciantes cometerem é tentar "olhar rapidamente".

Não.

Pare imediatamente.

Batch

Segure scheduler.

CA7

Control-M

TWS


CICS

Fechar arquivo.

CEMT SET FILE(CUSTFILE) CLOSED

ou

CEMT SET FILE(CUSTFILE) DISABLED

IMS

/DBR CUSTOMER

Started Tasks

Encerrar consumidores.

MQ

Connectors

Replication

ETL

CDC


A regra é simples.

Dataset suspeito.

Sem acesso.

Sem exceções.


Segunda Etapa: LISTCAT

Antes de sair executando VERIFY.

Olhe o paciente.

Comando

//STEP1 EXEC PGB=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *

 LISTCAT ENT(PROD.CUST.KSDS)
 ALL

/*

O que analisar?

Cluster

Data Component

Index Component

Volume

HI-USED-RBA

Catalog

SMS Classes


Exemplo

HURBA = 000001987654
HARBA = 000001999999

Valores estranhos podem indicar inconsistências.


VERIFY

Provavelmente a ferramenta mais subestimada do IDCAMS.


Função

Sincronizar.

Catalog

Volume

EOF

RBA

Informações físicas


Exemplo

VERIFY DATASET(PROD.CUST.KSDS)

Com recuperação:

VERIFY DATASET(PROD.CUST.KSDS)
RECOVER

O VERIFY resolve

EOF incorreto

Catalog inconsistente

Discrepâncias simples

Alguns problemas em KSDS


Mas atenção.

VERIFY não é mágica.

Ele não reconstrói uma estrutura destruída.


EXAMINE

Agora começa a parte realmente interessante.

EXAMINE é quase um scanner médico do VSAM.


Data Component

EXAMINE -
NAME(PROD.CUST.KSDS)
DATATEST

Índice

EXAMINE -
NAME(PROD.CUST.KSDS)
INDEXTEST

Completo

EXAMINE -
NAME(PROD.CUST.KSDS)
DATA

O que ele encontra?

Control Interval inválida

Ponteiros quebrados

Índices inconsistentes

RBAs errados

Registros perdidos


A Grande Pergunta

Após EXAMINE surge a decisão.

Corrupção pequena?

ou

Corrupção severa?

Essa decisão define tudo.


Cenário 1 — Corrupção Leve

Exemplos.

Catalog inconsistente.

EOF errado.

Pequenos danos.


Solução.

VERIFY

REPRO

Rebuild


REPRO

Criar novo cluster.

DEFINE CLUSTER(...)

Copiar.

REPRO -
INFILE(IN1)
OUTFILE(OUT1)

Muitas vezes isso resolve.

Surpreendentemente.


Cenário 2 — Corrupção Grave

Aqui muda completamente.

Nunca seja herói.

Backup sempre vence.


Restore

Melhor prática.

Sempre.


DFSMSdss

RESTORE DATASET(...)

HSM

HRECOVER

FDR

RESTORE TYPE=DS

E se não existir backup?

Infelizmente acontece.

Mais vezes do que deveria.


Estratégia

Salvar o que for possível.

Criar novo dataset.

Tentar REPRO.

Descartar registros inválidos.

Reconstruir índices.


Alternate Index

Muitos esquecem do AIX.

Ele também pode corromper.


Rebuild

BLDINDEX

Ou.

Excluir.

Criar novamente.

Popular.


Recuperação de Catálogo

Uma área extremamente especializada.

Pouca gente domina.

Muito valorizada.


DIAGNOSE

DIAGNOSE

EXPORT

EXPORT -
CATALOG(MYCAT)
TEMPORARY

IMPORT

IMPORT CONNECT

Ambientes CICS

A situação muda bastante.

Especialmente em RLS.


SMSVSAM

Cache compartilhado.

Lock global.

Coupling Facility.

Múltiplas regiões.


Problemas comuns.

CF inconsistente.

Lock perdido.

Buffer inválido.


Procedimento

Fechar arquivos.

Verificar SMSVSAM.

Executar VERIFY.

EXAMINE.

Restore.

Abrir novamente.


Ambientes Bancários

O fluxo normalmente é.


Incidente aberto.

Congelamento.

Snapshot.

LISTCAT.

VERIFY.

EXAMINE.

Análise.

Restore.

Testes.

Validação.

Produção.


Testes Pós-Recovery

Nunca devolver imediatamente.

Teste.

Leia registros.

Atualize.

Delete.

Browse.

Sequencial.

Random.


Batch

Executar programas COBOL.

Validar.

Retorno.

SMF.

CPU.

EXCP.


CICS

Abrir arquivo.

Executar transações.

CRUD.

Commit.

Syncpoint.


IMS

DBOPEN.

GN.

GU.

REPL.

DLET.


Ferramentas Úteis

IDCAMS

DFSMSdss

DFSMShsm

FDR

LISTCAT

VERIFY

EXAMINE

BLDINDEX

DIAGNOSE


O que Aprendemos?

O Mainframe continua sendo uma das plataformas mais resilientes do planeta.

Mas nenhuma tecnologia é imune.

Discos falham.

Pessoas erram.

Jobs são cancelados.

Aplicações apresentam bugs.

Volumes ficam inconsistentes.

Catálogos podem sofrer danos.

A diferença entre um desastre e uma recuperação tranquila quase sempre está em três fatores.

Backup.

Procedimentos.

Conhecimento.

Um desenvolvedor COBOL que entende apenas READ, WRITE e REWRITE é valioso.

Um desenvolvedor que compreende LISTCAT, VERIFY, EXAMINE, REPRO, recuperação de catálogo e estratégias de restore torna-se um profissional muito mais próximo do universo de Sysprog, Storage e Administração z/OS.

E essa é justamente uma das características que mais diferencia especialistas Mainframe experientes.

Porque no fim do dia, quando o telefone toca e alguém diz:

"O arquivo de produção corrompeu..."

A pergunta deixa de ser:

"Quem programou isso?"

E passa a ser:

"Quem sabe trazer a base de volta?"

E, acredite, nas grandes corporações, essas pessoas são lembradas por muitos anos.


Bellacosa Mainframe

"Transformando mensagens IDCAMS em oportunidades de aprendizado, um café por vez."


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