☕ 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 IBM Mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IBM Mainframe. Mostrar todas as mensagens

segunda-feira, 3 de agosto de 2026

ATS Friendly — O Dia em que Patrick Jane Investigou o Seu Currículo COBOL

Bellacosa Mainframe apresenta o ats friendly

 

☕ Um Café no Bellacosa Mainframe

ATS Friendly — O Dia em que Patrick Jane Investigou o Seu Currículo COBOL

Imagine a seguinte cena.

Uma grande empresa publica uma vaga para programador COBOL iniciante. O anúncio parece ter sido escrito especialmente para você:

  • COBOL;

  • JCL;

  • Db2;

  • CICS;

  • z/OS;

  • Git;

  • noções de DevOps;

  • vontade de aprender;

  • capacidade de trabalhar em equipe.

Você lê tudo, ajeita o currículo, salva o arquivo com um nome elegante e clica em “Enviar candidatura”.

Silêncio.

Nenhuma mensagem.

Nenhum telefonema.

Nenhuma entrevista.

Nada.

Você olha para a tela e pensa:

— Será que o recrutador não gostou de mim?

Mas existe uma possibilidade ainda mais intrigante: talvez o recrutador nunca tenha visto o seu currículo.

Antes que uma pessoa de Recursos Humanos leia sua experiência, seus cursos, seus projetos e suas certificações, existe uma boa chance de que o documento precise passar por uma espécie de porteiro eletrônico.

Esse porteiro atende pelo nome de ATS.

E, ao contrário de Patrick Jane, personagem da série The Mentalist, o ATS não observa seus gestos, não analisa seu tom de voz e não percebe quando você está nervoso.

Ele observa palavras.

Ele procura padrões.

Ele classifica informações.

Ele tenta entender se o seu currículo combina com a vaga.

Em outras palavras, o ATS é uma espécie de programa batch executado antes da entrevista.

Se a entrada estiver organizada, o processamento continua.

Se o layout estiver confuso, as palavras-chave estiverem ausentes e as informações importantes estiverem escondidas em caixas de texto, gráficos ou imagens, o job pode terminar com um elegante e silencioso:

COND CODE 0008
CANDIDATO NÃO LOCALIZADO

Bem-vindo ao mistério do currículo ATS Friendly.



1. O que significa ATS Friendly?

A expressão ATS Friendly significa que um currículo foi preparado para ser facilmente lido, interpretado e classificado por um Applicant Tracking System.

Em português, podemos traduzir ATS como:

Sistema de Rastreamento de Candidatos.

Esses sistemas são utilizados para ajudar empresas e recrutadores a:

  • receber currículos;

  • organizar candidaturas;

  • localizar profissionais;

  • comparar perfis;

  • pesquisar competências;

  • acompanhar etapas do processo seletivo;

  • filtrar candidatos conforme os requisitos de uma vaga.

Para um programador COBOL, a analogia é simples.

O ATS funciona como um processo que recebe um arquivo de entrada, tenta interpretar os campos e grava os resultados em uma base de dados.

Seu currículo é o arquivo de entrada.

O anúncio da vaga é a regra de validação.

As palavras-chave são os campos utilizados na comparação.

O recrutador é o usuário que consulta o resultado final.

Se o ATS consegue identificar corretamente seu nome, cargo, experiência, tecnologias e formação, seu currículo foi processado com sucesso.

Quando isso não acontece, informações importantes podem simplesmente desaparecer durante a leitura automática.


2. O ATS não é um vilão

Existe uma tendência de imaginar o ATS como uma inteligência artificial maligna sentada diante de milhares de currículos, eliminando candidatos por diversão.

Na prática, a ideia é menos dramática.

Imagine que uma empresa receba 1.500 candidaturas para uma única vaga.

Seria difícil para uma equipe pequena ler manualmente todos os documentos em pouco tempo. O ATS ajuda a organizar esse volume.

Ele permite que o recrutador procure, por exemplo:

COBOL AND CICS AND DB2

Ou:

MAINFRAME AND JCL AND Z/OS

Ou ainda:

COBOL AND GIT AND DEVOPS

O ATS também pode estruturar informações como:

  • nome do candidato;

  • cidade;

  • e-mail;

  • telefone;

  • empresas anteriores;

  • cargos ocupados;

  • datas;

  • formação;

  • certificações;

  • competências técnicas.

O problema não está necessariamente no sistema.

O problema aparece quando o currículo foi criado apenas para impressionar visualmente uma pessoa, mas não para ser compreendido por uma máquina.

Patrick Jane diria:

— O sistema não está escondendo a verdade. Ele está apenas interpretando os sinais que você deixou.


3. O currículo como um arquivo de entrada

Para compreender um currículo ATS Friendly, pense em um arquivo sequencial utilizado por um programa COBOL.

Imagine este layout:

01 REGISTRO-CANDIDATO.
   05 NOME-CANDIDATO        PIC X(50).
   05 CARGO-PRETENDIDO      PIC X(40).
   05 EXPERIENCIA           PIC X(500).
   05 COMPETENCIAS          PIC X(300).
   05 FORMACAO              PIC X(200).
   05 CERTIFICACOES         PIC X(300).

Agora imagine que alguém decida colocar o nome dentro de uma imagem, as competências dentro de um gráfico, as datas dentro de um rodapé e o telefone em uma caixa lateral.

Para uma pessoa, o currículo pode parecer bonito.

Para o ATS, o registro pode chegar assim:

NOME-CANDIDATO: EM BRANCO
CARGO-PRETENDIDO: NÃO IDENTIFICADO
COMPETENCIAS: PARCIAL
DATAS: INCONSISTENTES
TELEFONE: NÃO LOCALIZADO

Esse é o coração da questão.

Um currículo ATS Friendly não precisa ser feio.

Ele precisa ser estruturado.

A informação deve estar no lugar certo.

Os títulos devem ser claros.

As palavras devem estar escritas como texto.

O documento deve permitir que o sistema entenda sua história profissional sem depender de interpretação visual.



4. O primeiro princípio: simplicidade operacional

No mainframe, simplicidade não significa falta de poder.

Um JCL limpo, bem indentado e corretamente documentado pode executar uma tarefa crítica durante décadas.

Com o currículo acontece a mesma coisa.

Um currículo simples pode ser extremamente eficiente.

O formato mais seguro costuma utilizar:

  • uma única coluna;

  • títulos tradicionais;

  • texto alinhado;

  • listas simples;

  • datas claras;

  • nomes completos das tecnologias;

  • poucas variações de fonte;

  • espaçamento consistente.

Evite transformar o currículo em um pôster publicitário.

O objetivo não é criar uma propaganda de perfume.

O objetivo é facilitar a leitura técnica e humana.

O recrutador precisa encontrar rapidamente as informações relevantes.

O ATS também.



5. Layout de uma coluna

Currículos com duas ou três colunas podem causar problemas de interpretação.

Imagine que o ATS leia primeiro toda a coluna da esquerda e depois toda a coluna da direita. Informações que visualmente estavam relacionadas podem ser reorganizadas de forma incorreta.

Por exemplo:

IBM                     COBOL
Analista de Sistemas    CICS
2022 – Atual            Db2

Visualmente, isso pode parecer perfeito.

Mas o sistema pode interpretar:

IBM COBOL Analista de Sistemas CICS 2022 Atual Db2

O texto perde a estrutura.

Para evitar isso, prefira:

IBM
Analista de Sistemas
Janeiro de 2022 – Atual

Tecnologias:
COBOL, CICS, Db2, JCL e z/OS.

Simples.

Direto.

Sem mágica.

Patrick Jane observaria a página por alguns segundos e diria:

— A resposta estava diante de você. O excesso de design estava escondendo a informação.


6. Títulos tradicionais são seus aliados

Um ATS procura padrões conhecidos.

Por isso, use títulos como:

  • Resumo Profissional;

  • Objetivo Profissional;

  • Experiência Profissional;

  • Formação Acadêmica;

  • Certificações;

  • Competências Técnicas;

  • Idiomas;

  • Projetos;

  • Cursos Complementares.

Evite títulos criativos demais, como:

  • Minha Jornada;

  • Meus Superpoderes;

  • O Que Eu Faço de Melhor;

  • Minha Caixa de Ferramentas;

  • Aventuras Profissionais;

  • Grandes Batalhas.

Esses títulos podem ser simpáticos em um portfólio, mas não são ideais em um currículo destinado a processos automatizados.

Um sistema procura “Experiência Profissional”.

Ele pode não compreender que “Minhas Grandes Batalhas” significa a mesma coisa.

No Bellacosa Mainframe, criatividade é muito bem-vinda.

Mas até um Jedi precisa preencher corretamente o layout do arquivo.


7. Palavras-chave: o vocabulário secreto da vaga

As palavras-chave são um dos elementos mais importantes do currículo ATS Friendly.

Suponha que a vaga mencione:

  • Enterprise COBOL;

  • CICS Transaction Server;

  • Db2 for z/OS;

  • JCL;

  • VSAM;

  • Git;

  • Jenkins;

  • Agile;

  • APIs REST;

  • z/OS Connect.

Seu currículo deve incluir os termos que realmente fazem parte da sua experiência.

Não basta escrever apenas:

Experiência em tecnologias mainframe.

Essa frase é genérica demais.

É melhor escrever:

Experiência acadêmica e prática com COBOL, JCL, Db2 for z/OS, CICS, VSAM e ambiente z/OS.

Ou:

Desenvolvimento de programas COBOL para processamento batch, utilizando JCL, datasets sequenciais e arquivos VSAM.

Ou:

Projeto de integração entre aplicação COBOL e API REST por meio de conceitos de z/OS Connect.

Perceba que as palavras-chave aparecem dentro de um contexto real.

Isso é importante.

O currículo não deve parecer uma lista aleatória de tecnologias.

Ele deve mostrar como você utilizou ou estudou cada competência.



8. Não pratique keyword stuffing

Existe uma técnica ruim conhecida como keyword stuffing, que consiste em repetir palavras-chave de forma exagerada para tentar enganar sistemas de busca.

No currículo, isso poderia parecer assim:

COBOL COBOL COBOL CICS DB2 COBOL JCL CICS DB2 MAINFRAME MAINFRAME COBOL.

Isso não ajuda.

Além de tornar o texto artificial, pode prejudicar a leitura humana.

O recrutador quer compreender:

  • o que você sabe;

  • onde aprendeu;

  • como utilizou;

  • qual resultado alcançou;

  • qual seu nível de contato com a tecnologia.

A palavra-chave precisa aparecer naturalmente.

Patrick Jane não se impressionaria com repetições.

Ele perguntaria:

— Você realmente conhece CICS ou apenas escreveu CICS sete vezes?

  • O que é keyword stuffing

https://eljefemidnightlunch.blogspot.com/2013/01/csi-new-york-unidade-de-crimes-digitais.html


9. Como adaptar o currículo para uma vaga

Um dos maiores erros é enviar exatamente o mesmo currículo para todas as oportunidades.

Um currículo-base é importante, mas ele deve ser ajustado conforme a vaga.

Considere duas oportunidades.

Vaga A — Programador COBOL Batch

Requisitos:

  • COBOL;

  • JCL;

  • VSAM;

  • datasets;

  • SORT;

  • processamento batch.

Seu currículo deve destacar:

  • programas batch;

  • leitura e gravação de arquivos;

  • JCL;

  • SORT;

  • IDCAMS;

  • VSAM;

  • tratamento de retorno;

  • análise de ABEND.

Vaga B — Programador COBOL CICS

Requisitos:

  • COBOL;

  • CICS;

  • BMS;

  • Db2;

  • transações online;

  • COMMAREA;

  • mapas 3270.

Nesse caso, o currículo deve destacar:

  • CICS;

  • programas online;

  • LINK;

  • XCTL;

  • RETURN;

  • COMMAREA;

  • BMS;

  • Db2;

  • tratamento de erros SQL.

Você continua sendo a mesma pessoa.

Mas muda o foco da apresentação.

Isso não é manipulação.

É relevância.

Em programação, você não envia todos os campos de um banco de dados quando a API precisa apenas de cinco.

No currículo, você também prioriza aquilo que atende à consulta.


10. O resumo profissional

O resumo profissional é uma das primeiras áreas do currículo.

Ele deve apresentar rapidamente:

  • quem você é;

  • qual área busca;

  • quais tecnologias conhece;

  • qual valor oferece;

  • quais objetivos profissionais possui.

Para um programador COBOL iniciante, um exemplo poderia ser:

Profissional em formação na área de desenvolvimento IBM Mainframe, com conhecimentos em COBOL, JCL, Db2, VSAM e ambiente z/OS. Experiência prática em projetos acadêmicos envolvendo processamento batch, manipulação de arquivos e lógica estruturada. Busco oportunidade como programador COBOL júnior para aplicar conhecimentos técnicos, ampliar experiência em sistemas corporativos e contribuir com manutenção e modernização de aplicações críticas.

Observe que o resumo contém palavras-chave, mas também forma uma narrativa.

Não é apenas uma lista.

É uma apresentação.


11. Experiência profissional para quem ainda está começando

Muitos iniciantes dizem:

— Não tenho experiência. Meu currículo ficará vazio.

Isso não é verdade.

Experiência não significa apenas emprego formal.

Você pode incluir:

  • projetos acadêmicos;

  • bootcamps;

  • laboratórios;

  • desafios de código;

  • trabalho voluntário;

  • projetos pessoais;

  • exercícios relevantes;

  • repositórios GitHub;

  • participação em comunidades;

  • cursos com atividades práticas.

Por exemplo:

Projeto Acadêmico — Sistema de Cadastro em COBOL

Desenvolvimento de aplicação batch para inclusão, consulta e atualização de registros. Utilização de COBOL, JCL e arquivo sequencial. Implementação de validação de dados, tratamento de erros e geração de relatório de saída.

Outro exemplo:

Projeto Pessoal — Controle de Clientes com VSAM

Criação de programa COBOL para leitura e atualização de arquivo VSAM KSDS. Definição do cluster por meio de IDCAMS e execução do programa com JCL.

Outro:

Laboratório — Integração COBOL e Db2

Criação de consultas SQL embarcadas em programa COBOL, com tratamento de SQLCODE e exibição de mensagens de retorno.

Esses projetos demonstram aplicação prática.

O importante é ser honesto.

Não transforme um exercício de curso em cinco anos de experiência bancária.

Patrick Jane perceberia o exagero antes mesmo de você terminar a frase.


12. Use verbos de ação

As descrições ficam mais fortes quando começam com verbos objetivos.

Exemplos:

  • desenvolvi;

  • implementei;

  • analisei;

  • documentei;

  • corrigi;

  • automatizei;

  • testei;

  • integrei;

  • configurei;

  • monitorei;

  • otimizei;

  • participei;

  • apoiei;

  • criei;

  • mantive.

Compare:

Conhecimento de COBOL.

Com:

Desenvolvi programas COBOL para leitura, validação e processamento de arquivos sequenciais.

Compare:

Curso de JCL.

Com:

Criei e executei jobs JCL com etapas de compilação, linkedição e execução de programas COBOL.

Compare:

Noções de Db2.

Com:

Implementei consultas SQL em programas COBOL, utilizando SELECT, INSERT, UPDATE e tratamento de SQLCODE.

A segunda versão demonstra ação.


13. Competências técnicas

A seção de competências deve ser clara e organizada.

Exemplo:

Competências Técnicas

Linguagens:
COBOL, SQL e Python básico.

IBM Mainframe:
z/OS, TSO/ISPF, SDSF, JCL, VSAM, CICS e Db2.

Ferramentas:
Git, GitHub, Visual Studio Code e IBM Z Open Editor.

Conceitos:
Processamento batch, arquivos sequenciais, lógica estruturada, APIs REST e DevOps.

Essa estrutura ajuda tanto o ATS quanto o recrutador.

Evite barras gráficas como:

COBOL ████████ 80%
JCL  ██████ 60%
DB2  █████ 50%

Esses percentuais são subjetivos.

O que significa possuir 80% de COBOL?

Você sabe 80% de todas as instruções?

Domina 80% do compilador?

Resolve 80% dos ABENDs?

Conhece 80% do Language Environment?

Melhor indicar o contexto:

COBOL — projetos acadêmicos com processamento batch, arquivos sequenciais e VSAM.

Muito mais informativo.


14. Fontes e formatação

Utilize fontes comuns e fáceis de ler, como:

  • Arial;

  • Calibri;

  • Helvetica;

  • Verdana;

  • Times New Roman.

O tamanho pode variar, mas normalmente:

  • nome: entre 16 e 20 pontos;

  • títulos: entre 12 e 14 pontos;

  • corpo do texto: entre 10 e 12 pontos.

Não utilize cinco fontes diferentes.

Não transforme o currículo em um catálogo de estilos.

Um mainframe não precisa de luzes piscando para provar que processa milhões de transações.

Seu currículo também não.


15. Imagens, ícones e fotografias

Em currículos ATS Friendly, é mais seguro evitar:

  • fotografia;

  • logotipos;

  • ícones;

  • gráficos;

  • infográficos;

  • elementos decorativos;

  • textos dentro de imagens.

O problema não é apenas estético.

Um ícone de telefone pode não ser identificado como telefone.

Um ícone de e-mail pode não ser identificado como e-mail.

Por isso, escreva:

Telefone: +55 11 99999-9999
E-mail: nome@email.com
LinkedIn: linkedin.com/in/nome
GitHub: github.com/nome

Não dependa exclusivamente de símbolos.

Quanto à foto, sua inclusão depende do país, do mercado e da cultura local. Em muitos processos corporativos e internacionais, ela não é necessária.

Quando o objetivo principal é compatibilidade com ATS, a ausência de foto costuma simplificar o documento.


16. Cabeçalho e rodapé

Evite colocar informações críticas apenas no cabeçalho ou rodapé.

Alguns sistemas podem ignorar ou interpretar incorretamente essas áreas.

Não esconda seu telefone no rodapé.

Não coloque o e-mail apenas no cabeçalho.

Não deixe o LinkedIn em uma caixa flutuante.

Mantenha os contatos no corpo principal do documento, logo abaixo do nome.

Exemplo:

Vagner Bellacosa
Analista de Sistemas IBM Mainframe

Itatiba, São Paulo, Brasil
Telefone: +55...
E-mail: ...
LinkedIn: ...
GitHub: ...

17. Datas claras e consistentes

As datas devem seguir um padrão.

Exemplos adequados:

Janeiro de 2022 – Atual
01/2022 – Atual
2022 – 2025

Evite misturar formatos:

Jan 2022
02-23
Verão de 2024
Há três anos

O ATS trabalha melhor com consistência.

Além disso, datas claras facilitam a compreensão da evolução profissional.


18. PDF ou DOCX?

Os formatos mais comuns são:

  • DOCX;

  • PDF.

O DOCX costuma ser bem interpretado por diversos sistemas.

O PDF também pode funcionar muito bem, desde que tenha sido criado a partir de texto real.

Evite PDFs gerados como imagem.

Uma forma simples de testar é tentar selecionar o texto com o mouse.

Se você consegue copiar e colar o conteúdo normalmente, o documento provavelmente contém texto real.

Se toda a página se comporta como uma fotografia, o ATS pode ter dificuldade.

Quando a vaga informa um formato específico, siga exatamente a instrução.

Se ela pede DOCX, envie DOCX.

Se pede PDF, envie PDF.

Ignorar esse detalhe é como submeter um job com o nome errado do dataset e esperar que o sistema adivinhe.


19. Nome do arquivo

Nunca envie:

curriculo_final_novo_agora_vai_versao3.pdf

Use um nome profissional:

Vagner_Bellacosa_Curriculo_COBOL.pdf

Ou:

Vagner_Bellacosa_Mainframe_Developer.docx

O nome do arquivo também comunica organização.

Imagine o recrutador baixando 80 currículos chamados “curriculo.pdf”.

Seu nome precisa estar visível.


20. Ortografia e consistência

Erros de escrita prejudicam a credibilidade.

Revise:

  • nomes de tecnologias;

  • nomes de empresas;

  • datas;

  • cargos;

  • acentuação;

  • pontuação;

  • capitalização.

Escreva corretamente:

  • COBOL;

  • JCL;

  • CICS;

  • Db2;

  • z/OS;

  • VSAM;

  • GitHub;

  • Jenkins;

  • IBM Z.

Evite variações aleatórias como:

Cobol
COBOL
cobol
CÓBOL

Padronização demonstra cuidado.

Em ambientes corporativos, pequenos detalhes importam.

Uma letra errada em um dataset pode parar um job.

Uma letra errada em uma competência pode impedir que uma busca encontre seu perfil.


21. LinkedIn e currículo devem conversar

Seu currículo e seu LinkedIn não precisam ser idênticos, mas devem ser coerentes.

Se o currículo diz que você trabalhou de 2020 a 2024 em determinada empresa, e o LinkedIn informa 2021 a 2023, surge uma inconsistência.

Se o currículo apresenta experiência com COBOL e o LinkedIn não menciona mainframe em nenhum lugar, o recrutador pode ter dúvidas.

Mantenha alinhados:

  • cargos;

  • empresas;

  • períodos;

  • tecnologias;

  • certificações;

  • formação;

  • projetos principais.

O LinkedIn pode ser mais detalhado.

O currículo deve ser mais focado.

Um é o arquivo completo.

O outro é a consulta otimizada.


22. GitHub para o programador COBOL iniciante

Um GitHub organizado pode compensar parcialmente a falta de experiência formal.

Você pode criar repositórios com:

  • programas COBOL;

  • JCLs;

  • exemplos de arquivos;

  • documentação;

  • desafios;

  • diagramas;

  • exercícios de Db2;

  • exemplos de CICS;

  • scripts auxiliares;

  • projetos de bootcamp.

Cada projeto deve possuir um README explicando:

  • objetivo;

  • tecnologias;

  • estrutura;

  • como executar;

  • exemplos de entrada;

  • exemplos de saída;

  • aprendizados.

No currículo, escreva:

GitHub: github.com/seuusuario

E destaque projetos relevantes:

Projeto: Cloud Status Checker em Python
Implementação de validador de status de CPU, memória e rede, com tratamento de entradas inválidas e classificação de operação normal, alerta ou incidente.

Mesmo um projeto simples pode demonstrar:

  • lógica;

  • validação;

  • clareza;

  • tratamento de erros;

  • documentação;

  • disciplina.



23. Passo a passo para criar um currículo ATS Friendly

Passo 1 — Leia a vaga como um investigador

Não envie o currículo imediatamente.

Leia com atenção.

Marque:

  • cargo;

  • tecnologias;

  • nível de experiência;

  • responsabilidades;

  • requisitos obrigatórios;

  • requisitos desejáveis;

  • idioma;

  • localização;

  • modelo de trabalho.

Crie uma lista das palavras mais importantes.

Exemplo:

COBOL
JCL
CICS
DB2
VSAM
GIT
AGILE
PRODUÇÃO
MANUTENÇÃO

Passo 2 — Compare com sua experiência

Separe em três grupos:

Conheço e já usei
Conheço por estudo
Ainda não conheço

Seja honesto.

Para aquilo que você estudou, use expressões como:

  • conhecimento acadêmico;

  • experiência em laboratório;

  • projeto pessoal;

  • treinamento prático;

  • familiaridade;

  • noções.

Passo 3 — Ajuste o resumo profissional

Inclua o cargo desejado e as competências mais relacionadas.

Passo 4 — Reorganize a experiência

Coloque primeiro as atividades mais relevantes para a vaga.

Passo 5 — Inclua palavras-chave naturalmente

Utilize as palavras da vaga quando elas forem verdadeiras em seu perfil.

Passo 6 — Remova elementos arriscados

Elimine:

  • colunas;

  • caixas de texto;

  • gráficos;

  • estrelas;

  • ícones excessivos;

  • fotografias desnecessárias.

Passo 7 — Revise o arquivo

Copie todo o conteúdo e cole em um editor de texto simples.

Observe se a ordem permanece compreensível.

Se o texto ficar embaralhado, o ATS também pode ter dificuldade.

Passo 8 — Salve corretamente

Use o formato solicitado e um nome profissional.

Passo 9 — Compare novamente com a vaga

Pergunte:

  • COBOL aparece?

  • JCL aparece?

  • O cargo está claro?

  • Os projetos estão descritos?

  • O nível de experiência está honesto?

  • O telefone está visível?

  • O GitHub está presente?

  • As datas estão consistentes?

Passo 10 — Envie e registre

Crie uma planilha com:

  • empresa;

  • vaga;

  • data;

  • versão do currículo;

  • link;

  • status;

  • retorno;

  • próxima ação.

Isso evita enviar arquivos diferentes sem controle.

No mainframe, chamamos isso de rastreabilidade.

No mundo da carreira, chamamos de não enlouquecer.



24. Modelo de estrutura ATS Friendly

NOME COMPLETO
Cargo ou área de interesse

Cidade – Estado – País
Telefone
E-mail
LinkedIn
GitHub

RESUMO PROFISSIONAL

Texto de quatro a seis linhas apresentando experiência, conhecimentos, tecnologias e objetivo profissional.

COMPETÊNCIAS TÉCNICAS

Linguagens:
COBOL, SQL, Python.

Mainframe:
z/OS, JCL, CICS, Db2, VSAM, TSO/ISPF, SDSF.

Ferramentas:
Git, GitHub, VS Code, IBM Z Open Editor.

EXPERIÊNCIA PROFISSIONAL

Empresa
Cargo
Mês/Ano – Mês/Ano

- Atividade ou resultado.
- Tecnologia utilizada.
- Problema resolvido.
- Participação no projeto.

PROJETOS

Nome do projeto
Tecnologias

- Objetivo.
- Implementação.
- Resultado.

FORMAÇÃO ACADÊMICA

Curso
Instituição
Ano de conclusão ou previsão.

CERTIFICAÇÕES E CURSOS

Nome da certificação ou curso
Instituição
Ano.

IDIOMAS

Português — Nativo
Inglês — Intermediário

25. O currículo humano e o currículo robô

Um bom currículo precisa agradar a dois públicos.

O primeiro é a máquina.

Ela deseja:

  • estrutura;

  • palavras-chave;

  • títulos conhecidos;

  • dados claros;

  • formatação simples.

O segundo é o ser humano.

Ele deseja:

  • clareza;

  • coerência;

  • resultados;

  • contexto;

  • personalidade profissional;

  • honestidade;

  • facilidade de leitura.

O erro é otimizar apenas para um lado.

Um currículo cheio de palavras-chave, mas sem narrativa, parece artificial.

Um currículo visualmente deslumbrante, mas ilegível por sistemas, pode desaparecer no processo.

O equilíbrio é a resposta.


26. Easter eggs escondidos no recrutamento

Easter egg 1 — O currículo não consegue substituir competência

Nenhuma técnica de ATS transforma alguém em especialista.

O currículo abre a porta.

A entrevista testa o conhecimento.

O trabalho confirma a experiência.

Easter egg 2 — O ATS não é uma máquina de aprovação

Ter um currículo ATS Friendly não garante entrevista.

Ele apenas reduz a chance de ser eliminado por problemas de estrutura.

Easter egg 3 — A palavra “mainframe” pode ser ampla demais

Sempre que possível, detalhe:

  • IBM Z;

  • z/OS;

  • COBOL;

  • CICS;

  • Db2;

  • IMS;

  • JCL;

  • VSAM;

  • RACF.

Easter egg 4 — Recrutadores também fazem buscas internas

Mesmo que você não seja escolhido para uma vaga, seu currículo pode permanecer no banco de talentos.

Palavras-chave corretas ajudam a ser encontrado futuramente.

Easter egg 5 — O nome do cargo importa

Se você procura vaga de “Mainframe Developer”, não esconda isso.

Use o título no resumo, desde que seja compatível com seu objetivo.

Easter egg 6 — Certificação sem contexto vale menos

Em vez de listar vinte cursos sem explicação, priorize os mais relevantes.

Easter egg 7 — Currículo não é autobiografia

Você não precisa contar tudo.

Precisa contar o que é relevante para a oportunidade.

Easter egg 8 — O currículo é uma API

Ele recebe uma requisição:

Precisamos de um programador COBOL júnior.

E deve responder com dados claros:

{
  "cobol": true,
  "jcl": true,
  "db2": "conhecimento acadêmico",
  "cics": "em desenvolvimento",
  "git": true,
  "disponibilidade": true
}

Easter egg 9 — Patrick Jane não confiaria em estrelas

Cinco estrelas em COBOL não significam nada.

Uma descrição concreta significa.

Easter egg 10 — O verdadeiro mentalista é o candidato preparado

Você não lê mentes.

Mas aprende a ler vagas.

Essa habilidade muda tudo.


27. Curiosidades para o Padawan COBOL

A palavra “tracking” em Applicant Tracking System significa acompanhamento.

Ou seja, o sistema não serve apenas para filtrar. Ele também pode acompanhar o candidato durante as etapas:

Inscrição
Triagem
Entrevista RH
Entrevista Técnica
Teste
Proposta
Contratação

Em algumas empresas, o recrutador adiciona comentários, avaliações e histórico de contato.

Outro detalhe interessante é que diferentes ATS podem interpretar o mesmo documento de formas diferentes.

Por isso, não existe um layout mágico universal.

A melhor estratégia continua sendo:

  • estrutura simples;

  • texto real;

  • títulos claros;

  • poucas colunas;

  • palavras-chave relevantes;

  • conteúdo honesto.

Outra curiosidade: alguns recrutadores não pesquisam apenas tecnologias.

Eles procuram também responsabilidades e contextos.

Por exemplo:

production support
incident management
batch processing
application maintenance
legacy modernization
code review
unit testing

Portanto, descrever atividades pode ser tão importante quanto listar ferramentas.



28. Erros comuns de iniciantes

Erro 1 — Currículo com quatro páginas sem necessidade

Para alguém no início da carreira, uma ou duas páginas geralmente são suficientes.

Erro 2 — Objetivo genérico

Busco uma oportunidade para crescer profissionalmente.

Isso serve para quase qualquer pessoa.

Prefira:

Busco oportunidade como programador COBOL júnior, com foco em desenvolvimento e manutenção de aplicações IBM Mainframe.

Erro 3 — Listar tudo que já ouviu falar

Conhecer o nome de uma tecnologia não significa dominá-la.

Erro 4 — Não incluir projetos

Para iniciantes, projetos são fundamentais.

Erro 5 — Usar linguagem passiva demais

Foi realizado um projeto.

Melhor:

Desenvolvi um projeto.

Erro 6 — Currículo sem resultado

Sempre que possível, mostre o que foi entregue.

Erro 7 — Misturar português e inglês sem lógica

Use o idioma solicitado pela vaga.

Erro 8 — Endereço completo

Normalmente cidade, estado e país são suficientes.

Não é necessário informar número da casa.

Erro 9 — Dados pessoais excessivos

Evite informações que não ajudam no processo.

Erro 10 — Mentir

Esse é o maior erro.

Em tecnologia, a verdade aparece rapidamente.


29. Como descrever conhecimentos ainda básicos

Você pode ser iniciante e ainda assim apresentar seu conhecimento de forma profissional.

Exemplos:

COBOL — conhecimento prático em programas batch, estruturas condicionais, arquivos sequenciais e relatórios.
JCL — criação de jobs para compilação, linkedição, execução e manipulação básica de datasets.
Db2 — conhecimentos em SQL, consultas, atualização de dados e tratamento de SQLCODE em COBOL.
CICS — familiaridade com conceitos de transação, COMMAREA, mapas BMS e comandos básicos.
Git — versionamento de código, commits, branches e uso de repositórios GitHub.

Essas descrições são claras e honestas.


30. A investigação final de Patrick Jane

Imagine Patrick Jane entrando na sala.

Sobre a mesa existem dois currículos.

O primeiro possui cores, gráficos, estrelas, três colunas e uma fotografia enorme.

O segundo possui texto simples, seções claras, palavras-chave relevantes e projetos objetivos.

Ele observa os dois.

Toma uma xícara de chá — infelizmente, ainda não descobriu o poder do café Bellacosa — e diz:

— O primeiro deseja ser admirado. O segundo deseja ser compreendido.

Essa é a essência de um currículo ATS Friendly.

Ser compreendido.

Pelo sistema.

Pelo recrutador.

Pelo gerente.

Pelo entrevistador técnico.

Você não precisa eliminar sua personalidade.

Você precisa organizar sua mensagem.

  • Conheça o Lovable

https://eljefemidnightlunch.blogspot.com/2024/11/lovable-o-dia-em-que-patrick-jane.html

Conclusão — O job precisa entrar em execução

Um currículo ATS Friendly é um currículo preparado para atravessar a primeira camada do processo seletivo.

Ele utiliza:

  • layout simples;

  • texto legível;

  • títulos tradicionais;

  • palavras-chave;

  • datas consistentes;

  • informações claras;

  • descrições objetivas;

  • projetos relevantes;

  • formatação compatível.

Para um programador COBOL iniciante, essa preparação é especialmente importante.

Você talvez ainda não tenha dez anos de experiência.

Mas pode demonstrar:

  • disciplina;

  • capacidade de aprender;

  • domínio da lógica;

  • projetos práticos;

  • conhecimento do ambiente IBM Z;

  • interesse em sistemas corporativos;

  • organização;

  • documentação;

  • vontade de evoluir.

O currículo não deve fingir que você é um sênior.

Ele deve provar que você está pronto para dar o próximo passo.

No Bellacosa Mainframe, aprendemos que nenhum job chega à produção sem passar por validação, teste, revisão e controle.

Sua carreira também precisa desse cuidado.

Leia a vaga.

Identifique as palavras-chave.

Ajuste seu currículo.

Revise a estrutura.

Elimine ruídos.

Destaque projetos.

Salve corretamente.

Envie com consciência.

E lembre-se:

O ATS não precisa gostar de você.

Ele precisa entender você.

O recrutador não precisa decifrar um enigma.

Ele precisa encontrar rapidamente aquilo que procura.

E você, jovem Padawan do COBOL, não precisa ler mentes como Patrick Jane.

Precisa apenas aprender a ler pistas.

Porque, no grande datacenter da carreira profissional, a oportunidade pode já estar no spool.

Só falta o seu currículo passar com:

MAXCC = 0000
CANDIDATO SELECIONADO PARA A PRÓXIMA ETAPA

☕ Que o café esteja quente, o currículo esteja legível e o job da sua carreira execute sem ABEND.

sexta-feira, 31 de julho de 2026

👋 Boas-vindas ao IBM Bob Bootcamp

 

Bellacosa Mainframe apresenta o bootcamp DIO da IBM e seu agente BOB

👋 Boas-vindas ao IBM Bob Bootcamp

IA de Nível Empresarial para Desenvolvedores e Tech Leaders

Olá, pessoal!

Meu nome é Vagner Bellacosa, sou Analista de Sistemas IBM Mainframe, IBM Champion e, acima de tudo, um apaixonado por tecnologia, compartilhamento de conhecimento e aquele tradicional café que acompanha toda boa sessão de aprendizado.

É um enorme prazer fazer parte desta turma do IBM Bob Bootcamp.

Vivemos um momento raro na história da computação. Durante décadas ouvimos que a Inteligência Artificial era "o futuro". Pois bem... o futuro resolveu aparecer mais cedo do que imaginávamos, bater na porta e perguntar:

"Posso ajudar no seu código?"

A resposta, obviamente, foi:

"Pode... mas primeiro passa pelo Code Review!" 😄



Afinal... o que estamos fazendo aqui?

Estamos reunidos porque entendemos que IA não é moda.

É ferramenta.

É produtividade.

É aceleração.

É uma nova forma de pensar soluções.

Se você desenvolve software, administra ambientes, lidera equipes ou trabalha com arquitetura, provavelmente percebeu que a pergunta deixou de ser:

"Vou usar IA?"

e passou a ser

"Como posso utilizá-la melhor que os outros?"


Um recado para quem vem do Mainframe

Eu sou suspeito para falar...

Venho do universo IBM Z, COBOL, CICS, Db2 e z/OS.

Aquele ambiente que muitos juram que é "velho"...

...até descobrirem que movimenta boa parte do dinheiro do planeta.

Então, quando alguém pergunta:

"Mainframe combina com Inteligência Artificial?"

Minha resposta é sempre:

Combina tanto quanto café combina com madrugada de implantação.

Ou seja...

É praticamente obrigatório. ☕😂

Hoje a IA conversa com APIs REST, z/OS Connect, Watsonx, OpenShift, GitHub Copilot, Assistentes Inteligentes e, cada vez mais, com aplicações corporativas que executam justamente em IBM Z.


Minha expectativa

Espero aprender muito com todos vocês.

Cada participante chega com experiências diferentes.

Uns dominam Cloud.

Outros conhecem Kubernetes.

Alguns vivem em Java, Python ou JavaScript.

Outros, como eu, passaram anos escrevendo COBOL e fazendo milhões de transações passarem silenciosamente por um Data Center.

No fim das contas...

Todos estamos aprendendo a conversar com uma nova ferramenta.

E isso é fantástico.


Minha filosofia

Sempre gostei de uma frase simples:

Quem compartilha conhecimento nunca perde espaço; cria novos lugares para todos crescerem.

Então contem comigo durante o Bootcamp.

Se eu puder ajudar em alguma dúvida, trocar experiências ou simplesmente conversar sobre tecnologia, será um prazer.



Um pequeno aviso (com humor Bellacosa)

Caso durante o Bootcamp você apresente algum dos sintomas abaixo...

  • conversar com IA como se fosse um colega de equipe;

  • pedir para o Copilot escrever aquele método "rapidinho";

  • descobrir que um prompt bem escrito vale mais que cinquenta pesquisas;

  • começar a enxergar automação em absolutamente tudo;

...não se preocupe.

É perfeitamente normal.

Os efeitos costumam ser irreversíveis. 😄



https://web.dio.me/track/ibm-bob-ia-nivel-empresarial-para-desenvolvedores?

Boa sorte a todos!

Que este Bootcamp seja uma excelente oportunidade para aprender, compartilhar experiências, fazer novas amizades e descobrir como utilizar a Inteligência Artificial de forma prática e responsável.

Como diria o Bellacosa Mainframe:

"Prepare o café, abra a mente e mantenha o Git atualizado. Porque a IA pode até sugerir o código... mas a responsabilidade pelo commit continua sendo nossa!"

Nos vemos durante o Bootcamp!

☕🤖🚀

segunda-feira, 27 de julho de 2026

AWS vs Mainframe: O Grande Dicionário Bilíngue da Computação Corporativa

 

Bellacosa Mainframe compara o aws com o mainframe

☕ Um Café no Bellacosa Mainframe

AWS vs Mainframe: O Grande Dicionário Bilíngue da Computação Corporativa

Quando um Programador COBOL Descobre que a Nuvem Não Inventou Tudo... Apenas Deu Novos Nomes às Velhas Ideias

Existe uma frase muito conhecida entre os profissionais de tecnologia:

"Toda tecnologia nova parece revolucionária... até você descobrir que o mainframe já fazia algo parecido há décadas."

Naturalmente, essa frase é um exagero. A computação em nuvem trouxe inúmeras inovações reais: elasticidade praticamente infinita, cobrança sob demanda, infraestrutura global distribuída, APIs padronizadas e uma velocidade de provisionamento que seria impensável nos anos 1970.

Por outro lado...

Quem trabalhou muitos anos em IBM Z percebe rapidamente algo curioso.

Boa parte dos conceitos fundamentais da Cloud Computing já existiam, apenas recebiam outros nomes.

É justamente isso que o infográfico procura mostrar.

Não se trata de afirmar que AWS = Mainframe.

Muito menos que um substitui o outro.

A proposta é muito mais inteligente:

Traduzir conceitos.

Da mesma forma que um brasileiro aprende inglês associando "house" com "casa", um programador COBOL aprende AWS muito mais rapidamente quando pensa:

"EC2... isso lembra uma LPAR."

É exatamente essa mudança mental que acelera o aprendizado.

Vamos aprofundar essa comparação.


Antes de tudo...

Existe um erro extremamente comum.

Muitos profissionais perguntam:

"Qual é o equivalente do AWS Lambda no Mainframe?"

Na verdade essa pergunta está errada.

O correto seria perguntar:

"Qual tecnologia do Mainframe resolve um problema semelhante?"

Porque tecnologias diferentes podem resolver o mesmo problema de maneiras completamente distintas.

É exatamente isso que veremos.


EC2 × LPAR

AWS

EC2 fornece máquinas virtuais sob demanda.

Você cria.

Liga.

Desliga.

Apaga.

Escala.

Tudo em minutos.


Mainframe

A comparação natural é a LPAR (Logical Partition).

Mas aqui existe uma enorme diferença filosófica.

Uma instância EC2 normalmente é um servidor virtual.

Uma LPAR é praticamente um computador completo.

Dentro dela existe:

  • z/OS

  • JES

  • RACF

  • CICS

  • Db2

  • MQ

  • milhares de usuários

Ou seja...

Uma única LPAR frequentemente faz o trabalho de centenas de servidores Linux.

Por isso muitos profissionais dizem:

"Comparar uma EC2 com uma LPAR é como comparar um apartamento com um condomínio inteiro."


Curiosidade

O conceito de particionamento lógico apareceu comercialmente décadas antes da virtualização popularizada pelo VMware.

A IBM fazia isso quando a maioria dos servidores ainda era física.


S3 × VSAM / DASD

Esta comparação merece cuidado.

S3 não é um disco.

É um armazenamento de objetos.

VSAM não é armazenamento de objetos.

É um método de acesso.

Então por que a comparação?

Porque ambos representam onde os dados vivem.


S3

Armazena objetos.

  • fotos

  • backups

  • vídeos

  • PDFs

  • logs

Escala praticamente infinita.


Mainframe

No IBM Z os dados normalmente ficam em:

  • DASD

  • VSAM

  • Sequential datasets

  • GDGs

  • PDS/PDSE

O conceito é diferente.

Enquanto S3 trabalha com objetos identificados por chaves, o mainframe trabalha com datasets catalogados e métodos de acesso especializados.

Um VSAM KSDS, por exemplo, comporta-se muito mais como um banco de dados indexado do que como um bucket S3.


Melhor analogia

Talvez fosse mais correto dizer:

S3 ≈ Conjunto de datasets altamente duráveis.

Não existe equivalente perfeito.


RDS × Db2 for z/OS

Aqui a aproximação é muito boa.

AWS oferece banco relacional gerenciado.

Db2 oferece banco relacional corporativo.

Mas termina aí.


O que muda?

No AWS:

Você administra menos infraestrutura.

No Mainframe:

Você administra muito mais parâmetros.

Em compensação...

Obtém níveis absurdos de disponibilidade.

Db2 z/OS foi construído para:

  • bancos

  • cartões

  • bolsas

  • governos

  • seguradoras

Milhões de transações por segundo.

Décadas de evolução.

Consistência extrema.


Easter Egg

Quando alguém diz:

"Meu banco usa RDS."

O programador de mainframe responde:

"Interessante... o meu banco inteiro usa Db2."


Lambda × CICS

Essa comparação é conceitual.

Lambda executa código quando um evento ocorre.

CICS executa transações quando uma requisição chega.

Ambos respondem a eventos.

Mas de maneiras completamente diferentes.


Lambda

Sem servidor visível.

Escala automaticamente.

Cada chamada inicia uma execução.


CICS

Servidor transacional residente.

As tarefas reutilizam recursos.

Baixíssima latência.

Controle rigoroso.

Extrema confiabilidade.


Uma transação CICS pode durar poucos milissegundos.

E atender milhares de usuários simultaneamente.

Há bancos onde o cliente insere a senha no caixa eletrônico...

E em menos de um décimo de segundo:

  • RACF valida

  • CICS executa

  • Db2 consulta

  • MQ envia mensagens

  • resposta retorna

Tudo isso antes do usuário piscar.


API Gateway × CICS Web Services

Nos últimos anos o CICS tornou-se um verdadeiro servidor de APIs.

Hoje é possível expor programas COBOL como:

  • REST

  • SOAP

  • JSON

Sem reescrever décadas de código.

A ideia é semelhante ao API Gateway:

publicar serviços de forma segura.

A diferença é que no CICS o backend muitas vezes continua sendo um programa escrito em 1989.

E funcionando perfeitamente.


CloudWatch × RMF / SMF

Talvez uma das melhores comparações.

CloudWatch monitora.

RMF mede.

SMF registra praticamente tudo.


No mainframe existem registros para:

CPU.

I/O.

Memória.

Logons.

Jobs.

CICS.

Db2.

MQ.

Segurança.

Tudo vira SMF.

Depois essas informações alimentam:

  • relatórios

  • capacity planning

  • billing interno

  • auditoria

  • performance

É praticamente uma caixa-preta de avião.


VPC × VTAM / TCP-IP

VPC cria uma rede privada lógica.

No mainframe temos:

  • TCP/IP

  • Enterprise Extender

  • SNA

  • VTAM (historicamente)

São tecnologias diferentes.

Mas ambas organizam comunicações seguras entre aplicações.

Hoje, o TCP/IP é predominante no z/OS, enquanto o VTAM permanece como parte importante da arquitetura SNA e do gerenciamento de sessões legadas.


IAM × RACF

Esta talvez seja a comparação mais intuitiva.

IAM controla identidades.

RACF controla identidades.

Mas RACF faz isso desde os anos 1970.


No RACF encontramos:

  • usuários

  • grupos

  • perfis

  • datasets

  • transações

  • comandos

  • permissões

Tudo centralizado.

Em ambientes corporativos enormes, RACF continua sendo um dos sistemas de segurança mais robustos do mercado.


CloudFront

Aqui o infográfico coloca:

Sem equivalente.

Concordo parcialmente.

CloudFront é uma CDN.

Mainframe nunca precisou distribuir imagens para milhões de navegadores.

Mas existe um conceito parecido.

CICS, z/OS Connect e balanceadores corporativos podem distribuir carga entre regiões, embora isso não seja uma CDN. Portanto, realmente não há um equivalente direto.


DynamoDB

Também não existe equivalente perfeito.

O mainframe tradicional trabalha principalmente com:

  • Db2

  • IMS DB

  • VSAM

Entretanto...

IMS Hierarchical Database possui algumas características que lembram bancos NoSQL modernos.

Não são iguais.

Mas resolvem certos problemas semelhantes.


SQS × IBM MQ

Esta comparação é excelente.

Ambos trabalham com filas.

Mensagens.

Processamento assíncrono.

Desacoplamento.

A principal diferença está no foco.

IBM MQ nasceu para ambientes corporativos críticos.

SQS nasceu para aplicações distribuídas na nuvem.

Ambos resolvem brilhantemente problemas de integração, mas IBM MQ oferece recursos avançados de transação, persistência e integração com sistemas legados que o tornam um pilar do processamento empresarial.


SNS × WTO / Console Messages

Aqui talvez seja a comparação mais discutível.

SNS distribui notificações para diversos assinantes.

Já WTO (Write To Operator) envia mensagens ao console do operador do z/OS.

Embora ambos "notifiquem", cumprem papéis muito diferentes.

Uma analogia funcional mais próxima seria:

  • SNS ↔ combinação de IBM MQ + Event Notification + automação (como IBM Z System Automation ou NetView), dependendo do cenário.

WTO é muito mais voltado para operação do sistema do que para publicação de eventos para consumidores.


O que ficou faltando?

O universo AWS é enorme. Diversos serviços modernos também encontram paralelos conceituais no ecossistema IBM Z:

AWSMainframe
EBSVolumes DASD
EFSzFS / HFS
Elastic Load BalancerSysplex Distributor
Auto ScalingWLM + Capacity on Demand
Secrets ManagerRACF Key Rings + ICSF
KMSICSF + Hardware Crypto Express
CloudTrailSMF + RACF Auditing
Systems Managerz/OSMF
ECS/EKSzCX (z/OS Container Extensions)
EventBridgeIBM MQ + CICS START + automação
Step FunctionsJCL + Scheduler (TWS/IWS, CA 7, Control-M)
GlueDFSORT, SyncSort, DataStage e ferramentas ETL
AthenaDb2 Analytics, SQL Federation e consultas distribuídas
RedshiftDb2 Analytics Accelerator (IDAA)
CognitoRACF + provedores de identidade (LDAP, SAF, z/OS Connect)

A Filosofia por Trás da Comparação

A maior lição do infográfico não é decorar equivalências.

É perceber que os problemas fundamentais da computação permanecem os mesmos:

  • executar aplicações;

  • armazenar dados;

  • proteger acessos;

  • integrar sistemas;

  • monitorar ambientes;

  • processar eventos;

  • escalar capacidade.

O que muda é a forma como cada arquitetura resolve esses desafios.

O IBM Z foi concebido para oferecer estabilidade, consistência transacional e disponibilidade extrema em um ambiente centralizado. A AWS foi projetada para privilegiar elasticidade, automação, distribuição geográfica e provisionamento sob demanda em uma infraestrutura de nuvem.

Essas filosofias não são concorrentes em todos os casos — são frequentemente complementares. Hoje, é comum encontrar bancos, seguradoras e governos executando seus sistemas críticos em IBM Z enquanto utilizam AWS para APIs, analytics, inteligência artificial, aplicações móveis e serviços digitais.


Conclusão: O Melhor Profissional Fala Dois "Idiomas"

No início da carreira, muitos especialistas em mainframe enxergavam a nuvem como uma ameaça. Da mesma forma, muitos profissionais de cloud acreditavam que o mainframe era apenas uma tecnologia ultrapassada.

Com o tempo, o mercado mostrou uma realidade bem diferente.

Os ambientes corporativos mais sofisticados são híbridos.

O cartão de crédito pode ser autorizado por um programa COBOL executando em CICS e Db2 no IBM Z, enquanto o aplicativo móvel utiliza APIs hospedadas na AWS, com autenticação moderna, monitoramento em nuvem e microsserviços.

Em vez de escolher entre "mainframe ou cloud", as organizações escolhem mainframe e cloud.

Para o profissional de tecnologia, isso significa uma oportunidade extraordinária: dominar os dois mundos. Quem entende como traduzir conceitos entre AWS e IBM Z consegue atuar como uma ponte entre equipes, acelerar projetos de modernização e preservar décadas de conhecimento corporativo enquanto incorpora as práticas mais recentes da computação em nuvem.

No fim das contas, aprender AWS não exige esquecer o mainframe. Pelo contrário: para quem já conhece IBM Z, muitas ideias da nuvem deixam de parecer completamente novas e passam a ser apenas uma nova linguagem para resolver problemas que a computação empresarial enfrenta — e resolve — há mais de meio século.

domingo, 26 de julho de 2026

Lógica de Validação : Quando um Programador COBOL Descobre que o Campo Obrigatório Não Foi Criado para Irritar Usuários... Mas para Evitar que um Banco Inteiro Exploda às 23h59

 

Bellacosa Mainframe e a logica de validação

☕ Um Café no Bellacosa Mainframe

Lógica de Validação sem Mistérios para Programadores COBOL

Quando um Programador COBOL Descobre que o Campo Obrigatório Não Foi Criado para Irritar Usuários... Mas para Evitar que um Banco Inteiro Exploda às 23h59

"Meu nome é COBOL. Enterprise COBOL."

Imagine a cena clássica de um filme de James Bond.

Em algum lugar de Londres, M entrega uma missão.

— Bond, encontramos um programa escrito em RPG III em 1989. Um desenvolvedor júnior pretende remover algumas validações porque "atrapalham a experiência do usuário". Se ele conseguir... centenas de sistemas financeiros poderão produzir dados incorretos durante meses sem que ninguém perceba.

Bond responde calmamente.

— Então o problema não é o código.

— Exatamente. O problema é que ninguém sabe por que aquele código existe.

...

Bem-vindo ao mundo dos sistemas corporativos.

E curiosamente...

Essa história acontece praticamente todos os dias: validações aparentemente simples escondem regras de negócio extremamente sofisticadas.

Para um programador COBOL iniciante, isso representa uma das maiores mudanças de mentalidade da carreira.


O grande erro dos iniciantes

Todo iniciante pensa parecido.

Ele abre um programa COBOL.

Encontra:

IF CLIENTE = SPACES
    DISPLAY "CLIENTE OBRIGATORIO"
    GO TO TELA
END-IF

Primeira reação:

"Isso é simples."

Segunda reação:

"Posso melhorar."

Terceira reação:

"Nem precisa existir."

...

E é exatamente aí que começam os problemas.

Porque talvez esse IF esteja protegendo:

  • faturamento

  • integração

  • impostos

  • compliance

  • auditoria

  • relatórios

  • processamento batch

  • fechamento mensal

Ou seja...

o verdadeiro trabalho nunca foi impedir campo vazio.

O verdadeiro trabalho era proteger todo o restante do sistema.


O efeito James Bond

Nos filmes do 007 existe um detalhe interessante.

Quase nunca o vilão destrói Londres usando uma bomba gigante.

Ele altera uma pequena peça.

Troca um satélite.

Muda um código.

Rouba uma chave.

Troca uma senha.

Depois observa o caos acontecer sozinho.

Nos sistemas corporativos acontece exatamente igual.

Você altera uma validação aparentemente insignificante.

Nada acontece.

Durante dias.

Durante semanas.

Depois...

o fechamento financeiro falha.


O usuário vê uma mensagem.

O sistema vê um contrato.

O artigo explica algo extremamente importante.

Para o usuário existe apenas isto:

Campo obrigatório.

Fim.

Mas internamente aquela mensagem significa:

"Não permita que este registro siga adiante porque cinquenta processos dependem dele."

Essa diferença de perspectiva muda completamente a forma como analisamos software legado.


O iceberg das validações

A tela é apenas a ponta.

Debaixo dela existem dezenas de dependências.

Imagine:

Tela

↓

Programa COBOL

↓

VSAM

↓

DB2

↓

MQ

↓

Interface REST

↓

Batch Noturno

↓

Relatórios

↓

BI

↓

Auditoria

↓

Banco Central

O usuário enxerga:

Campo obrigatório.

O arquiteto enxerga:

Uma cadeia inteira de dependências.

Por que sistemas antigos fazem tantas validações?

Porque durante décadas não existiam:

  • APIs

  • Microservices

  • Gateway

  • Event Broker

  • Kafka

  • Camadas REST

Tudo acontecia dentro do programa.

Logo...

a validação morava exatamente onde os dados entravam.

Na tela.

Esse padrão tornou-se extremamente comum em RPG, COBOL, Natural e PL/I.


O verdadeiro inimigo chama-se "dados ruins"

Programadores novos costumam pensar:

"Erro de compilação é ruim."

Não.

Muito pior é dado errado.

Porque código errado normalmente explode imediatamente.

Dado errado...

pode sobreviver anos.


Imagine:

Cliente cadastrado sem CPF.

Hoje nada acontece.

Amanhã:

batch ignora.

Depois:

faturamento não encontra cliente.

Depois:

impostos errados.

Depois:

auditoria encontra inconsistência.

Depois:

advogados entram.

Tudo começou porque alguém retirou um IF.


O paradoxo da modernização

Outro ponto excelente discutido no artigo.

Modernizar NÃO significa preservar tudo.

Nem apagar tudo.

Modernizar significa entender primeiro.

Depois decidir.

A sequência correta é:

  1. Descobrir a regra.

  2. Entender a regra.

  3. Descobrir quem usa.

  4. Descobrir quem depende.

  5. Só então alterar.

Jamais o contrário.


Um dos maiores perigos: o efeito dominó

Imagine uma peça de dominó.

Você derruba apenas uma.

As outras caem sozinhas.

Validações funcionam exatamente assim.

Uma alteração pequena pode atingir:

  • relatórios

  • integração SAP

  • emissão fiscal

  • XML

  • APIs

  • Data Warehouse

  • Analytics

Nenhuma dessas equipes estava olhando aquela tela.

Mas todas dependiam dela.


James Bond e o Mainframe

Se James Bond trabalhasse num banco...

Q provavelmente lhe entregaria um gadget chamado:

Validator Scanner 9000

Funções:

✓ localizar IF esquecidos

✓ encontrar PERFORM misteriosos

✓ rastrear GO TO perigosos

✓ identificar programas batch impactados

Infelizmente...

na vida real esse gadget chama-se:

Conhecimento.

A IA entra em cena

O artigo mostra um uso extremamente inteligente da IA.

Não para substituir o desenvolvedor.

Mas para acelerar investigação.

Por exemplo.

A IA pode responder rapidamente:

  • Qual campo é validado?

  • Qual mensagem aparece?

  • Qual arquivo recebe update?

  • Qual status muda?

  • Quais programas são chamados?

  • Quais SQL executam?

  • Quais interfaces dependem?

Ela reduz dias de investigação para minutos em muitos casos.


Mas cuidado...

A IA enxerga código.

Ela não enxerga história.

Ela pode dizer:

"Campo obrigatório."

Mas não sabe que:

Em 1997 um cliente perdeu milhões porque esse campo ficou vazio.

Quem sabe isso?

O analista veterano.


O método Bellacosa de investigação

Sempre ensine seu cérebro a pensar nesta sequência:

Etapa 1

Onde está a validação?


Etapa 2

Quem chama?


Etapa 3

Quem grava?


Etapa 4

Quem lê?


Etapa 5

Quem depende?


Etapa 6

O que quebra?


Etapa 7

Ainda faz sentido?


Só depois:

Modificar.


A importância da documentação

Outro excelente ponto.

Quando finalmente descobrimos o motivo daquela validação...

não podemos guardar isso apenas na cabeça.

Transforme em:

  • Wiki

  • Confluence

  • Markdown

  • Obsidian

  • Teste

  • Caso de Uso

Conhecimento que permanece apenas em pessoas desaparece quando elas mudam de projeto ou se aposentam.


O prompt apresentado

O artigo também fornece um excelente modelo para IA.

Ele pede análise sobre:

  • campo

  • condição

  • mensagem

  • regra

  • arquivos

  • programas

  • SQL

  • interfaces

  • batch

  • riscos

  • QA

  • suporte

  • testes

Na prática é quase um checklist de engenharia reversa moderna.


Os cinco agentes secretos da modernização

Desenvolvedor

Descobre como funciona.


Analista

Descobre por quê.


QA

Prova que continua funcionando.


Suporte

Conta todas as tragédias já ocorridas.


Arquiteto

Decide onde essa regra deverá viver daqui para frente.

Cada um possui uma parte da missão.


Curiosidade histórica

Nos anos 1970 e 1980 era comum concentrar praticamente toda a inteligência do negócio dentro do programa COBOL ou RPG.

Não porque fosse "bonito".

Mas porque era o local natural onde os dados entravam.

Décadas depois, APIs, microsserviços e arquiteturas em camadas redistribuíram muitas dessas responsabilidades, mas inúmeras regras continuam preservadas no legado por razões históricas e operacionais.


Easter Egg 007

Existe um paralelo curioso.

Nos filmes do James Bond, M frequentemente diz:

"Confie em seus instintos."

No mainframe existe uma versão melhor:

"Nunca remova um IF antes de descobrir quem escreveu aquele IF."

Porque talvez quem escreveu já tenha resolvido um desastre que nunca foi documentado.


Licença para Refatorar

Bond tinha licença para matar.

O programador moderno deveria possuir outra licença:

Licença para perguntar.

Antes de remover qualquer validação:

  • Quem pediu?

  • Quando surgiu?

  • Qual incidente originou?

  • Existe documento?

  • Existe chamado?

  • Existe histórico?

  • Existe auditoria?

Se ninguém souber responder...

o IF merece respeito.


Conclusão — O verdadeiro agente secreto é a regra de negócio

Todo iniciante imagina que programas COBOL são grandes coleções de IFs antigos, mensagens em maiúsculas e GO TO espalhados pelo código.

Com o tempo, porém, descobre uma verdade muito mais fascinante: cada validação é um pequeno agente secreto infiltrado no sistema. Ela trabalha silenciosamente, impedindo que dados inconsistentes atravessem fronteiras invisíveis e provoquem efeitos em cadeia em faturamento, relatórios, integrações, processamento batch e auditorias.

Modernizar não é eliminar essas sentinelas indiscriminadamente. É investigar sua missão, entender o contexto histórico, confirmar se ainda fazem sentido e decidir o melhor lugar para que continuem protegendo o negócio. A inteligência artificial pode acelerar essa investigação, resumir código e sugerir perguntas relevantes, mas ela ainda depende da experiência humana para interpretar o significado de cada regra e validar seu impacto no mundo real.

No universo Bellacosa Mainframe, a maior lição é simples: um IF aparentemente banal pode valer mais do que milhares de linhas de código moderno, porque ele representa conhecimento acumulado ao longo de décadas. Assim como James Bond salva o mundo antes que a maioria perceba que havia perigo, uma boa validação impede desastres que nunca aparecerão nos relatórios de incidentes justamente porque jamais chegaram a acontecer.

Da próxima vez que encontrar um antigo IF CAMPO = SPACES, não pense apenas em removê-lo. Pense que talvez ele seja o 007 do seu sistema: discreto, elegante, quase invisível... e responsável por impedir que uma catástrofe silenciosa aconteça todos os dias.

Os Três Bugs Invisíveis do Padawan COBOL : Como vencer a hesitação, a ingenuidade e o excesso de confiança

Bellacosa Mainframe e os 3 bugs invisiveis do padawan cobol



☕ Um Café no Bellacosa Mainframe

Os Três Bugs Invisíveis do Padawan COBOL

Como vencer a hesitação, a ingenuidade e o excesso de confiança antes que eles provoquem o primeiro ABEND da sua carreira

"O primeiro programa raramente derruba o banco. O primeiro erro de julgamento, sim."


Introdução

Existe um momento curioso na carreira de praticamente todo programador COBOL.

Não importa se ele estudou durante seis meses, um ano ou cinco anos.

Não importa se tirou certificações IBM.

Não importa se domina PROCEDURE DIVISION, PERFORM VARYING, OCCURS DEPENDING ON, SQL EMBEDDED, CICS ou VSAM.

O verdadeiro teste começa no primeiro dia em produção.

É ali que nasce o verdadeiro programador.

Durante décadas observando profissionais entrando em grandes bancos, seguradoras, empresas aéreas, órgãos públicos e processadoras de cartões, percebi um padrão curioso.

Os novatos quase nunca fracassam por falta de conhecimento técnico.

Eles tropeçam em três inimigos invisíveis.

São eles:

  • Hesitação

  • Ingenuidade

  • Excesso de confiança

Esses três defeitos aparecem em praticamente toda profissão crítica.

Na aviação.

Na medicina.

Na engenharia.

Na investigação criminal.

E, principalmente, em ambientes IBM Mainframe.

O curioso é que eles aparecem em momentos diferentes da evolução profissional.

E quase sempre na mesma ordem.

Hoje vamos investigar cada um deles como se estivéssemos em um episódio de CSI.

Porque um sistema crítico deixa rastros.

E a mente do programador também.


Cena do Crime 1

A Hesitação

Imagine a seguinte situação.

Você acabou de entrar na empresa.

Seu líder diz:

"Precisamos alterar o programa FINA340."

Você abre o programa.

28.000 linhas.

Escrito em 1989.

Última alteração:
há quatro dias.

Autores:

  • João

  • Carlos

  • Equipe Y2K

  • Projeto PIX

  • Open Banking

  • Adequação LGPD

Você olha aquilo.

O cursor pisca.

Cinco minutos.

Dez minutos.

Quinze minutos.

Você simplesmente não consegue tocar em nada.

Isso é completamente normal.


O cérebro entra em modo de sobrevivência

Nosso cérebro odeia destruir algo que parece importante.

Quanto maior a responsabilidade...

Maior a hesitação.

É um mecanismo biológico.

O problema é que hesitação excessiva paralisa.

E um programador parado não aprende.


O primeiro segredo

Veteranos não têm menos medo.

Eles apenas sabem investigar antes.

Essa é uma diferença gigantesca.

O novato pensa:

"Vou alterar."

O veterano pensa:

"Vou entender."


O método Bellacosa

Nunca altere antes de responder:

O que este programa faz?

Quem chama este programa?

Quem ele chama?

Quais arquivos atualiza?

Quais tabelas Db2 altera?

Existe rollback?

Existe commit?

Existe checkpoint?

Existe controle de versão?

Existe scheduler?

Existe impacto batch?

Existe impacto online?

Existe interface MQ?

Existe interface CICS?

Existe API?

Quando todas essas respostas aparecem...

A hesitação desaparece.

Porque ela foi substituída por conhecimento.


Easter Egg

Sherlock Holmes dizia:

"É um erro teorizar antes de possuir os fatos."

Todo programador COBOL deveria colocar essa frase no monitor.


Cena do Crime 2

A Ingenuidade

Depois do primeiro mês...

A hesitação diminui.

Agora nasce outro inimigo.

O iniciante acredita em tudo.

Documentação.

Comentários.

Fluxogramas.

Diagramas.

PowerPoint.

Wiki.

Chamados.

Manuais.


A maior mentira do Mainframe

Imagine encontrar isso:

* Atualiza somente clientes ativos

Bonito.

Organizado.

Profissional.

Mas você olha o código...

MOVE "S" TO WS-ATIVO

Nada mais.

Nenhuma validação.

Nenhuma regra.

Nenhum IF.

O comentário está errado há quinze anos.

Quem escreveu?

Provavelmente alguém que saiu da empresa em 2004.


A documentação envelhece

Código muda.

Documentação nem sempre.

O sistema continua funcionando.

Mas o documento virou arqueologia.

É como encontrar um mapa romano tentando dirigir em São Paulo.


A regra de ouro

Nunca confie totalmente em:

Comentários

Diagramas

Documentação

Fluxogramas

Apresentações

Emails antigos

Confie no comportamento do sistema.

Ele não mente.


Curiosidade

Muitos bancos possuem documentação cuja última atualização ocorreu antes do PIX existir.

O sistema evoluiu.

O documento não.


Cena do Crime 3

O Excesso de Confiança

Esse é o mais perigoso.

Porque normalmente aparece depois dos primeiros sucessos.

Você já resolveu alguns chamados.

Corrigiu ABEND.

Alterou tela CICS.

Fez alguns programas.

Agora pensa:

"Estou dominando."

É aí que mora o perigo.


O efeito Dunning-Kruger no Mainframe

Existe um fenômeno psicológico famoso.

Quanto menos sabemos...

Mais acreditamos saber.

Depois de alguns anos...

Percebemos o tamanho do universo.

É curioso.

O profissional de cinco meses costuma parecer mais confiante que o de vinte anos.

Porque ainda não descobriu tudo o que desconhece.


O veterano faz mais perguntas

O iniciante responde rápido.

O veterano pergunta mais.

Isso parece contraditório.

Mas faz sentido.

O veterano conhece centenas de armadilhas.

Ele sabe que sistemas críticos escondem surpresas.


Exemplo clássico

Você altera:

IF SALDO > 0

Parece simples.

Mas esquece que existe outro programa batch.

Outro online.

Outro scheduler.

Outro MQ.

Outro API Gateway.

Outro processo noturno.

Outro job semanal.

Outro fechamento mensal.

Outro processamento anual.

Seu IF alterou uma cadeia inteira.


O código nunca vive sozinho

Essa talvez seja a maior descoberta da carreira.

Programas COBOL não são ilhas.

São organismos.

Cada programa conversa com dezenas de outros.

Às vezes centenas.

Você altera uma linha.

Pode movimentar uma cidade inteira.


CSI Mainframe

Imagine Gil Grissom entrando no CPD.

Ele nunca começaria perguntando:

"Quem é o culpado?"

Ele perguntaria:

"O que aconteceu primeiro?"

Depois:

"O que mudou?"

Depois:

"Quem foi impactado?"

É exatamente assim que um analista experiente investiga incidentes.


Indiana Jones no Data Center

O código legado lembra uma cidade perdida.

Você entra com uma tocha.

Cada COPYBOOK é uma sala.

Cada PERFORM é um corredor.

Cada CALL é uma porta secreta.

Cada JCL é um mapa.

Cada PROC é um túnel subterrâneo.

E cada alteração pode ativar uma armadilha escondida.

O aventureiro imprudente corre.

O arqueólogo observa.


A Regra dos Cinco "Por Quês"

Sempre pergunte:

Por que isso existe?

Por que foi escrito assim?

Por que não removeram?

Por que ainda funciona?

Por que ninguém mexe nisso?

A quinta resposta normalmente revela uma decisão de negócio esquecida.


O Erro Mais Caro

Não é apagar um arquivo.

Nem provocar um ABEND.

Nem esquecer um END-IF.

O erro mais caro é assumir.

Assumir que entendeu.

Assumir que ninguém usa.

Assumir que é simples.

Assumir que o comentário está correto.

Assumir que aquele campo nunca recebe zeros.

Mainframe odeia suposições.


O Poder da Humildade Técnica

Existe uma frase muito comum entre grandes especialistas IBM.

"Não sei. Vamos verificar."

Observe.

Eles não respondem imediatamente.

Eles investigam.

Essa postura não demonstra fraqueza.

Demonstra maturidade.


O Ritual Bellacosa Antes de Alterar Qualquer Programa

Criei ao longo dos anos um pequeno ritual que evita boa parte dos problemas em produção. Antes de salvar qualquer alteração, faça estas perguntas:

  1. Entendi exatamente qual é o problema de negócio?

  2. Descobri todos os programas envolvidos?

  3. Verifiquei os COPYBOOKs relacionados?

  4. Analisei impactos em Db2, VSAM, CICS ou IMS?

  5. Procurei alterações semelhantes no histórico?

  6. Executei testes com dados normais e dados extremos?

  7. Pensei no que acontece se um campo vier vazio, nulo ou inesperado?

  8. Existe plano de retorno (rollback) caso algo dê errado?

  9. Alguém mais experiente revisou minha lógica?

  10. Eu conseguiria explicar esta alteração para outra pessoa em cinco minutos?

Se alguma resposta for "não", ainda há investigação a fazer.


Os Três Mestres da Carreira

Todo grande profissional aprende a equilibrar três características:

Coragem
Para enfrentar programas enormes sem fugir.

Curiosidade
Para investigar antes de alterar.

Humildade
Para aceitar que sempre existe algo escondido no sistema.

Esses três pilares são muito mais importantes do que decorar todas as instruções do COBOL.


O Último Easter Egg

Na saga Star Wars, Luke Skywalker acreditava que vencer significava lutar melhor.

Yoda ensinou outra coisa.

Primeiro, controlar a própria mente.

Só depois controlar o sabre de luz.

No Mainframe acontece exatamente o mesmo.

O COBOL não é o sabre.

O sabre é apenas uma ferramenta.

O verdadeiro combate acontece dentro da cabeça do programador.

A hesitação precisa ser transformada em investigação.

A ingenuidade precisa ser substituída por validação.

O excesso de confiança precisa dar lugar à disciplina.

Quando isso acontece, nasce um profissional capaz de trabalhar em ambientes onde milhões de transações financeiras, folhas de pagamento, benefícios governamentais, seguros, cartões de crédito e operações bancárias dependem de algumas linhas de código escritas décadas atrás.


Conclusão — O Primeiro Grande Upgrade Não é no Código, é no Programador

No universo Bellacosa Mainframe, costumo dizer que existem dois tipos de iniciantes.

O primeiro acredita que aprender COBOL significa memorizar verbos, comandos, JCLs e utilitários. Ele mede seu progresso pela quantidade de sintaxes que conhece.

O segundo entende que COBOL é apenas a linguagem usada para conversar com um ecossistema gigantesco de regras de negócio, processos, integrações e pessoas. Ele mede seu progresso pela qualidade das perguntas que faz, pela capacidade de investigar antes de modificar e pela prudência ao assumir responsabilidades.

É esse segundo profissional que evolui para analista, arquiteto, líder técnico e mentor.

A verdadeira iniciação de um Padawan Mainframe não acontece quando ele compila seu primeiro programa sem erros. Ela acontece no dia em que percebe que um sistema legado é como um templo antigo: cada rotina foi construída por gerações diferentes, cada COPYBOOK guarda um pedaço da história da empresa e cada linha de código existe por um motivo — mesmo que esse motivo tenha sido esquecido pelo tempo.

Se você conseguir vencer a hesitação sem perder a prudência, abandonar a ingenuidade sem perder a curiosidade e controlar o excesso de confiança sem perder a coragem, terá desenvolvido a característica mais valiosa de todas: o julgamento técnico.

E julgamento técnico não se aprende em um manual. Ele é construído a cada investigação, a cada revisão de código, a cada incidente resolvido e a cada lição deixada por um erro.

No fim das contas, o maior sistema que um programador COBOL precisa aprender a administrar não é o z/OS, o CICS ou o Db2.

É a própria mente. Só quando ela trabalha de forma disciplinada, investigativa e humilde é que o restante do ecossistema Mainframe deixa de parecer um labirinto e passa a revelar sua verdadeira arquitetura. Nesse momento, o Padawan deixa de apenas escrever programas e começa, de fato, a pensar como um guardião dos sistemas que sustentam parte da economia do mundo.

sábado, 25 de julho de 2026

O Código Nunca Foi o Mistério : Quando um Programador COBOL Descobre que Alterar Dez Linhas é Fácil... Difícil é Sobreviver ao Templo Esquecido do Sistema

 

Bellacosa Mainframe na aventura onde o codigo nunca foi o misterio

☕ Um Café no Bellacosa Mainframe

O Código Nunca Foi o Mistério

Quando um Programador COBOL Descobre que Alterar Dez Linhas é Fácil... Difícil é Sobreviver ao Templo Esquecido do Sistema

"Arqueologia não é procurar coisas velhas. É descobrir a história escondida por trás delas."

Se Indiana Jones tivesse escolhido Ciência da Computação em vez de Arqueologia, provavelmente terminaria trabalhando em um grande banco desenvolvendo COBOL.

Pode parecer exagero.

Mas pense comigo.

Indiana nunca encontrava o artefato logo na primeira sala.

Primeiro havia um mapa incompleto.

Depois uma caverna.

Uma armadilha.

Um diário escrito há cinquenta anos.

Um símbolo perdido.

Um templo subterrâneo.

Uma pedra falsa.

Uma ponte quebrada.

E somente depois de horas de investigação ele finalmente colocava as mãos no objeto que havia saído para procurar.

No Mainframe acontece exatamente a mesma coisa.

O gerente chega à sua mesa.

— "É só alterar umas dez linhas."

Você sorri.

Respira.

Abre o ISPF.

E cinco minutos depois percebe que acaba de entrar no equivalente computacional do Templo da Perdição.

Bem-vindo ao verdadeiro trabalho de um desenvolvedor COBOL.


Capítulo 1 — O Mapa Perdido

Todo aventureiro começa com um mapa.

O problema é que, no mundo corporativo, esse mapa quase nunca existe.

Ou pior.

Existe.

Mas foi escrito em 1994.

Em WordPerfect.

Impresso.

Escaneado.

Convertido para PDF.

E armazenado numa pasta chamada:

Documentacao_Final_Versao_Final_2_AgoraVai.pdf

Que obviamente está desatualizada desde 1998.

É nesse momento que o jovem programador descobre uma das maiores verdades da profissão.

O COBOL não é o sistema.

O programa é apenas uma pequena pedra dentro de uma pirâmide construída durante décadas.


Capítulo 2 — O Chicote Não é o COBOL

Muita gente acredita que dominar COBOL significa dominar Mainframe.

É o mesmo que dizer:

"Indiana Jones venceu porque sabia usar um chicote."

Não.

O chicote era apenas uma ferramenta.

O verdadeiro diferencial era compreender:

  • história

  • culturas

  • idiomas

  • símbolos

  • armadilhas

  • comportamento humano

Com COBOL acontece exatamente igual.

Conhecer:

MOVE
ADD
PERFORM
IF
READ
WRITE

é apenas aprender a usar o chicote.

O arqueólogo ainda nem entrou no templo.


Capítulo 3 — A Primeira Porta

Chega o chamado.

Modificar o programa FAT001.

Perfeito.

Onde ele está?

Ninguém sabe.

Começa então a expedição.

Primeira parada:

PDS COBOL

Nada.

Segunda parada.

LIBLOAD

Nada.

Terceira.

JCLLIB

Quarta.

PROCLIB

Quinta.

Scheduler

Somente depois de muito procurar você descobre:

JOBFIN01

↓

PROCFAT

↓

STEP040

↓

PGM=FAT001

Parabéns.

Você encontrou a porta do templo.

Agora começa a aventura.


Capítulo 4 — O Diário do Professor Ravenwood

Indiana Jones sempre encontrava um velho diário.

No Mainframe ele possui outro nome.

JCL.

O JCL é praticamente um diário de viagem.

Ele conta:

  • quem chamou o programa;

  • quais arquivos entram;

  • quais arquivos saem;

  • qual biblioteca foi usada;

  • quais parâmetros chegaram;

  • qual região executa;

  • qual ambiente está sendo utilizado.

Um simples trecho como:

//EXEC PGM=FAT001

parece insignificante.

Mas atrás dele existem dezenas de decisões arquitetônicas tomadas durante décadas.

O JCL responde perguntas que o próprio programa COBOL jamais responderá.


Capítulo 5 — As Pegadas na Poeira

Indiana observava pegadas.

Você observa datasets.

Imagine encontrar:

CLIENTE.GDG(+1)

Quem criou?

Quando?

Qual layout?

Possui compressão?

É VB?

FB?

RECFM?

LRECL?

Existe SORT anterior?

Existe IDCAMS?

Existe IEBGENER?

Cada dataset é uma pegada deixada por alguém que passou antes.

E cada pegada pode revelar uma história completamente diferente.


Capítulo 6 — O Labirinto dos Processamentos

Na imagem analisada, uma das partes mais brilhantes é justamente a existência de dois mundos:

Traitements Amont

e

Traitements Aval.

Pouca gente percebe a importância disso.

Imagine uma corrente.

Sistema A

↓

Sistema B

↓

Sistema C

↓

Sistema D

↓

Seu programa

O problema talvez tenha começado cinco programas antes.

Agora imagine o contrário.

Seu programa

↓

Financeiro

↓

PIX

↓

SPED

↓

Data Warehouse

↓

BI

↓

IA

Alterar um campo pode quebrar seis departamentos.

É como retirar uma pedra da parede de um templo maia.

Talvez nada aconteça.

Ou talvez toda a construção desabe.


Capítulo 7 — A Câmara das Armadilhas

Nos filmes existe sempre uma sala cheia de mecanismos mortais.

No Mainframe essa sala chama-se:

Regras de Negócio

Elas raramente aparecem documentadas.

Você encontra coisas como:

IF UF = "AM"

Por quê?

Silêncio.

Outro exemplo.

IF CODIGO = 37

Por quê?

Ninguém sabe.

Até que um veterano lembra.

— Em 1996 surgiu uma legislação especial.

Pronto.

Você acaba de resolver um mistério de trinta anos.


Curiosidade Bellacosa nº 1

Existe uma frase muito conhecida entre desenvolvedores experientes:

"Todo IF estranho possui uma história triste."

E normalmente ela envolve:

  • imposto;

  • banco central;

  • auditoria;

  • legislação;

  • cliente VIP;

  • bug ocorrido numa madrugada de domingo.


Capítulo 8 — O Cálice Sagrado Chama-se DB2

Muitos iniciantes acreditam que alterar uma tabela significa apenas executar:

ALTER TABLE

Longe disso.

Uma coluna nova pode afetar:

  • índices;

  • packages;

  • plans;

  • RUNSTATS;

  • REORG;

  • BIND;

  • stored procedures;

  • triggers;

  • views;

  • aplicações Java;

  • aplicações .NET;

  • relatórios;

  • APIs REST.

No filme, Indiana precisava escolher o cálice correto.

No Mainframe você precisa alterar a coluna correta.

Escolher errado custa muito mais caro que um filme de Hollywood.


Capítulo 9 — O Reino Invisível do CICS

Durante o dia:

Cliente consulta saldo.

À noite:

Batch recalcula saldo.

São dois mundos completamente diferentes.

Mas compartilham os mesmos dados.

É como duas expedições arqueológicas explorando entradas diferentes do mesmo templo.

Se um explorador mover uma pedra...

O teto pode cair sobre o outro.


Capítulo 10 — O Calendário Maia do Scheduler

Existe uma entidade misteriosa.

Poucos iniciantes lhe dão atenção.

Scheduler.

Ele sabe exatamente:

  • que horas tudo começa;

  • quanto cada JOB demora;

  • quem depende de quem;

  • qual janela operacional existe;

  • qual SLA precisa ser cumprido.

Imagine:

22:00 Recepção

22:30 Validação

23:10 DB2

00:20 COBOL

01:30 SPED

03:40 Banco Central

Você aumenta cinco minutos no processamento.

Agora tudo termina quinze minutos depois.

Às vezes isso significa apenas atraso.

Às vezes significa multa milionária.


Easter Egg nº 1 — A Pedra Rolante

Todo programador COBOL já viveu algo parecido.

Você altera uma linha.

Executa o teste.

Tudo funciona.

Vai para homologação.

Tudo funciona.

Vai para produção.

Então aparece uma "pedra rolante" gigantesca.

Não era seu programa.

Era um JOB executado apenas no último dia útil do mês, usando um parâmetro que ninguém lembrava existir.

A pedra não persegue Indiana Jones apenas no cinema.

Ela também aparece às 02h47 da manhã, durante o fechamento contábil.


Capítulo 11 — A Arqueologia Digital

Talvez a maior habilidade de um desenvolvedor Mainframe não seja programar.

Seja investigar.

Você vira uma mistura de:

  • arqueólogo;

  • historiador;

  • investigador;

  • detetive;

  • matemático;

  • contador;

  • psicólogo;

  • engenheiro.

Cada programa é uma civilização antiga.

Cada comentário:

* NÃO ALTERAR

é uma inscrição hieroglífica.

Cada COPYBOOK é um pergaminho.

Cada PDS é uma biblioteca de Alexandria.

Cada JOB é uma rota comercial entre impérios.


Passo a Passo — Como um Desenvolvedor Experiente Investiga uma Alteração

Antes de escrever qualquer linha de código, siga uma metodologia quase arqueológica:

Etapa 1 — Entenda o requisito

Não aceite frases como:

"É só mudar um IF."

Pergunte:

  • Qual problema de negócio será resolvido?

  • Existe documentação?

  • Quem é o usuário afetado?


Etapa 2 — Localize o programa

  • PDS fonte

  • Load Library

  • Histórico de versões

  • Chamadores

  • Programas chamados


Etapa 3 — Analise o JCL

Verifique:

  • EXEC PGM

  • DD Statements

  • GDGs

  • SYSIN

  • SYSOUT

  • PROCs

  • PARM


Etapa 4 — Descubra os arquivos

Para cada dataset pergunte:

  • Quem gera?

  • Quem consome?

  • Qual layout?

  • Existe versionamento?


Etapa 5 — Analise o banco

  • Tabelas

  • Índices

  • Views

  • Packages

  • Plans

  • Estatísticas

  • SQLs afetados


Etapa 6 — Verifique integrações

Existe:

  • CICS?

  • MQ?

  • Web Services?

  • z/OS Connect?

  • APIs?

  • Batch paralelo?


Etapa 7 — Procure regras escondidas

Nunca confie apenas na documentação.

Leia o código.

Leia comentários antigos.

Converse com analistas.

Converse com usuários.

Muitas regras vivem apenas na memória das pessoas.


Etapa 8 — Teste impacto

Pergunte sempre:

Quem depende disso?

Quem será afetado?

Quem vai perceber?


Curiosidade Bellacosa nº 2

Em muitos bancos existem programas COBOL executando diariamente há mais de quarenta anos.

Alguns foram escritos antes mesmo do nascimento dos desenvolvedores que hoje fazem sua manutenção.

É como entrar em uma tumba egípcia sabendo que o arquiteto original nunca imaginou que alguém, quatro décadas depois, ainda pisaria naquele corredor para instalar uma nova "porta secreta".


Easter Egg nº 2 — O "X" Nunca Marca o Lugar

Nos filmes, o mapa sempre mostra um enorme X indicando o tesouro.

No desenvolvimento corporativo acontece exatamente o contrário.

O chamado diz:

"Alterar o programa FAT001."

Você passa dois dias investigando e descobre que o problema verdadeiro está em:

  • um parâmetro no Scheduler;

  • um SORT que remove registros;

  • um COPYBOOK compartilhado;

  • uma VIEW DB2;

  • um arquivo recebido de outro sistema.

O X nunca marca o lugar certo. A jornada até ele é que revela onde o verdadeiro problema estava escondido.


Conclusão — O Tesouro Não é o Código

Quando iniciamos nossa jornada em COBOL, acreditamos que aprenderemos uma linguagem de programação.

Com o tempo percebemos que aprendemos algo muito maior.

Aprendemos engenharia de sistemas.

O programa COBOL é apenas a ponta visível de um enorme continente tecnológico formado por JCLs, PROCs, Scheduler, Db2, CICS, VSAM, arquivos, integrações, calendários operacionais e regras de negócio acumuladas ao longo de décadas.

É por isso que dois profissionais com o mesmo domínio da sintaxe podem ter desempenhos completamente diferentes. Um conhece os verbos da linguagem; o outro conhece a história do templo, onde estão as armadilhas, quais corredores desabam, onde ficam as passagens secretas e qual pedra jamais deve ser removida.

No universo Bellacosa Mainframe, o verdadeiro desenvolvedor COBOL não é apenas um programador. Ele é um explorador da computação corporativa, alguém que entra diariamente em ruínas digitais construídas por gerações de engenheiros e retorna trazendo o artefato mais valioso de todos: uma alteração segura, compreendida e confiável, capaz de preservar sistemas que movimentam bancos, governos, seguradoras e a economia mundial sem que milhões de usuários sequer percebam que uma aventura aconteceu durante a madrugada.

E, como diria um certo arqueólogo de chapéu e chicote, ao fechar mais um chamado aparentemente simples:

"O código pertence ao sistema... mas o conhecimento pertence a quem teve coragem de explorar o templo inteiro antes de alterar uma única linha."

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