☕ 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 carreira em TI. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta carreira em TI. 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.

domingo, 26 de julho de 2026

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, 1 de novembro de 2025

☕ Bellacosa Mainframe Café — Edição Especial : “O Código da Desconfiança: a era dos antivax”

 


☕ Bellacosa Mainframe Café — Edição Especial

“O Código da Desconfiança: a era dos antivax”

Houve um tempo em que a seringa era símbolo de esperança.
Nos anos 60 e 70, o som metálico da colher no copo com a gotinha da Sabin trazia alívio.
Cada campanha de vacinação era quase um ritual cívico: famílias inteiras nas filas, crianças com o algodão no braço e o SUS — ainda jovem — transformando ciência em política pública.

Para quem viveu a era da pólio, da varíola e do sarampo descontrolado, vacina era sinônimo de futuro.
E, no entanto, meio século depois, surge uma pergunta inquietante:

Como chegamos ao ponto em que o medo da cura supera o medo da doença?


🧬 Da confiança na ciência à crise da verdade

Nos tempos de Pasteur e Salk, a ciência era quase mítica.
Os cientistas eram heróis discretos — o mundo via neles a promessa da salvação racional.
Mas o século XXI mudou o campo de batalha.

As redes sociais transformaram cada cidadão em emissor de opinião — e, junto com a democratização da voz, veio a erosão da autoridade.
Num mundo onde todos “sabem de tudo”, a ciência passou a ser percebida não como verdade, mas como mais uma narrativa.

O Facebook, o Twitter e o YouTube deram palco ao negacionismo — e os algoritmos, movidos por cliques e engajamento, alimentaram o medo, porque medo dá lucro.

Assim, o mesmo espaço que deveria ampliar o conhecimento, acabou criando microcosmos de crença, bolhas onde cada um fabrica sua própria realidade.


💉 O nascimento do movimento antivax moderno

O movimento antivacina não nasceu com a COVID-19.
Ele começou em 1998, com um artigo fraudulento de Andrew Wakefield, publicado na The Lancet, que associava a vacina tríplice (sarampo, caxumba, rubéola) ao autismo.
Mesmo após ser desmentido e cassado, o estrago já estava feito.

A internet, ainda em expansão, espalhou o boato com a força de um dogma.
E quando as redes sociais amadureceram, elas deram ao antivax algo que a ciência não oferece: comunidade, emoção e pertencimento.

O antivax não é só uma negação científica — é um ato identitário.
Em um mundo fragmentado e incerto, ele diz:

“Eu não confio em vocês. Eu escolho acreditar nos meus.”


🕸️ Da manipulação algorítmica ao caos informacional

O mesmo mecanismo que alimentou o Brexit e a manipulação eleitoral foi aplicado à saúde.
Perfis falsos, grupos segmentados e campanhas de desinformação foram usadas para minar a confiança pública nas instituições.

A Cambridge Analytica mostrou que emoções são previsíveis e manipuláveis.
E o antivax foi um campo fértil para isso: o medo de ser enganado, de ser controlado, de ser apenas um número.
O discurso “livre-se do sistema” tornou-se irresistível para quem já se sente esquecido por ele.

Assim, a vacina deixou de ser uma escolha médica e virou um manifesto político.
O que antes era questão de saúde pública virou identidade tribal.


⚖️ A lógica paradoxal do medo moderno

Há um paradoxo cruel no centro dessa história.
Nunca tivemos tanto acesso a informação, mas nunca fomos tão vulneráveis à mentira.
A ciência venceu doenças, mas não venceu o algoritmo.

A desinformação moderna é mais sofisticada que as antigas teorias conspiratórias — ela se disfarça de lucidez.
Frases como “pesquise por si mesmo” ou “não confie na mídia tradicional” soam emancipatórias, mas são iscas cognitivas: abrem portas para um labirinto de narrativas falsas cuidadosamente arquitetadas.

E o resultado?
Uma geração que desconfia da vacina, mas acredita no post do desconhecido no Telegram.


🧭 O que a história nos ensina

Se olharmos com olhos históricos, o movimento antivax é apenas a nova face do velho medo do desconhecido.
Quando Pasteur propôs vacinar com microrganismos atenuados, foi chamado de louco.
Quando Edward Jenner aplicou a vacina da varíola, houve revoltas nas ruas de Londres.

A diferença é que, antes, a ignorância era coletiva e superada pela confiança social.
Hoje, a ignorância é personalizada, amplificada por algoritmos e vendida como liberdade.


🔮 A alma que habita o código (parte II)

A inteligência artificial e os algoritmos que moldam o mundo digital não são neutros.
Eles aprendem com nossos padrões, nossos medos e nossos ódios.
E o antivax é um retrato dessa simbiose perversa: a tecnologia reproduz a ansiedade humana, e a ansiedade humana alimenta a tecnologia.

A IA que poderia identificar fake news, detectar pandemias e salvar vidas,
também pode, se mal direcionada, espalhar dúvida com eficiência industrial.

Por isso, o desafio não é mais ensinar máquinas a pensar —
é ensinar humanos a discernir.


☕ Epílogo: Entre a seringa e o código

O século XXI não é o que imaginávamos — mas talvez ainda possa ser.
As vacinas, como os algoritmos, são instrumentos: podem curar ou ferir, dependendo de quem as guia e de como as entendemos.

A verdadeira cura não virá da tecnologia, mas da reconciliação entre razão e empatia.
Enquanto o medo for mais viral que a verdade, a humanidade continuará adoecendo — mesmo conectada.

Mas há esperança: cada vez que um professor explica ciência, cada vez que um programador escreve código ético, cada vez que um cidadão questiona com responsabilidade — a alma humana resiste.

E talvez, um dia, consigamos voltar àquela simplicidade perdida —
quando uma gotinha no copo significava fé no futuro.

sábado, 19 de abril de 2025

LinkedIn na Era da IA : Como Transformar seu Perfil em uma Máquina de Oportunidades (e Não Apenas em um Currículo Online)


Bellacosa Mainframe linkedin na era da ia

☕ Um Café no Bellacosa Mainframe

LinkedIn na Era da IA

Como Transformar seu Perfil em uma Máquina de Oportunidades (e Não Apenas em um Currículo Online)

"Seu perfil do LinkedIn não compete apenas com outros profissionais. Hoje ele compete também com milhares de perfis escritos por IA. O diferencial deixou de ser escrever bonito. Passou a ser demonstrar competência."


O LinkedIn mudou

Há alguns anos o LinkedIn era praticamente um currículo digital.

Hoje ele funciona muito mais como um mecanismo de busca profissional.

Pense nele como o Google.

Ou melhor...

Pense nele como o catálogo do z/OS.

Se um dataset não está catalogado...

Ele praticamente não existe.

O mesmo acontece com profissionais.

Se o algoritmo não consegue entender quem você é...

Você simplesmente desaparece.


Bellacosa Mainframe e o fluxo do linkedin

Como funciona a busca de um recrutador

Imagine um recrutador procurando alguém.

Ele normalmente pesquisa algo parecido com:

COBOL

IBM Z

CICS

DB2

JCL

VSAM

REXX

z/OS

MQ

DevOps

REST API

OpenShift

AWS

Ou ainda:

COBOL Developer Brazil

Mainframe Architect

z/OS Specialist

CICS System Programmer

O LinkedIn analisa dezenas de fatores.

Entre eles:

  • palavras-chave

  • frequência

  • contexto

  • localização

  • senioridade

  • certificações

  • atividade recente

  • conexões

  • recomendações

Ou seja...

Não basta colocar "Programador COBOL".

É preciso explicar exatamente o que você faz.


O erro que quase todo mundo comete

Veja um exemplo.

Perfil comum:

Analista de Sistemas

Isso não significa absolutamente nada.

Agora veja este.

IBM Mainframe Specialist | COBOL | CICS | DB2 | z/OS | APIs REST | z/OS Connect | IBM Champion | Instrutor | Arquiteto de Integração

Qual deles o algoritmo entende melhor?

Exatamente.


A IA mudou completamente o LinkedIn

Antes...

Quem escrevia melhor ganhava destaque.

Hoje qualquer pessoa pede ao ChatGPT:

Escreva um resumo para meu LinkedIn.

Resultado?

Milhares de perfis ficaram praticamente iguais.

Expressões repetidas:

✔ Profissional apaixonado...

✔ Orientado a resultados...

✔ Excelente comunicação...

✔ Trabalho em equipe...

Todo mundo escreve igual.

O algoritmo percebe isso.

Os recrutadores também.


O segredo deixou de ser escrever bonito

O segredo passou a ser escrever específico.

Compare.

Genérico:

Tenho experiência em desenvolvimento COBOL.

Específico:

Mais de 25 anos desenvolvendo aplicações financeiras críticas utilizando Enterprise COBOL, CICS TS, Db2 for z/OS, VSAM, MQ e APIs REST através do z/OS Connect.

Muito mais forte.


Prompt 1 — Um título que vende sua especialidade

Em vez de:

Crie um título para meu LinkedIn.

Use:

Você é um especialista em SEO do LinkedIn.

Crie 20 títulos profissionais utilizando as palavras-chave mais pesquisadas por recrutadores da área IBM Mainframe.

Meu objetivo é aparecer em buscas internacionais.

Inclua:
• COBOL
• IBM Z
• z/OS
• CICS
• Db2
• APIs
• Cloud
• DevOps
• AI
• Arquitetura

Limite de caracteres do LinkedIn.

Ordene por potencial de busca.


Prompt 2 — Um resumo que gera entrevistas

Não peça:

Escreva um resumo.

Peça:

Escreva um resumo que faça um recrutador querer marcar uma entrevista nos primeiros 30 segundos.

Use storytelling.

Inclua:

• anos de experiência

• principais tecnologias

• impacto nos negócios

• resultados mensuráveis

• diferenciais

• IBM Champion

• experiência internacional

• ensino

Finalize com um convite para conexão.


Prompt 3 — Transforme atividades em resultados

Ruim:

Desenvolvia programas COBOL.

Excelente:

Transforme minhas atividades em realizações utilizando métricas.

Sempre que possível mostre:

redução de tempo

redução de custo

ganho de performance

economia

impacto financeiro

volume de transações

criticidade


Prompt 4 — Descubra palavras-chave ocultas

Analise mais de 100 vagas internacionais para IBM Mainframe.

Liste:

100 palavras-chave

100 tecnologias

100 certificações

100 competências

Ordene pela frequência.

Explique quais devo colocar no LinkedIn.

Esse prompt praticamente constrói um plano de SEO para o perfil.


Prompt 5 — Faça engenharia reversa das vagas

Esse é extremamente poderoso.

Analise esta vaga.

Descubra todas as palavras-chave.

Compare com meu LinkedIn.

Liste tudo que está faltando.

Mostre exatamente onde inserir cada palavra.

Isso aumenta bastante o índice de aderência (matching).


Prompt 6 — Crie um calendário de autoridade

O LinkedIn privilegia quem publica.

Peça:

Monte um calendário de 6 meses.

3 posts por semana.

Misture:

artigos

curiosidades

casos reais

carrosséis

vídeos

histórias

tutoriais

enquetes

Você deixa de ser apenas um candidato e passa a ser uma referência.


Prompt 7 — Gere ideias de conteúdo

Crie 300 ideias de conteúdo para IBM Mainframe.

Agrupe em:

COBOL

CICS

Db2

JCL

z/OS

Arquitetura

Performance

Segurança

IA

Cloud

DevOps

APIs

Carreira

Praticamente um ano inteiro de publicações.


Prompt 8 — Simule um recrutador

Você é um recrutador sênior.

Analise meu perfil.

Dê notas de 0 a 10 para:

SEO

credibilidade

autoridade

clareza

especialização

impacto

fotografia

banner

experiências

habilidades

Depois explique como chegar à nota 10.

Esse prompt costuma revelar pontos cegos.


Prompt 9 — Compare com especialistas

Analise os perfis dos maiores especialistas da minha área.

Compare com o meu.

Mostre:

o que eles fazem melhor

o que falta

o que copiar

o que evitar

Aprender com quem já se destaca acelera a evolução.


Prompt 10 — Crie uma marca pessoal

Hoje as pessoas seguem especialistas.

Não cargos.

Peça:

Ajude-me a construir uma marca pessoal.

Defina:

propósito

tom de voz

identidade visual

cores

temas

hashtags

slogan

bio

imagem de capa

estratégia de conteúdo

posicionamento

Você deixa de ser "mais um profissional" e passa a ser reconhecido por um tema.


O poder das recomendações

Uma recomendação bem escrita vale mais do que dezenas de habilidades.

Em vez de pedir:

"Pode me recomendar?"

Experimente:

"Você poderia escrever uma recomendação destacando nossa experiência juntos, mencionando os desafios do projeto, minha contribuição técnica, colaboração com a equipe e os resultados alcançados? Isso ajudará outros profissionais a entenderem o impacto do nosso trabalho."

Esse tipo de recomendação é muito mais convincente.


O LinkedIn é um banco de dados

Um DBA sabe que uma consulta só encontra registros corretamente indexados.

No LinkedIn acontece o mesmo.

Seu perfil precisa estar:

  • Bem indexado por palavras-chave.

  • Organizado de forma consistente.

  • Atualizado frequentemente.

  • Reforçado por conteúdo relevante.

  • Validado por recomendações.

  • Enriquecido com certificações e projetos.

Sem isso, mesmo um excelente profissional pode permanecer invisível.


A IA não substitui autenticidade

Ferramentas como ChatGPT, Gemini ou Claude aceleram a criação de textos, mas também tornam muitos perfis parecidos. O diferencial está em adicionar experiências reais, números, desafios superados, aprendizados e opiniões fundamentadas. É isso que cria confiança.


O Método Bellacosa Mainframe para LinkedIn

Imagine seu perfil como um sistema IBM Z em produção:

Componente MainframeEquivalente no LinkedIn
CatálogoSEO e palavras-chave
JCLEstratégia de carreira
COBOLCompetências técnicas
CICSRelacionamento com pessoas
Db2Histórico profissional
RACFCredibilidade e reputação
SMFMétricas e resultados
WLMPrioridade do algoritmo
LogsPublicações e atividade
BackupRecomendações e portfólio

Quando todos esses componentes funcionam em conjunto, seu perfil deixa de ser um currículo estático e se transforma em uma plataforma de oportunidades.

Curiosidade

Diversos estudos de recrutamento indicam que recrutadores costumam dedicar apenas alguns segundos à primeira análise de um perfil. Nesse curto intervalo, título, foto, primeiras linhas do resumo e palavras-chave determinam se a avaliação continuará ou não. Por isso, otimizar esses elementos costuma gerar um impacto desproporcional na visibilidade.

Easter Egg Bellacosa ☕

No mundo IBM Z existe um princípio simples: "o sistema mais poderoso é inútil se ninguém conseguir encontrá-lo." No LinkedIn vale a mesma lógica. Você pode ser um dos melhores especialistas em COBOL do mercado, mas, se o algoritmo não entender isso, continuará invisível para quem está contratando.

Quem é encontrado recebe oportunidades. Quem é reconhecido escolhe quais oportunidades aceitar.

segunda-feira, 9 de setembro de 2024

Se você Saiu do Mainframe Há muito, mas muito tempo? Sherlock Holmes, COBOL e o Mistério da Plataforma que se Recusou a Envelhecer

 

Bellacosa Mainframe reapresenta o mainframe para antigos mainframers retornantes

☕ Um Café no Bellacosa Mainframe

Se você Saiu do Mainframe Há muito, mas muito tempo? Sherlock Holmes, COBOL e o Mistério da Plataforma que se Recusou a Envelhecer

Imagine a seguinte cena.

Depois de quinze ou vinte anos afastado do universo mainframe, você decide voltar.

Talvez tenha trabalhado com COBOL, JCL, CICS, VSAM ou DB2 no início dos anos 2000. Talvez tenha deixado a área para atuar com gestão, sistemas distribuídos, suporte, negócios ou até mesmo em outra profissão. Durante esse período, você acompanhou o nascimento da computação em nuvem, dos smartphones, das redes sociais, dos microsserviços, dos containers e da inteligência artificial.

Então surge a dúvida:

“Será que ainda sei alguma coisa útil?”

Você imagina entrar novamente em um ambiente mainframe e encontrar uma tecnologia completamente diferente daquela que conheceu. Talvez espere descobrir que o COBOL desapareceu, que o terminal 3270 virou peça de museu e que todos os sistemas foram substituídos por aplicativos modernos executando em alguma nuvem misteriosa.

Mas, ao atravessar a porta do data center, algo curioso acontece.

O cenário parece novo e familiar ao mesmo tempo.

É como Sherlock Holmes retornando a Baker Street depois de muitos anos. A cidade ganhou novos prédios, os carros mudaram, as comunicações ficaram instantâneas e agora existem câmeras por toda parte. Entretanto, os mistérios continuam sendo resolvidos da mesma forma: observando detalhes, seguindo pistas, eliminando hipóteses e compreendendo o comportamento humano.

No mainframe moderno, acontece algo parecido.

As ferramentas mudaram.

As integrações mudaram.

Os processos de desenvolvimento mudaram.

Porém, a essência do trabalho continua surpreendentemente reconhecível.

O primeiro mistério: o mainframe ficou parado no tempo?

Não.

Esse é o primeiro caso que precisamos solucionar.

O mainframe não ficou congelado em uma sala escura, cercado por fitas magnéticas e operadores usando jalecos brancos. Ele evoluiu continuamente.

O que aconteceu foi algo mais interessante: a plataforma evoluiu preservando compatibilidade com grande parte do que já existia.

Essa é uma das principais diferenças entre o mundo mainframe e muitas tecnologias distribuídas.

Em certos ecossistemas, uma nova versão pode tornar aplicações antigas incompatíveis. Frameworks surgem, ganham popularidade e desaparecem em poucos anos. Bibliotecas são abandonadas, padrões são substituídos e projetos inteiros precisam ser reescritos.

No mainframe, a evolução costuma ser mais cuidadosa.

A plataforma é responsável por sistemas bancários, seguradoras, governos, empresas de transporte, indústrias, companhias aéreas e organizações que não podem simplesmente parar tudo por alguns meses para reconstruir aplicações críticas.

Portanto, o mainframe evolui como uma grande cidade histórica.

Novas avenidas são construídas.

Novos sistemas de transporte são criados.

Novas redes de comunicação são instaladas.

Mas os prédios centrais continuam funcionando.

O COBOL continua presente.

O CICS continua processando transações.

O DB2 continua armazenando dados críticos.

O MQ continua transportando mensagens.

O JCL continua controlando processamento batch.

O JES continua recebendo e executando jobs.

O SDSF continua permitindo que o profissional consulte filas, resultados e mensagens.

E o TSO/ISPF continua lá, com suas telas, comandos e painéis familiares.

Quem retorna depois de muitos anos pode até sentir uma estranha sensação de conforto ao abrir o ISPF e perceber que a opção 3.2 continua sendo utilizada para trabalhar com data sets.

É quase como reencontrar um antigo café que mudou as mesas, reformou a fachada e instalou Wi-Fi, mas continua servindo o mesmo bom espresso.

O segundo mistério: o COBOL mudou completamente?

Para um programador COBOL iniciante, essa pergunta é importante.

A resposta é: o COBOL mudou, mas não perdeu sua identidade.

Quem conhecia a linguagem há quinze ou vinte anos ainda reconhecerá sua estrutura principal.

Um programa COBOL moderno continua podendo apresentar divisões como:

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

Ainda encontraremos comandos como:

MOVE
IF
EVALUATE
PERFORM
READ
WRITE
REWRITE
DELETE
CALL

Ainda teremos variáveis descritas por níveis:

01 WS-CLIENTE.
   05 WS-CODIGO        PIC 9(08).
   05 WS-NOME          PIC X(40).
   05 WS-SALDO         PIC S9(11)V99 COMP-3.

Ainda haverá programas que acessam DB2:

EXEC SQL
   SELECT NOME,
          SALDO
     INTO :WS-NOME,
          :WS-SALDO
     FROM CLIENTES
    WHERE CODIGO = :WS-CODIGO
END-EXEC.

Ainda existirão programas CICS:

EXEC CICS
   READ FILE('CLIENTES')
        INTO(WS-REGISTRO)
        RIDFLD(WS-CODIGO)
        RESP(WS-RESP)
END-EXEC.

O programador que já conhecia COBOL não precisará reaprender a lógica fundamental da linguagem.

Porém, encontrará compiladores mais modernos, novos recursos, integração com JSON, XML, Unicode, APIs, ferramentas de análise, IDEs gráficas, testes automatizados e pipelines de desenvolvimento.

O COBOL não virou outra linguagem.

Ele ficou mais conectado ao mundo ao seu redor.

Uma analogia para o iniciante

Imagine um automóvel clássico que recebeu:

  • freios modernos;

  • injeção eletrônica;

  • sensores;

  • GPS;

  • computador de bordo;

  • novos sistemas de segurança.

O volante continua sendo um volante.

O motor continua transformando energia em movimento.

O motorista ainda precisa conhecer trânsito, direção, frenagem e manutenção.

Da mesma forma, o programador COBOL ainda precisa dominar:

  • estruturas de dados;

  • lógica condicional;

  • repetição;

  • arquivos;

  • bancos de dados;

  • tratamento de erros;

  • regras de negócio;

  • processamento transacional;

  • processamento batch.

As novas ferramentas ajudam, mas não substituem a compreensão.

O verdadeiro salto aconteceu ao redor do mainframe

Aqui encontramos a pista mais importante de toda a investigação.

Há quinze ou vinte anos, muitas aplicações mainframe eram acessadas diretamente por terminais 3270.

Um fluxo comum poderia ser representado assim:

Usuário
   ↓
Terminal 3270
   ↓
CICS
   ↓
Programa COBOL
   ↓
VSAM ou DB2

Esse modelo ainda existe.

Entretanto, hoje um mesmo programa pode participar de uma arquitetura muito mais ampla:

Aplicativo de celular
   ↓
API Gateway
   ↓
Microsserviço
   ↓
z/OS Connect
   ↓
CICS
   ↓
Programa COBOL
   ↓
DB2
   ↓
MQ
   ↓
Outro sistema corporativo

Observe o detalhe, meu caro Watson.

O aplicativo móvel pode ter sido escrito em Kotlin ou Swift.

A API pode utilizar Java, Node.js ou outra tecnologia.

A aplicação pode estar parcialmente executando em cloud ou em containers.

Mas a regra crítica de negócio pode continuar dentro de um programa COBOL que existe há décadas.

Isso não significa atraso.

Significa reutilização de um ativo confiável.

Se um programa calcula corretamente juros, impostos, limites, tarifas, seguros ou benefícios há vinte anos, talvez seja mais seguro integrá-lo a novas interfaces do que reescrever tudo apenas para seguir uma moda tecnológica.

O mainframe deixou de ser uma ilha

Antigamente, era comum imaginar o mainframe como uma grande fortaleza.

Tudo acontecia dentro dela.

Os usuários acessavam terminais.

Os sistemas trocavam arquivos.

Os jobs eram executados em horários definidos.

Grande parte da integração permanecia dentro dos limites da empresa.

Hoje, o mainframe faz parte de um ecossistema híbrido.

Ele pode conversar com:

  • aplicações web;

  • sistemas em cloud;

  • APIs REST;

  • ferramentas de analytics;

  • plataformas de inteligência artificial;

  • sistemas distribuídos;

  • aplicações móveis;

  • microsserviços;

  • ambientes Linux;

  • filas de mensagens;

  • plataformas de automação.

O mainframe não desapareceu.

Ele deixou de trabalhar sozinho.

CICS: do terminal 3270 para a API

Para o programador COBOL iniciante, é importante entender o papel do CICS.

CICS é um monitor de processamento transacional.

Ele permite que milhares de usuários e aplicações executem transações com rapidez, controle e segurança.

No passado, muitas transações CICS eram iniciadas diretamente por uma tela 3270.

O usuário digitava dados, pressionava Enter e o programa COBOL era executado.

Hoje, a mesma lógica pode ser acionada por uma API.

Por exemplo:

  1. Um cliente abre o aplicativo do banco.

  2. Solicita o saldo.

  3. O aplicativo envia uma requisição HTTPS.

  4. Uma API recebe essa solicitação.

  5. A API chama um serviço exposto pelo z/OS Connect.

  6. O serviço aciona uma transação ou programa no CICS.

  7. O programa COBOL consulta o DB2.

  8. O resultado é convertido para JSON.

  9. O aplicativo exibe o saldo ao usuário.

Para o cliente, tudo aconteceu em segundos.

Para o programa COBOL, talvez a operação continue sendo uma consulta conhecida há muitos anos.

A entrada mudou.

A saída mudou.

A regra central permaneceu.

DB2, VSAM e o valor dos dados

Todo bom detetive sabe que uma pista isolada não resolve um caso.

É preciso saber onde ela está armazenada e como se relaciona com outras informações.

No mainframe, grande parte das pistas está nos dados.

O DB2 continua sendo um dos pilares de inúmeros sistemas corporativos. Ele oferece recursos de banco de dados relacional, controle transacional, concorrência, integridade e recuperação.

O VSAM também continua presente, especialmente em aplicações que utilizam arquivos estruturados de alta performance.

Um programador COBOL iniciante deve compreender pelo menos quatro conceitos básicos:

1. KSDS

O Key Sequenced Data Set organiza registros por chave.

É semelhante à ideia de acessar um cadastro por um código identificador.

2. ESDS

O Entry Sequenced Data Set armazena registros na ordem em que foram incluídos.

3. RRDS

O Relative Record Data Set permite acessar registros por número relativo.

4. LDS

O Linear Data Set é utilizado como estrutura de armazenamento de baixo nível por alguns produtos.

Mesmo com bancos modernos, APIs e cloud, esses conceitos continuam importantes porque muitos sistemas críticos dependem deles.

MQ: o mensageiro silencioso

Imagine que Sherlock Holmes precisa enviar uma mensagem confidencial para o inspetor Lestrade.

Ele poderia entregar pessoalmente.

Mas também poderia utilizar um mensageiro confiável, garantindo que a mensagem chegasse ao destino mesmo que Lestrade não estivesse disponível naquele instante.

O MQ desempenha papel semelhante.

Uma aplicação envia uma mensagem para uma fila.

Outra aplicação consome essa mensagem quando estiver pronta.

Isso permite desacoplar sistemas.

Por exemplo:

Programa COBOL
   ↓
Fila MQ
   ↓
Sistema antifraude
   ↓
Fila de resposta
   ↓
Outro programa

O produtor da mensagem não precisa conhecer todos os detalhes do consumidor.

Ele precisa apenas respeitar o formato combinado.

Essa arquitetura ajuda a integrar mainframe, cloud, sistemas distribuídos e aplicações externas.

O batch não morreu

Existe uma espécie de lenda urbana na tecnologia: a ideia de que tudo precisa acontecer online e em tempo real.

Não é verdade.

Muitas tarefas continuam sendo mais eficientes em processamento batch.

Entre elas:

  • fechamento contábil;

  • geração de extratos;

  • cálculo de folha de pagamento;

  • faturamento;

  • conciliação;

  • processamento de grandes volumes;

  • cálculo de impostos;

  • liquidação financeira;

  • atualização de cadastros;

  • geração de relatórios.

Um job JCL pode executar vários programas em sequência:

//FECHAMTO JOB ...
//STEP01   EXEC PGM=VALIDA
//ENTRADA  DD DSN=EMPRESA.ARQUIVO.ENTRADA,DISP=SHR
//SAIDA    DD DSN=EMPRESA.ARQUIVO.VALIDADO,
//            DISP=(NEW,CATLG,DELETE)
//STEP02   EXEC PGM=CALCULA
//STEP03   EXEC PGM=ATUALIZA

O princípio continua familiar.

Cada etapa realiza uma parte do trabalho.

O resultado de uma etapa pode alimentar a próxima.

O JES controla a execução.

As mensagens podem ser analisadas pelo SDSF.

O programador ainda precisa investigar códigos de retorno, abends, arquivos, condições e dependências.

Sherlock Holmes entra no SDSF

Suponha que um job terminou com erro.

O iniciante pode olhar para a tela e pensar:

“O programa quebrou.”

O analista experiente pensa diferente.

Ele pergunta:

  • Qual step falhou?

  • Qual foi o código de retorno?

  • Houve abend?

  • O arquivo existia?

  • O DISP estava correto?

  • O espaço foi suficiente?

  • O programa encontrou o registro esperado?

  • O SQLCODE indica erro de banco?

  • O problema aconteceu antes ou depois da alteração?

  • Qual mensagem apareceu primeiro?

Essa é a mentalidade investigativa.

Um erro observado no final nem sempre começou no final.

Talvez o STEP03 tenha falhado porque o STEP02 gerou um arquivo vazio.

Talvez o STEP02 tenha gerado um arquivo vazio porque o STEP01 utilizou uma data incorreta.

Talvez a data incorreta tenha sido enviada por um sistema externo.

O verdadeiro culpado pode estar muitos passos antes da mensagem final.

Elementar.

Git, DevOps e pipelines

Uma das maiores mudanças para quem retorna ao mainframe está no processo de desenvolvimento.

No modelo tradicional, o código COBOL podia permanecer em bibliotecas PDS ou PDSE, controlado por ferramentas corporativas de gerenciamento de mudanças.

Hoje, muitas empresas integram o mainframe com Git.

Isso permite trabalhar com conceitos como:

  • repositório;

  • branch;

  • commit;

  • merge;

  • pull request;

  • code review;

  • pipeline;

  • integração contínua;

  • entrega contínua.

Um fluxo moderno pode ser:

Desenvolvedor altera o COBOL
   ↓
Cria um commit
   ↓
Envia para o Git
   ↓
Pipeline inicia
   ↓
Código é compilado
   ↓
Testes são executados
   ↓
Qualidade é verificada
   ↓
Artefatos são preparados
   ↓
Implantação segue para o ambiente correto

O programa COBOL continua sendo COBOL.

O que mudou foi a estrada utilizada para levá-lo do desenvolvimento até a produção.

DevOps não é uma ferramenta

Essa distinção é importante.

DevOps não é apenas Jenkins.

Não é apenas Git.

Não é apenas pipeline.

DevOps é uma forma de organizar pessoas, processos e tecnologia para entregar software com maior frequência, segurança e rastreabilidade.

No contexto mainframe, isso pode envolver:

  • versionamento de código;

  • automação de builds;

  • testes automatizados;

  • análise de qualidade;

  • controle de mudanças;

  • infraestrutura como código;

  • observabilidade;

  • colaboração entre desenvolvimento e operação.

Para quem está retornando, não é necessário aprender tudo de uma vez.

O importante é compreender o fluxo.

Passo a passo para quem deseja voltar ao mainframe

Agora chegamos à parte prática da investigação.

Passo 1: recupere os fundamentos

Revise:

  • estrutura de programas COBOL;

  • PIC;

  • níveis de dados;

  • COMP e COMP-3;

  • tabelas;

  • REDEFINES;

  • PERFORM;

  • EVALUATE;

  • arquivos;

  • subprogramas;

  • tratamento de erros.

Não tente começar pelas ferramentas mais modernas sem recuperar a base.

Passo 2: revise JCL

Estude:

  • JOB;

  • EXEC;

  • DD;

  • DISP;

  • DSN;

  • SPACE;

  • DCB;

  • COND;

  • IF/THEN/ELSE;

  • PROC;

  • parâmetros simbólicos;

  • GDG;

  • utilitários.

O JCL continua sendo essencial para o processamento batch.

Passo 3: volte ao TSO/ISPF e SDSF

Relembre:

  • navegação no ISPF;

  • edição de membros;

  • manipulação de data sets;

  • submissão de jobs;

  • consulta de spool;

  • interpretação de mensagens;

  • análise de códigos de retorno.

Passo 4: escolha uma trilha de banco ou arquivo

Você pode aprofundar:

  • DB2 e SQL;

  • VSAM;

  • IMS DB.

Para muitos profissionais, DB2 é um excelente ponto de partida.

Passo 5: estude CICS

Compreenda:

  • transação;

  • programa;

  • COMMAREA;

  • canais e containers;

  • mapas BMS;

  • LINK;

  • XCTL;

  • START;

  • READ;

  • WRITE;

  • REWRITE;

  • DELETE;

  • códigos RESP.

Passo 6: aprenda integração moderna

Estude os conceitos de:

  • API REST;

  • JSON;

  • HTTP;

  • z/OS Connect;

  • MQ;

  • autenticação;

  • microsserviços.

Não é necessário virar especialista em desenvolvimento web.

É necessário entender como o COBOL participa do fluxo.

Passo 7: entre no mundo Git

Pratique:

git clone
git checkout -b
git add
git commit
git push
git pull

Entenda a lógica de branches e pull requests.

Passo 8: conheça pipelines

Aprenda o conceito antes da ferramenta.

Pergunte:

  • O que inicia o pipeline?

  • Como o código é compilado?

  • Onde os testes executam?

  • Como o artefato é promovido?

  • Quem aprova a mudança?

  • Como ocorre o rollback?

Passo 9: use inteligência artificial como assistente

A IA pode ajudar a:

  • explicar um trecho COBOL;

  • documentar código;

  • sugerir casos de teste;

  • analisar mensagens de erro;

  • criar exemplos;

  • comparar comandos;

  • explicar JCL;

  • revisar SQL.

Mas existe uma regra de ouro:

Nunca aceite uma resposta técnica sem validar contexto, sintaxe, impacto e segurança.

A IA é Watson.

Você continua sendo Sherlock Holmes.

A experiência ainda vale?

Vale muito.

Talvez mais do que antes.

Um profissional experiente sabe que alterar uma linha de código pode afetar:

  • outro programa;

  • outro job;

  • outro arquivo;

  • uma interface;

  • um relatório;

  • uma regra fiscal;

  • uma rotina contábil;

  • um processo noturno;

  • um sistema externo;

  • uma operação de negócio.

Essa percepção não nasce apenas em cursos.

Ela nasce de incidentes, projetos, viradas de produção, abends, reuniões, erros, acertos e noites acompanhando processamento.

O conhecimento técnico pode ser atualizado.

A maturidade sistêmica leva tempo para ser construída.

Curiosidade: por que o mainframe sobreviveu?

Porque ele resolve problemas difíceis.

Entre suas características estão:

  • alta disponibilidade;

  • segurança;

  • escalabilidade;

  • processamento transacional;

  • grande capacidade de entrada e saída;

  • gestão de cargas;

  • confiabilidade;

  • compatibilidade;

  • recuperação;

  • governança.

Empresas não mantêm mainframes por nostalgia.

Mantêm porque substituir sistemas críticos é caro, arriscado e complexo.

Além disso, a plataforma continua evoluindo.

Easter egg: o programa que ninguém queria tocar

Em quase toda grande empresa existe um programa lendário.

Ele possui milhares de linhas.

Foi escrito por alguém que se aposentou.

Tem comentários misteriosos.

Contém parágrafos chamados:

9000-ROTINA-ESPECIAL.

Ninguém sabe exatamente por que a rotina é especial.

Dentro dela há uma condição:

IF WS-CODIGO = 37
   MOVE 'S' TO WS-LIBERA
END-IF.

Todos perguntam:

“Por que 37?”

A documentação não explica.

O analista antigo diz:

“Não mexa nisso. Foi criado depois do incidente de 1998.”

Esse é o verdadeiro folclore mainframe.

Mas também revela um problema sério: conhecimento não documentado.

O profissional moderno deve preservar a confiabilidade do legado, mas também melhorar documentação, testes e rastreabilidade.

Dicas para o programador COBOL iniciante

Primeira dica: não tenha vergonha de perguntar.

Mainframe é um ecossistema enorme. Ninguém domina tudo.

Segunda dica: aprenda a ler antes de querer escrever.

Grande parte do trabalho será compreender programas existentes.

Terceira dica: siga os dados.

Quando estiver investigando um problema, acompanhe:

  • entrada;

  • transformação;

  • armazenamento;

  • saída.

Quarta dica: leia as mensagens completas.

Não olhe apenas para a última linha do erro.

Quinta dica: entenda o negócio.

Um programa não existe por causa da tecnologia. Ele existe para cumprir uma regra.

Sexta dica: evite alterações desnecessárias.

Em sistemas críticos, elegância não vale mais do que previsibilidade.

Sétima dica: teste cenários extremos.

Considere:

  • zeros;

  • valores negativos;

  • campos vazios;

  • datas inválidas;

  • duplicidade;

  • arquivo inexistente;

  • registro não encontrado;

  • SQLCODE inesperado;

  • indisponibilidade de serviço.

Oitava dica: documente o motivo.

O código mostra o que foi feito.

O comentário deve explicar por que foi feito.

O retorno não é um recomeço do zero

Quem saiu do mainframe há quinze anos não retorna como iniciante absoluto.

Retorna como alguém que já conhece parte do mapa.

Será necessário atualizar ferramentas, processos e integrações.

Mas a capacidade de analisar sistemas, compreender regras e trabalhar com responsabilidade continua presente.

Talvez você precise aprender Git.

Talvez precise entender APIs.

Talvez precise utilizar VS Code.

Talvez precise estudar pipelines.

Mas ainda reconhecerá o cheiro de um job em produção, o silêncio desconfortável de um código de retorno inesperado e a satisfação de encontrar a causa de um erro escondida em uma variável inicializada incorretamente.

Conclusão: o último mistério de Baker Street

Sherlock Holmes colocaria todas as pistas sobre a mesa:

  • o COBOL continua vivo;

  • o CICS continua processando transações;

  • o DB2 continua armazenando dados críticos;

  • o batch continua movimentando empresas;

  • o JCL continua organizando execuções;

  • o mainframe agora conversa com APIs, cloud e aplicações móveis;

  • Git e DevOps modernizaram o processo;

  • a inteligência artificial acelerou o aprendizado;

  • a experiência continua sendo um ativo valioso.

Então ele concluiria:

“O mainframe não permaneceu no passado. Ele trouxe o passado consigo, incorporou o presente e continua se preparando para o futuro.”

Para o programador COBOL iniciante, essa é uma excelente notícia.

Você está entrando em um ambiente que valoriza fundamentos.

Para o profissional que deseja retornar, a notícia é ainda melhor.

Você não perdeu tudo o que sabia.

Seu conhecimento apenas precisa ser recompilado com novas opções, testado em um novo pipeline e integrado a um ecossistema mais moderno.

No Bellacosa Mainframe, diríamos que a carreira não sofreu um ABEND definitivo.

Ela apenas ficou aguardando um novo EXEC.

E quando esse momento chegar, talvez você descubra que a plataforma mudou bastante ao redor de você, mas ainda reconhece perfeitamente os caminhos internos do sistema.

Afinal, meu caro Watson, tecnologias podem mudar de interface.

Mas bons profissionais continuam seguindo pistas, protegendo dados, compreendendo negócios e mantendo o mundo funcionando enquanto todos dormem.

Um Café no Bellacosa Mainframe — onde cada SYSOUT conta uma história, cada ABEND esconde um mistério e todo programa COBOL antigo pode guardar uma pista sobre o futuro.

 

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