Translate

segunda-feira, 3 de agosto de 2026

CSI Las Vegas — O Caso do Agente Fantasma Afinal : Onde Mora o IBM Bob?

Bellacosa Mainframe e o caso do agente fantasma onde o ibm bob habita?

☕ Um Café no Bellacosa Mainframe

CSI Las Vegas — O Caso do Agente Fantasma

Afinal... Onde Mora o IBM Bob?

"Toda investigação começa com uma pergunta aparentemente simples. No CSI Las Vegas aprendemos que, muitas vezes, a resposta está escondida exatamente onde ninguém pensa em procurar."

A pergunta chegou ao laboratório Bellacosa Mainframe numa tarde qualquer.

"O IBM Bob mora dentro do Mainframe?"

Silêncio.

O programador COBOL olha para o SDSF.

O operador observa a JES2.

O Sysprog abre a SYS1.PROCLIB.

O Administrador RACF consulta os Started Tasks.

Nada.

Nenhum PROC chamado BOB.

Nenhuma SYS.BOB.LIB.

Nenhum BOBLOAD.

Nenhum BOBPROC.

Nenhum STC.

Então...

Onde diabos mora esse agente?

Pegue sua lanterna.

Hoje investigaremos uma das maiores cenas do crime da Inteligência Artificial aplicada ao IBM Z.


Cena do Crime

CSI Las Vegas.

Sala escura.

Monitores iluminando o laboratório.

Na parede um enorme diagrama do z/OS.

Grissom aproxima-se.

— Catherine...

Onde está o Bob?

Nick responde:

— Não encontramos nenhum dataset.

Sara consulta o catálogo.

LISTCAT LEVEL(SYS.BOB)

Resultado:

ENTRY NOT FOUND

Brass pergunta:

— Então ele não existe?

Grissom sorri.

— Existe.

Só não mora onde vocês estão procurando.



A Primeira Hipótese

Todo programador COBOL imagina algo parecido com isto.

SYS1.PROCLIB

↓

SYS1.PARMLIB

↓

SYS1.LINKLIB

↓

USER.COBOL

↓

COPYLIB

↓

JCLLIB

↓

SYS.BOB.LIB

Seria maravilhoso.

Uma biblioteca contendo:

BOB

BOBINIT

BOBPROC

BOBLOAD

BOBCFG

Mas isso simplesmente não existe.

Pelo menos não na arquitetura atual.


O Grande Engano

Nós, profissionais de mainframe, fomos treinados durante quarenta anos para acreditar que:

"Se executa alguma coisa...

ela deve morar em algum dataset."

É natural pensar assim.

O CICS mora em bibliotecas.

O DB2 mora em bibliotecas.

O IMS mora em bibliotecas.

O MQ mora em bibliotecas.

O RACF possui módulos.

O DFSORT possui módulos.

Até o ISPF possui bibliotecas.

Então...

onde mora Bob?

A resposta muda completamente nossa forma de pensar.



Bob não mora no z/OS

Bob é um serviço.

Mais precisamente,

um AI Software Engineer Service.

Ele vive em infraestrutura moderna.

Pode estar:

  • IBM Cloud

  • Linux

  • Kubernetes

  • OpenShift

  • LinuxONE

  • Cloud privada

  • Data Center corporativo

Mas normalmente

não dentro do Address Space do z/OS.


Pense no Banco de Dados

Imagine um programa COBOL.

READ CLIENTE

Os dados não estão no COBOL.

Estão no VSAM.

Agora imagine:

EXEC SQL
SELECT *
FROM CLIENTES

O DB2 não mora no COBOL.

Ele responde ao COBOL.

Bob faz exatamente isso.



O Novo Modelo Mental

Em vez disso,

pense assim.

                 IBM Bob

             AI Service

                 │

      HTTPS / MCP / APIs

                 │

      IBM Z Open Editor

                 │

          Seu Programa

                 │

              Mainframe

O Bob está do outro lado da conversa.


Quem faz a ponte?

Aqui entra um personagem novo.

O MCP.

Model Context Protocol.

Imagine o velho VTAM.

Ele ligava terminais.

O MCP liga Inteligências Artificiais.


Antes

3270

↓

VTAM

↓

CICS


Hoje

Bob

↓

MCP

↓

Git

↓

Filesystem

↓

Mainframe

↓

Cloud

↓

SQLite

↓

Appwrite

↓

GitHub

É o mesmo conceito.

Mudou apenas o protocolo.


O Investigador encontra uma pista

Sara abre o VS Code.

Existe um programa COBOL.

CLIENTE.CBL

Bob consegue explicar.

Grissom pergunta.

Como?

Será que Bob entrou no PDS?

Não.

Quem abriu o programa foi o editor.

O editor entregou o conteúdo ao Bob.


Quem entrega os COPYBOOKs?

Outra pergunta excelente.

Imagine.

COPY CLIENTE.

COPY CONTA.

COPY BMSMAP.

O editor conhece o projeto.

Ele resolve os COPYBOOKs.

Quando Bob precisa entender o código,

ele recebe esse contexto.

Não porque entrou no Mainframe.

Mas porque alguém lhe mostrou.


A mesma lógica vale para

  • JCL

  • PROC

  • SYSIN

  • SQL

  • REXX

  • CLIST

  • HLASM

Tudo depende do contexto entregue.



Então Bob nunca acessa o Mainframe?

Aí está o detalhe interessante.

Ele pode acessar.

Mas através de portas autorizadas.

Nunca "invadindo" o z/OS.

Por exemplo.


Caminho 1

VS Code

↓

Zowe Explorer

↓

z/OSMF

↓

REST

↓

Mainframe

Caminho 2

Bob

↓

MCP

↓

Git

↓

Pipeline

↓

DBB

↓

Mainframe

Caminho 3

Bob

↓

SSH

↓

USS

↓

Linux

Tudo depende da arquitetura.


LinuxONE entra na investigação

Agora a história fica muito mais interessante.

Imagine um datacenter IBM.

Rack

↓

IBM Z

+

LinuxONE

↓

Rede interna

↓

Storage

↓

OpenShift

O LinuxONE é um monstro.

Ele roda Linux.

Mas não é um Linux qualquer.

Ele compartilha muitas características do IBM Z.

Alta disponibilidade.

Segurança.

Virtualização.

Criptografia.

Escalabilidade absurda.


E se Bob morasse no LinuxONE?

Agora estamos falando.

Imagine.

LinuxONE

↓

OpenShift

↓

Container

↓

IBM Bob

Esse cenário faz muito sentido.

Porque:

  • baixa latência

  • segurança

  • sem sair do datacenter

  • integração corporativa


Bob e OpenShift

Imagine.

Pod

↓

IBM Bob

↓

MCP Server

↓

REST APIs

Tudo rodando localmente.

O Mainframe conversa pela rede interna.

Muito parecido com:

CICS

↓

MQ

↓

Application Server


O papel do Telum

Agora entra outro personagem.

Telum.

O processador do IBM Z.

Muita gente pensa:

"O Telum roda Bob."

Não exatamente.


O que Telum realmente faz?

Telum possui IA embarcada.

Mas ela foi criada para inferência transacional.

Exemplo.

Fraude bancária.

Cartão de crédito.

Detecção de risco.

Scoring.

Machine Learning.

Tudo isso acontece durante a própria transação.


Imagine.

Cliente compra.

↓

CICS.

↓

COBOL.

↓

DB2.

↓

Telum AI.

↓

Fraude detectada.

↓

Autoriza.

↓

Resposta.

Tudo em poucos milissegundos.


Então Bob usa Telum?

Hoje,

não diretamente.

Bob é um agente.

Telum é um acelerador de IA.

São papéis diferentes.

É como comparar.

Compilador COBOL

e

CPU

O compilador usa a CPU.

Mas não mora nela.


Poderia usar?

Perfeitamente.

Imagine uma arquitetura futura.

IBM Bob

↓

LLM

↓

Agente

↓

Inferência Telum

↓

Mainframe

Algumas decisões poderiam ser aceleradas pelo hardware.


O Grande Sonho do Sysprog

Agora imagine uma empresa.

Tudo dentro do próprio datacenter.

                  Firewall

                     │

────────────────────────────────────

             IBM Z

────────────────────────────────────

       z/OS

         │

    z/OSMF

         │

    REST APIs

────────────────────────────────────

     LinuxONE

────────────────────────────────────

 OpenShift Cluster

      │

 IBM Bob

 MCP Server

 Vector Database

 Granite LLM

 watsonx

────────────────────────────────────

      Storage

────────────────────────────────────

Observe.

Bob continua não morando no z/OS.

Mas mora ao lado.

Dentro da mesma empresa.


Como um Sysprog enxergaria isso?

Algo parecido com:

Users

↓

VS Code

↓

Bob

↓

MCP

↓

z/OSMF

↓

RACF

↓

Datasets

↓

JES2

↓

CICS

↓

DB2

Cada camada conversa apenas com a seguinte.


O papel do RACF

Outra pergunta importante.

Bob pode ler qualquer dataset?

Não.

Quem manda continua sendo o RACF.

Imagine.

USER

↓

RACF

↓

Permissão

↓

Dataset

Bob nunca deveria ultrapassar essas permissões.

Ele atua com as credenciais autorizadas.


E o Sysadmin?

O Sysadmin enxerga diferente.

Ele pensa.

CPU.

Containers.

Pods.

TLS.

Certificados.

Load Balancer.

Storage.

OpenShift.

Logs.

Monitoramento.

Prometheus.

Grafana.

Para ele,

Bob é apenas mais um serviço corporativo.


O Sysprog pensa diferente

Ele pensa.

SYS1.PARMLIB

LPAR

SMF

RMF

APF

LINKLIST

JES

RACF

WLM

Por isso existe a confusão.

Bob pertence mais ao universo DevOps do que ao universo clássico do z/OS.


E se IBM decidisse integrar tudo?

Agora começa a ficção científica.

Imagine.

IBM.BOB.STC

Started Task.

BOBPROC

PROC.

SYS1.BOBLIB

Biblioteca.

BOBCFG

Parâmetros.

BOBMCP

Servidor.

Tudo hospedado em USS.

Não é impossível.

Na verdade,

USS já permite executar aplicações Linux-like dentro do z/OS.

Poderíamos imaginar:

USS

↓

Container

↓

Granite

↓

MCP

↓

Bob

Embora hoje esse não seja o modelo oficial.


Easter Egg nº 1

Lembra quando dizíamos:

"O Mainframe é um computador enorme."

Hoje essa definição está errada.

O IBM Z virou um grande orquestrador.

Ele conversa com:

  • Linux

  • Cloud

  • Kubernetes

  • APIs

  • IA

  • Containers

O computador deixou de ser uma ilha.


Easter Egg nº 2

Nos anos 1980 perguntávamos:

"Onde está o programa?"

Hoje perguntamos:

"Onde está o serviço?"

É uma mudança filosófica enorme.


Easter Egg nº 3

Daqui a alguns anos,

talvez um novo programador pergunte:

"Onde mora o Agente?"

E o Sysprog responderá:

"Não importa onde ele mora.

Importa apenas qual identidade RACF ele usa."


Veredito do CSI Las Vegas

Grissom fecha a pasta da investigação.

Na primeira página está escrito:

O Caso do Agente Fantasma

Conclusão:

O IBM Bob não desapareceu.

Nunca esteve escondido em uma SYS.BOB.LIB.

Nunca foi um módulo APF.

Nunca ocupou uma PDSE ao lado dos seus COPYBOOKs.

Ele representa uma nova geração de software: serviços inteligentes distribuídos, acessados por protocolos modernos e integrados ao ecossistema corporativo.

Para o programador COBOL, isso pode parecer estranho no início. Afinal, passamos décadas procurando tudo em bibliotecas, PROCs, LOADLIBs e datasets catalogados. Mas o mundo mudou.

Hoje, o código continua vivendo no z/OS. Os dados continuam protegidos pelo RACF. Os JOBs continuam passando pelo JES2. O CICS continua processando milhões de transações e o Db2 continua armazenando o coração do negócio.

A novidade é que surgiu um novo colega de equipe.

Ele não mora na estante das bibliotecas.

Ele mora na rede.

Pode estar em um cluster OpenShift sobre LinuxONE, em uma nuvem privada IBM, integrado ao watsonx e aos modelos Granite, conversando com o z/OS por z/OSMF, Zowe, MCP e APIs seguras.

É como um consultor extremamente experiente sentado do outro lado do vidro da sala de operações. Ele não toca diretamente nos datasets nem invade o sistema. Observa o contexto que você lhe fornece, analisa, sugere, documenta, revisa e acelera o trabalho.

Talvez essa seja a maior transformação desde o surgimento do CICS ou do Db2: o conhecimento deixou de estar preso a uma biblioteca física e passou a existir como um serviço inteligente, distribuído, colaborativo e conectado.

E quem sabe, daqui a alguns anos, ao abrir um console do z/OS, o Sysprog encontre finalmente aquele velho sonho realizado:

===> START BOB

IEF403I BOB - STARTED

IBM AI Software Engineer ready.

Waiting for next mission...

Nesse dia, provavelmente Grissom apenas sorriria e diria:

"O agente nunca esteve perdido. Nós é que estávamos procurando no lugar errado."

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, 2 de agosto de 2026

IBM Bob : O Holocron do Padawan — Da Primeira Pergunta até os Agentes Inteligentes

 

Bellacosa Mainframe e o holocron do conhecimento do ibm bob

☕ Um Café no Bellacosa Mainframe

IBM Bob para Programadores COBOL

O Holocron do Padawan — Da Primeira Pergunta até os Agentes Inteligentes

"Quando um programador COBOL encontra uma IA pela primeira vez, a tendência é pensar que ela escreve código. Depois de alguns dias percebe que ela faz muito mais. Depois de alguns meses percebe que quem realmente mudou foi a forma de pensar sobre desenvolvimento."


Durante décadas nós aprendemos uma sequência relativamente estável.

Requisito
↓
Análise
↓
Codificação
↓
Compilação
↓
Teste
↓
Produção

O IBM Bob não muda esse fluxo.

Ele muda quem participa dele.

O desenvolvedor deixa de trabalhar sozinho e passa a trabalhar acompanhado por uma IA especializada.

Essa é exatamente a ideia por trás de praticamente todas as fases do treinamento.



Capítulo 1 — O que é o IBM Bob?

O erro mais comum é pensar:

"Bob é um ChatGPT."

Não.

Bob é um AI Software Engineer.

Ele foi construído para acompanhar todo o ciclo de vida do software (SDLC).

Ele entende:

  • código

  • arquitetura

  • documentação

  • Git

  • Pull Request

  • testes

  • APIs

  • banco de dados

  • DevOps

  • Cloud

  • Mainframe

Ele não responde apenas perguntas.

Ele participa do desenvolvimento.



Capítulo 2 — O verdadeiro SDLC

Praticamente em vários momentos do curso falam do SDLC.

A ordem correta é:

Planejamento

↓

Levantamento de requisitos

↓

Análise

↓

Design

↓

Implementação

↓

Testes

↓

Deploy

↓

Manutenção

Nunca confunda.

Os testes nunca vêm antes dos requisitos.


Planejamento

Aqui respondemos:

O que será construído?

Quem vai usar?

Qual problema resolve?


Requisitos

Aqui descobrimos:

  • regras de negócio

  • usuários

  • limitações

  • integrações

É exatamente como conversar com o cliente antes de escrever um COBOL.


Design

Aqui definimos

Arquitetura.

Tecnologias.

Banco.

API.

Cloud.

Infraestrutura.

É a planta da casa.


Implementação

Aqui escrevemos código.

COBOL.

Java.

Python.

TypeScript.

Não importa.

O design vira código.


Testes

Somente agora validamos.

Não antes.


Capítulo 3 — Contexto é Rei

Uma das maiores mensagens do curso.

IA sem contexto é praticamente inútil.

Imagine perguntar:

Melhore esse programa.

Qual programa?

Qual arquivo?

Qual função?

Qual objetivo?

Agora compare com:

Arquivo:

CLIENTE.CBL

Objetivo:

Melhorar performance da leitura VSAM.

Não alterar layout.

Não modificar regras fiscais.

Não instalar bibliotecas.

Agora Bob entende.

Toda IA funciona melhor quando recebe contexto.



Capítulo 4 — Janela de Contexto

Outro assunto recorrente.

A Janela de Contexto é simplesmente tudo aquilo que Bob conhece naquele momento.

Ela contém:

  • conversa

  • arquivos

  • regras

  • prompts

  • histórico

  • documentos

Quanto maior o contexto útil,

melhor a resposta.

Quanto maior o contexto inútil,

pior a resposta.


Context Poisoning

Uma expressão importante.

Imagine manter aberto:

Projeto Banco A.

Depois mudar para

Projeto Banco B.

Mas esquecer documentos antigos.

Bob pode misturar regras.

Isso chama-se

Context Poisoning.

A IA passa a raciocinar baseada em informações erradas.



Capítulo 5 — Human in the Loop

Talvez seja o conceito mais importante do treinamento.

Bob nunca substitui o desenvolvedor.

Ele trabalha junto.

Você continua responsável por:

✔ validar

✔ revisar

✔ aprovar

✔ decidir

A IA sugere.

Você decide.


Capítulo 6 — Auto Approve

Bob pode executar ações automaticamente.

Mas existem níveis.

Exemplo:

Leitura

Pode abrir arquivos.

Pode listar diretórios.

Sem perguntar.

Já comandos perigosos

como

git reset

rm

git push

normalmente pedem confirmação.

Por quê?

Porque alterar um repositório é diferente de apenas ler um arquivo.


Capítulo 7 — Checkpoints

O que faz um checkpoint? Muitas vezes usamos o conceito mas não paramos para analisar e fazer um mapa mental.

Checkpoint significa:

Criar um ponto seguro.

Igual snapshot.

Antes de uma grande mudança:

✔ cria checkpoint

✔ modifica

✔ testa

✔ aprova

É exatamente igual ao conceito de backup antes de um grande IPL.



Capítulo 8 — Bob Rules

Aqui está um conceito excelente.

Imagine um programador COBOL.

Toda vez você escreve:

Sempre documente.

Nunca use GO TO.

Explique em português.

Isso é repetitivo.

As Bob Rules resolvem isso.

São regras permanentes.

Exemplo:

Sempre gerar comentários.

Nunca instalar dependências.

Usar Clean Code.

Elas ficam válidas para o projeto inteiro.



Capítulo 9 — Slash Commands

Enquanto Rules são permanentes,

Slash Commands são ações.

Exemplo:

/review

Revisar código.

/document

Gerar documentação.

/performance

Analisar desempenho.

São pequenas automações.


Capítulo 10 — agent.md

Uma excelente ideia.

O arquivo

agent.md

é um manual para Bob.

Ele registra:

  • arquitetura

  • convenções

  • decisões

  • padrões

  • organização

É muito parecido com um grande README técnico.


Capítulo 11 — Git

O curso insiste bastante nisso.

Fluxo correto.

git checkout -b

↓

editar

↓

commit

↓

push

↓

Pull Request

↓

Review

↓

Merge

Jamais:

Editar diretamente a Main.


Pull Request

Não é apenas enviar código.

É pedir revisão.


Code Review

Serve para verificar

✔ qualidade

✔ documentação

✔ arquitetura

✔ padrões

✔ clareza

✔ links

✔ consistência

Não apenas bugs.



Capítulo 12 — MCP

Aqui começa o futuro.

Model Context Protocol.

Imagine um cabo USB.

Você conecta:

Bob

Git

SQLite

Appwrite

GitHub

Filesystem

Terminal

APIs

Tudo usando um padrão.

Esse padrão chama-se MCP.


MCP Local

Vale apenas para um projeto.


MCP Global

Vale para todos.


MCP Remoto

Permite conversar com serviços externos.

Exemplo:

Appwrite.


API Keys

Sem credenciais

Bob não entra.

Assim como RACF protege um dataset,

API Keys protegem serviços Cloud.



Capítulo 13 — LLM

Outra sequência cobrada.

LLM

↓

Chatbot

↓

Copilot

↓

Agente

LLM

Motor.


Chatbot

Conversa.


Copilot

Ajuda.


Agente

Executa.

Planeja.

Decide.

Corrige.



Capítulo 14 — Sistemas Agentic

Agente faz muito mais.

Ele consegue:

Planejar.

Executar.

Reavaliar.

Corrigir.

Continuar.

Esse conceito aparece sempre que usamos um chat bot, seria o nosso passo a passo na execução da tarefa.


Multistep

Executa várias etapas.

Não apenas uma.


Self Correction

Errou?

Corrige sozinho.


Human in the Loop

Mesmo assim,

o desenvolvedor continua aprovando.



Capítulo 15 — Analytics

Outro bloco do curso.

Bob Analytics mostra:

Consumo.

Bob Coins.

Plano.

Uso.

Métricas.


Bob Coins

Padronizam consumo.

Não importa qual modelo está por trás.


Trial

Temporário.


PRO

Renova Bob Coins mensalmente.


Overage

Uma pegadinha da prova.

No treinamento foi enfatizado que:

o overage precisa ser reativado manualmente a cada mês para continuar em uso.

Mesmo que essa característica possa variar entre serviços, essa é a resposta esperada no contexto da aula.



Capítulo 16 — O Grande Mapa Mental

Cliente

↓

Requisitos

↓

Design

↓

Bob entende contexto

↓

Rules

↓

Slash Commands

↓

agent.md

↓

Checkpoint

↓

Implementação

↓

Git

↓

Commit

↓

Push

↓

Pull Request

↓

Review

↓

Merge

↓

Deploy

↓

Analytics

↓

Melhoria Contínua


O Pensamento Bellacosa Mainframe

Quando comecei no mainframe, lá no final dos anos 1980, a inteligência estava concentrada em dois lugares: na cabeça do analista experiente e nos milhares de programas COBOL que sustentavam o negócio. Hoje, continuamos precisando dessa experiência, mas ganhamos um novo parceiro.

O IBM Bob não substitui o programador COBOL. Ele não conhece melhor o negócio do que quem mantém aquele sistema há anos. O que ele faz é acelerar tarefas repetitivas, organizar informações, sugerir melhorias e reduzir o tempo gasto com atividades mecânicas.

Pense nele como um novo integrante da equipe. Ele trabalha rápido, lê milhares de arquivos em segundos e nunca se cansa de revisar código. Porém, ainda depende do arquiteto, do analista e do desenvolvedor para definir o rumo correto.

No fim das contas, a principal lição de todo esse treinamento não é aprender comandos, MCPs ou Bob Rules. É compreender uma nova forma de desenvolver software:

A IA executa. O desenvolvedor direciona. A experiência humana continua sendo o verdadeiro sistema operacional por trás de qualquer projeto.

Esse é o verdadeiro espírito do Bellacosa Mainframe: combinar décadas de conhecimento em engenharia de software com as novas capacidades da Inteligência Artificial, formando um desenvolvedor que entende tanto o legado quanto o futuro.

sábado, 1 de agosto de 2026

IBM BOB — O Companheiro de Bordo do Desenvolvedor Moderno

 

Bellacosa Mainframe e uma visão introdutoria no ibm ia bob

☕ Um Café no Bellacosa Mainframe

IBM BOB — O Companheiro de Bordo do Desenvolvedor Moderno

Quando a Inteligência Artificial finalmente aprendeu a conversar com o Programador COBOL

"Todo padawan precisa de um mestre. Às vezes esse mestre veste um manto. Outras vezes... responde em linguagem natural e ajuda a escrever código."


Introdução

Durante décadas, o desenvolvimento em IBM Z parecia uma arte secreta.

Os conhecimentos eram transmitidos de um programador experiente para outro, quase como antigos mestres Jedi passando seus holocrons.

Quem começava aprendia observando.

Depois copiava JCLs.

Depois copiava programas COBOL.

Depois aprendia por que aquela instrução existia.

Depois descobria que ninguém mais lembrava.

Foi assim por mais de cinquenta anos.

Então chegou a Inteligência Artificial.

Mas não aquela IA dos filmes que domina o mundo.

Nem aquela que escreve poesia.

Nem aquela que desenha gatos astronautas.

A IBM resolveu criar algo diferente.

Criou uma IA voltada para empresas.

Uma IA treinada para compreender documentação técnica.

Uma IA capaz de ajudar desenvolvedores.

Uma IA que entende infraestrutura corporativa.

Uma IA que conversa sobre APIs, COBOL, Java, Linux, Cloud, DevOps, Watsonx, OpenShift e IBM Z.

Essa IA recebeu um nome curioso.

IBM BOB.


Afinal...

O que é o IBM BOB?

BOB é o assistente de Inteligência Artificial corporativo da IBM.

Pense nele como um colega extremamente paciente.

Ele nunca reclama.

Nunca diz:

"Leia a documentação."

Ao contrário.

Ele lê a documentação por você.

Explica.

Resume.

Sugere.

Cria exemplos.

Ajuda a escrever código.

Explica mensagens de erro.

Traduz conceitos difíceis.

Auxilia arquitetos.

Auxilia desenvolvedores.

Auxilia administradores.

Auxilia alunos.

É praticamente um copiloto especializado no universo IBM.


Por que o nome "BOB"?

A IBM nunca tratou o nome apenas como uma sigla técnica.

O objetivo sempre foi dar ao assistente uma identidade simples, amigável e fácil de lembrar.

Curiosamente, "Bob" é um dos nomes mais comuns do idioma inglês.

Não intimida.

Não parece um robô.

Parece um colega de equipe.

E essa é justamente a proposta.

Não substituir pessoas.

Mas trabalhar junto delas.


Como nasceu essa ideia?

Durante muitos anos a IBM produziu milhares de páginas de documentação.

Imagine apenas:

  • z/OS

  • CICS

  • IMS

  • Db2

  • RACF

  • MQ

  • WebSphere

  • OpenShift

  • LinuxONE

  • Power

  • Storage

  • Cloud Pak

  • Watsonx

São milhões de linhas de documentação.

Nenhum ser humano consegue decorar tudo.

Mesmo especialistas vivem pesquisando.

A IBM percebeu algo importante.

O problema não era falta de informação.

Era excesso dela.

Assim surgiu a ideia:

"E se a documentação pudesse conversar?"

Essa pergunta mudou tudo.


A evolução da IA na IBM

Antes do BOB vieram muitos projetos importantes.

Década de 1990:

Especialistas começaram a estudar sistemas inteligentes.

Anos 2000:

Chegaram mecanismos de busca corporativos.

Depois vieram sistemas especialistas.

Então surgiu um projeto famoso.

Watson.


Watson mudou tudo

Em 2011 o IBM Watson venceu o programa Jeopardy.

Foi um marco histórico.

Pela primeira vez uma IA compreendia perguntas feitas em linguagem natural.

Ela precisava interpretar:

  • contexto

  • ambiguidades

  • referências

  • significado

Era muito diferente de apenas pesquisar palavras.

Foi ali que nasceu boa parte da tecnologia usada anos depois.


Depois veio a IA Generativa

Com os grandes modelos de linguagem, tudo acelerou.

A IBM lançou a plataforma:

watsonx

Ela reúne:

  • modelos de IA

  • treinamento

  • governança

  • segurança

  • IA corporativa

BOB nasceu justamente dentro dessa nova geração.


O grande diferencial

Existem muitas IAs.

Mas poucas entendem o mundo corporativo.

BOB foi criado pensando em empresas.

Ele entende:

  • documentação IBM

  • arquitetura

  • APIs

  • infraestrutura

  • padrões

  • segurança

  • desenvolvimento

Ele evita inventar respostas quando não possui contexto suficiente.

Essa característica é fundamental em ambientes corporativos.


Para que serve?

Imagine seu primeiro dia trabalhando em um banco.

Seu líder diz:

"Precisamos alterar um programa COBOL."

Você abre um programa com 18 mil linhas.

Existem:

  • COPYBOOKS

  • SQL

  • CICS

  • VSAM

  • MQ

  • dezenas de PERFORM

  • centenas de variáveis

Você pensa:

"Por onde começo?"

BOB ajuda exatamente nisso.


Exemplos do dia a dia

Entender um programa COBOL

Você pergunta:

Explique este PERFORM.

Ele explica.


Criar documentação

Pode transformar comentários técnicos em documentação.


Gerar exemplos

Pode criar programas exemplo.


Aprender comandos

Pergunte:

"Como funciona SORT FIELDS?"

Ele explica.


Entender mensagens

Recebeu um ABEND?

Cole a mensagem.

BOB explica.


Aprender APIs

Peça um exemplo REST.


Explicar JCL

Mostra cada DD.

Cada DISP.

Cada SPACE.

Cada UNIT.


Traduzir documentação

Boa parte da documentação IBM está em inglês.

BOB ajuda a interpretar rapidamente.


Um exemplo prático

Imagine um padawan.

Ele recebe:

IF SALDO > LIMITE
    MOVE "S" TO APROVADO
ELSE
    MOVE "N" TO APROVADO
END-IF

Ele pergunta:

Explique linha por linha.

BOB responde detalhadamente.

Agora imagine um código com 4 mil linhas.

O princípio é o mesmo.


Um exemplo ainda melhor

Imagine um JCL.

//STEP01 EXEC PGM=SORT

Pergunte:

"O que faz?"

Ele responde.

Depois:

"O que significa EXEC?"

Depois:

"O que significa PGM?"

Depois:

"Como funciona SORT?"

Você transforma um JCL inteiro em uma aula.


BOB não é apenas para COBOL

Ele auxilia em:

  • Java

  • Python

  • C#

  • Go

  • JavaScript

  • Terraform

  • Kubernetes

  • Linux

  • OpenShift

  • Git

  • GitHub

  • Jenkins

  • DevOps

E naturalmente...

IBM Z.


Primeiros passos para um Padawan COBOL

Aqui começa a aventura.

Passo 1

Não peça código.

Peça explicações.

Isso desenvolve raciocínio.


Passo 2

Mostre pequenos programas.

Nunca envie milhares de linhas inicialmente.


Passo 3

Pergunte:

"O que esta variável representa?"


Passo 4

Depois pergunte:

"Como melhorar?"


Passo 5

Só então peça exemplos.


Uma rotina interessante

Imagine estudar uma hora.

30 minutos:

Leia o material IBM.

30 minutos:

Converse com BOB.

Esse ciclo acelera absurdamente o aprendizado.


O que um desenvolvedor experiente faz?

Curiosamente...

Ele usa BOB de maneira diferente.

Não pergunta:

"Como escrever COBOL?"

Pergunta:

"Existe uma forma mais elegante?"

ou

"Há algum risco de performance?"

ou

"Existe um padrão mais moderno?"

A IA vira um segundo par de olhos.


Um paralelo com Star Wars

Luke possuía R2-D2.

Anakin tinha C-3PO.

Os pilotos tinham seus computadores de bordo.

No mundo IBM...

BOB cumpre um papel parecido.

Ele não pilota sua nave.

Mas ajuda durante toda a missão.


Curiosidades

Pouca gente percebe algumas coisas interessantes.

Curiosidade 1

BOB conversa em linguagem natural.

Você não precisa decorar comandos.


Curiosidade 2

Ele entende perguntas incompletas.

Como:

"Explique este JCL."


Curiosidade 3

Ele pode resumir documentações enormes.


Curiosidade 4

Ele reduz bastante o tempo gasto procurando informações.


Curiosidade 5

Ele funciona melhor quando recebe contexto.

Quanto melhor sua pergunta...

Melhor a resposta.


O segredo está no Prompt

Existe um velho ditado da programação.

Garbage In, Garbage Out.

Na IA vale exatamente a mesma regra.

Pergunta ruim.

Resposta ruim.

Pergunta excelente.

Resposta excelente.


Easter Egg 1

No universo Star Wars existiam Holocrons.

No mundo IBM...

A documentação técnica sempre foi o Holocron dos administradores de sistema.

BOB é quase um tradutor desses holocrons.


Easter Egg 2

Nos anos 70 existia um "BOB".

Só que era diferente.

Era aquele colega veterano que sabia tudo.

Ninguém sabia onde ele aprendia.

Mas quando havia um ABEND impossível...

Chamavam o Bob.

Décadas depois...

Agora existe outro Bob.

Só que digital.


Easter Egg 3

Programadores COBOL sempre tiveram fama de decorar códigos de erro.

Hoje não precisam decorar tanto.

Precisam entender.

BOB ajuda justamente nisso.


Easter Egg 4

Existe uma ironia interessante.

Durante décadas diziam:

"O COBOL vai desaparecer."

Hoje uma das áreas onde IA mais cresce é justamente ajudando empresas que possuem milhões de linhas de COBOL.

A história deu uma enorme volta.


O que BOB não faz?

Ele não substitui experiência.

Não conhece automaticamente todas as regras de negócio da sua empresa.

Não entende processos internos sem contexto.

Não aprova mudanças.

Não faz code review definitivo.

Ele auxilia.

A decisão continua sendo humana.


O futuro

Tudo indica que assistentes como o BOB serão cada vez mais integrados às ferramentas de desenvolvimento.

Imagine abrir o VS Code ou o IBM Z Open Editor e conversar com a IA enquanto programa, recebendo explicações, sugestões de testes, análise de impacto e ajuda para navegar por sistemas legados. Em vez de alternar entre dezenas de abas de documentação, o conhecimento chega diretamente ao ambiente de trabalho.

Para quem desenvolve em COBOL, isso representa uma mudança importante: o tempo gasto procurando respostas diminui, enquanto o tempo dedicado a compreender o negócio e criar soluções aumenta.


Conclusão

Se há alguns anos o maior patrimônio de uma equipe era o veterano que conhecia cada detalhe do sistema, hoje esse conhecimento pode ser ampliado por assistentes de IA como o IBM BOB. Isso não reduz o valor do profissional; pelo contrário, torna sua experiência ainda mais estratégica, permitindo que tarefas repetitivas sejam aceleradas e que o foco esteja naquilo que realmente importa: resolver problemas de negócio com qualidade.

Para o padawan COBOL, BOB não é um atalho para evitar estudar. É um mentor digital que responde perguntas, sugere caminhos e ajuda a interpretar décadas de conhecimento acumulado pela IBM. Quanto mais você aprende, melhores ficam suas perguntas — e melhores ficam as respostas.

Como diria o Bellacosa Mainframe, enquanto serve mais uma caneca de café:

"O verdadeiro mestre não é aquele que sabe todas as respostas. É aquele que aprendeu a fazer as perguntas certas. O IBM BOB pode responder muitas delas, mas a curiosidade continua sendo o compilador mais poderoso de qualquer programador."

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