Translate

Mostrar mensagens com a etiqueta cobol. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta cobol. 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, 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."

sexta-feira, 31 de julho de 2026

👋 Boas-vindas ao IBM Bob Bootcamp

 

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

👋 Boas-vindas ao IBM Bob Bootcamp

IA de Nível Empresarial para Desenvolvedores e Tech Leaders

Olá, pessoal!

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

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

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

"Posso ajudar no seu código?"

A resposta, obviamente, foi:

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



Afinal... o que estamos fazendo aqui?

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

É ferramenta.

É produtividade.

É aceleração.

É uma nova forma de pensar soluções.

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

"Vou usar IA?"

e passou a ser

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


Um recado para quem vem do Mainframe

Eu sou suspeito para falar...

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

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

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

Então, quando alguém pergunta:

"Mainframe combina com Inteligência Artificial?"

Minha resposta é sempre:

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

Ou seja...

É praticamente obrigatório. ☕😂

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


Minha expectativa

Espero aprender muito com todos vocês.

Cada participante chega com experiências diferentes.

Uns dominam Cloud.

Outros conhecem Kubernetes.

Alguns vivem em Java, Python ou JavaScript.

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

No fim das contas...

Todos estamos aprendendo a conversar com uma nova ferramenta.

E isso é fantástico.


Minha filosofia

Sempre gostei de uma frase simples:

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

Então contem comigo durante o Bootcamp.

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



Um pequeno aviso (com humor Bellacosa)

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

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

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

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

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

...não se preocupe.

É perfeitamente normal.

Os efeitos costumam ser irreversíveis. 😄



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

Boa sorte a todos!

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

Como diria o Bellacosa Mainframe:

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

Nos vemos durante o Bootcamp!

☕🤖🚀

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

 

Bellacosa Mainframe do Html ao IBM Z uma jornada classica do Heroi

☕ Um Café no Bellacosa Mainframe

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

"Durante muitos anos acreditamos que existiam dois mundos completamente diferentes. De um lado, o navegador. Do outro, o mainframe. Hoje sabemos que eles nunca estiveram tão próximos."


Existe uma cena curiosa que provavelmente todo programador COBOL já viveu.

Você está trabalhando em um programa CICS há horas. Ajusta um COMMAREA, altera uma consulta DB2, recompila, faz o BIND, libera para homologação e, de repente, alguém da equipe Web aparece com uma pergunta aparentemente inocente:

"Você consegue disponibilizar isso numa API REST?"

Há alguns anos essa pergunta soaria quase como magia.

Hoje ela faz parte do cotidiano.

Foi justamente para reduzir essa distância que nasceu o APPDEV 33 – Introduction to Web Development – Part 2, expandindo os conceitos apresentados na Parte 1 e mostrando que HTML, CSS e JavaScript não competem com COBOL. Eles trabalham juntos.

Na verdade...

Eles dependem um do outro.



A grande mudança silenciosa

Existe uma falsa impressão de que o desenvolvimento Web pertence apenas ao universo JavaScript.

Não pertence.

Da mesma forma que existe a falsa impressão de que o Mainframe termina na tela verde.

Também não termina.

O navegador moderno tornou-se apenas mais um terminal.

Só que muito mais bonito.

Muito mais amigável.

Muito mais inteligente.

E atrás dele continua existindo aquilo que sempre sustentou bancos, seguradoras, governos, companhias aéreas e bolsas de valores:

IBM Z.


O que aprendemos na Parte 1

Na primeira parte aprendemos três pilares fundamentais.

HTML

A estrutura.

Assim como uma BMS MAP define onde cada campo aparecerá na tela 3270, o HTML define onde cada elemento será exibido dentro da página.

É o esqueleto.


CSS

A aparência.

Se na BMS alterávamos atributos como intensidade, cor, proteção e brilho, no navegador fazemos praticamente a mesma coisa utilizando CSS.

Mudam os nomes.

O conceito continua.


JavaScript

O comportamento.

Enquanto COBOL executa regras de negócio no servidor, JavaScript controla a experiência do usuário no navegador.

Ele responde cliques.

Atualiza informações.

Valida formulários.

Move elementos.

Sem precisar recarregar toda a página.


A analogia perfeita

Mundo WebMundo Mainframe
HTMLBMS MAP
CSSAtributos da Tela
JavaScriptInterface
COBOLRegras de Negócio

Quando essa tabela aparece pela primeira vez, muita gente faz exatamente a mesma expressão:

"Ahhh... agora fez sentido."



O navegador é apenas o começo

Quando digitamos:

https://empresa.com

Nossa mente costuma imaginar algo simples.

Mas, nos bastidores, ocorre uma verdadeira corrida de revezamento.

Usuário

↓

Browser

↓

Servidor Web

↓

HTML

↓

CSS

↓

JavaScript

↓

Página pronta

↓

REST API

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta

Observe algo interessante.

O navegador praticamente nunca conversa diretamente com o COBOL.

Existe uma camada intermediária.

E isso é excelente.


O guardião entre dois mundos

No ecossistema IBM Z moderno existe um verdadeiro tradutor universal.

z/OS Connect.

Ele recebe chamadas REST.

Converte JSON.

Invoca programas COBOL.

Executa CICS.

Consulta DB2.

Retorna novamente JSON.

Tudo isso escondendo completamente a complexidade do ambiente z/OS.

É quase como um intérprete simultâneo durante uma conferência internacional.

Cada lado continua falando sua própria língua.

Mas todos passam a se entender.


HTML deixou de ser apenas marcação

Quem aprendeu HTML há quinze anos provavelmente conheceu algo parecido com isto.

<div>
<div>
<div>

Funcionava.

Mas era praticamente impossível descobrir o significado daquela estrutura.

Então surgiu o HTML Semântico.

Agora passamos a utilizar elementos como:

<header>

<nav>

<main>

<section>

<article>

<footer>

Essas palavras possuem significado.

E significado muda tudo.

Motores de busca entendem melhor o conteúdo.

Leitores de tela conseguem navegar corretamente.

Ferramentas de Inteligência Artificial interpretam o contexto.

Até os próximos programadores agradecem.

Porque finalmente conseguem entender a organização da página.


CSS cresceu

Durante muito tempo criar layouts era uma atividade quase artesanal.

Tabelas.

Float.

Clear.

Margens.

Gambiarras.

Então surgiu o Flexbox.

De repente bastava escrever poucas linhas.

display:flex;

justify-content:space-between;

align-items:center;

Como mágica.

Tudo se alinhava.

Responsivamente.

Sem sofrimento.

Depois veio o CSS Grid.

E aí o navegador finalmente ganhou um verdadeiro sistema de layout bidimensional.

Header.

Menu.

Conteúdo.

Rodapé.

Tudo organizado como uma planta arquitetônica.

Curiosamente...

É exatamente assim que pensamos quando desenhamos uma aplicação CICS.

Primeiro definimos a arquitetura.

Depois os componentes.

Depois o fluxo.


JavaScript finalmente ganhou vida

No início JavaScript apenas executava comandos.

Hoje ele reage.

Clique.

Teclado.

Mouse.

Touch.

Formulário.

Mudança de valor.

Tudo é evento.

Usuário

↓

Evento

↓

JavaScript

↓

Resposta

Essa simplicidade mudou completamente a experiência da Web.

Não precisamos mais atualizar páginas inteiras.

Alteramos apenas aquilo que realmente mudou.

Essa ideia parece moderna.

Mas, curiosamente, programadores CICS fazem algo parecido há décadas.

Atualizamos apenas determinados campos da tela.

Não a aplicação inteira.



DOM — A página deixa de ser estática

Imagine que exista uma árvore invisível.

Cada botão.

Cada texto.

Cada imagem.

Cada tabela.

Cada formulário.

Tudo faz parte dessa árvore.

Ela recebe um nome.

DOM — Document Object Model.

JavaScript pode caminhar por essa árvore.

Encontrar um elemento.

Alterar seu conteúdo.

Modificar sua aparência.

Inserir novos componentes.

Tudo instantaneamente.

Sem recarregar o navegador.

É isso que transforma páginas estáticas em aplicações.

Parte II : Quando o Navegador Conversa com o Mainframe

Na primeira parte da nossa conversa percebemos algo importante: HTML, CSS e JavaScript não substituem o COBOL. Eles apenas ocupam uma camada diferente da aplicação.

Agora vem a pergunta que todo programador COBOL faz quando termina de aprender os conceitos básicos.

"Tudo bem... mas como exatamente um clique no navegador consegue executar um programa COBOL dentro do IBM Z?"

É justamente aqui que começa a mágica.

Ou melhor...

A engenharia.



A viagem de um clique

Imagine que um cliente acessa o Internet Banking.

Ele vê um botão.

Consultar Saldo

Aparentemente ele apenas clicou.

Mas esse clique inicia uma longa viagem.

Clique

↓

JavaScript

↓

REST API

↓

JSON

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

DB2

↓

Resposta

↓

JSON

↓

JavaScript

↓

Atualização da Tela

Em menos de um segundo tudo isso aconteceu.

Sem o usuário perceber.

Se o sistema estiver rodando em IBM Z, provavelmente essa operação ocorreu em alguns poucos milissegundos.



REST API — A língua franca da Internet

Há vinte anos cada sistema possuía seu próprio protocolo.

Cada fabricante inventava uma maneira diferente de trocar informações.

Era um verdadeiro caos.

REST mudou completamente esse cenário.

Hoje praticamente qualquer sistema consegue conversar com qualquer outro utilizando HTTP.

Isso significa que um navegador, um aplicativo Android, um iPhone, uma Smart TV ou até uma geladeira inteligente podem acessar exatamente a mesma API.

O IBM Z simplesmente tornou-se mais um participante dessa conversa.



JSON — O envelope que viaja pela Internet

Quando um navegador solicita informações, ele normalmente envia algo parecido com isto.

{
   "cliente":12345
}

Poucos milissegundos depois recebe algo semelhante.

{
   "nome":"Maria",
   "saldo":1250.90,
   "limite":5000
}

Isso é JSON.

Leve.

Organizado.

Fácil de interpretar.

Mas existe uma curiosidade.

O JSON praticamente nunca nasce no navegador.

Na maioria das aplicações corporativas ele foi produzido por um programa COBOL.

Ou seja...

Por trás daquele pequeno documento existe toda uma lógica construída durante décadas.



z/OS Connect — O tradutor universal

Imagine um diplomata durante uma reunião internacional.

Um participante fala japonês.

Outro fala português.

Outro inglês.

Outro espanhol.

Todos conseguem conversar porque existe um intérprete.

z/OS Connect faz exatamente esse papel.

Ele entende REST.

Entende HTTP.

Entende JSON.

Depois traduz tudo para o universo do IBM Z.

Do outro lado...

O programa COBOL continua exatamente igual.

Sem precisar conhecer HTML.

Sem conhecer JavaScript.

Sem conhecer navegador.

Ele apenas recebe parâmetros.

Processa.

Responde.

E volta ao trabalho.



CICS continua fazendo o que sempre fez

Muita gente acredita que REST substituiu CICS.

Na verdade aconteceu justamente o contrário.

REST fez ainda mais aplicações dependerem do CICS.

O fluxo normalmente é este.

Browser

↓

REST API

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

Observe que o CICS continua sendo o gerente das transações.

Ele controla segurança.

Sincronismo.

Rollback.

Commit.

Performance.

Disponibilidade.

Nada mudou.

Apenas surgiram novos clientes.

Antes eram terminais 3270.

Hoje são navegadores.



COBOL continua sendo o cérebro

Existe uma frase que gosto muito.

JavaScript encanta. COBOL decide.

É JavaScript quem anima a tela.

É JavaScript quem valida um campo.

É JavaScript quem muda uma cor.

Mas quem realmente decide se um empréstimo será aprovado?

Quem calcula juros?

Quem verifica limite de crédito?

Quem consulta regras fiscais?

Quem processa milhões de transações diariamente?

COBOL.

Sempre ele.

O navegador apenas apresenta o resultado.



DB2 continua guardando o tesouro

Toda aplicação precisa armazenar informações.

Clientes.

Contas.

Contratos.

Apólices.

Empréstimos.

Pedidos.

Cartões.

É aqui que entra o DB2.

O programa COBOL faz consultas.

Atualiza registros.

Executa commits.

Controla integridade.

Depois transforma essas informações em JSON.

E o navegador recebe tudo pronto.

Perceba algo interessante.

O navegador nunca conversa diretamente com o banco.

Isso seria extremamente perigoso.

Existe sempre uma camada intermediária protegendo os dados.



Organização faz diferença

Quando começamos nossos primeiros programas HTML normalmente criamos apenas um arquivo.

index.html

Pouco tempo depois aparecem outros.

style.css

app.js

logo.png

Mais tarde surgem dezenas.

Depois centenas.

É exatamente nesse momento que aprendemos a organizar projetos.

Projeto

│

├── index.html

├── css

├── js

├── images

├── api

Essa organização pode parecer apenas estética.

Não é.

Ela facilita manutenção.

Facilita testes.

Facilita integração contínua.

Facilita Git.

Facilita DevOps.

Curiosamente...

É exatamente o mesmo motivo pelo qual existem COPYBOOKS.



COPYBOOKS nasceram muito antes dos Frameworks

Muitos desenvolvedores Web acreditam que reutilização nasceu com Frameworks modernos.

Na verdade...

Programadores COBOL fazem isso desde os anos 60.

Sempre que escrevemos

COPY CLIENTE.

Estamos reutilizando componentes.

Assim como um projeto Web reutiliza:

componentes

bibliotecas

frameworks

módulos

Mudam os nomes.

O princípio continua exatamente igual.


Git mudou a forma de trabalhar

Durante décadas o controle de versões no Mainframe foi responsabilidade de ferramentas como:

  • Endevor

  • ISPW

  • Librarian

  • Panvalet

Hoje Git tornou-se praticamente obrigatório.

Não importa se o código está em Java.

Python.

COBOL.

REXX.

Assembler.

Todos podem viver no mesmo repositório.

E isso abriu uma porta enorme para DevOps.



DevOps aproximou dois mundos

Antigamente existia uma divisão muito clara.

O desenvolvedor escrevia código.

Outra equipe compilava.

Outra homologava.

Outra implantava.

Hoje pipelines fazem praticamente tudo isso automaticamente.

Commit

↓

Build

↓

Testes

↓

Análise

↓

Deploy

Essa automação não substitui o programador.

Ela elimina tarefas repetitivas.

E permite que ele invista tempo onde realmente faz diferença.

Criando soluções.

Não apertando botões.



O novo profissional IBM Z

Chegamos então ao ponto mais importante de toda esta formação.

O profissional IBM Z moderno não conhece apenas COBOL.

Ele entende a jornada completa.

COBOL

↓

JSON

↓

REST

↓

HTML

↓

CSS

↓

JavaScript

↓

Git

↓

DevOps

↓

Cloud

↓

IBM Z

Isso não significa abandonar o Mainframe.

Significa ampliar horizontes.

Quanto mais camadas você compreende, maior passa a ser seu valor dentro da organização.

Você deixa de ser apenas um programador COBOL.

Passa a ser alguém capaz de conversar com equipes Web, arquitetos de soluções, especialistas em APIs, profissionais DevOps e engenheiros de Cloud.

E isso muda completamente sua carreira.



☕ Um café antes de continuar...

Existe um detalhe curioso que costuma passar despercebido.

Durante décadas ouvimos que "o futuro substituiria o Mainframe".

Mas aconteceu exatamente o contrário.

Foi o Mainframe que aprendeu a conversar com o futuro.

Hoje ele fala REST, entende JSON, integra-se com Cloud, participa de pipelines DevOps, conversa com aplicações móveis e continua executando, silenciosamente, bilhões de transações por dia.

Talvez essa seja a maior lição desta formação.

O IBM Z nunca ficou parado. Nós é que demoramos para perceber o quanto ele evoluiu.

Parte III — O Desenvolvedor IBM Z Moderno e o Futuro que Já Chegou

"O melhor momento para aprender HTML foi quando surgiu. O segundo melhor momento é hoje. Porque o IBM Z já está esperando por você."

Depois de percorrer toda a jornada desta formação, uma pergunta inevitavelmente aparece.

"O que devo aprender agora?"

Essa talvez seja a maior ansiedade de quem vem do mundo COBOL.

São tantas tecnologias...

HTML.

CSS.

JavaScript.

Git.

REST.

JSON.

Cloud.

DevOps.

Containers.

Docker.

Kubernetes.

OpenShift.

Inteligência Artificial.

À primeira vista parece impossível.

Mas existe uma boa notícia.

Você não precisa aprender tudo de uma vez.

Muito menos abandonar o conhecimento acumulado durante anos.

Na verdade, você já possui aquilo que a maioria dos desenvolvedores modernos ainda está tentando adquirir.

Conhecimento de negócio.

E isso vale ouro.


A árvore do conhecimento

Durante a apresentação utilizamos uma imagem bastante simbólica.

Uma árvore.

À primeira vista ela parece apenas um desenho bonito.

Mas existe um significado escondido.

As raízes

São invisíveis.

Pouca gente presta atenção nelas.

Mas sustentam tudo.

No IBM Z elas representam:

  • COBOL

  • JCL

  • CICS

  • DB2

  • VSAM

  • RACF

  • TSO/ISPF

Curiosamente...

São justamente as tecnologias que mais movimentam dinheiro no planeta.

Ninguém faz propaganda delas.

Mas bilhões de transações acontecem todos os dias graças a elas.


O tronco

O tronco representa aquilo que conecta todas as áreas.

Na nossa metáfora...

É o próprio IBM z17.

Não apenas como computador.

Mas como plataforma.

Segura.

Disponível.

Escalável.

Resiliente.

Enquanto centenas de tecnologias aparecem e desaparecem ao longo das décadas...

O IBM Z continua crescendo.


Os galhos

É onde surgem as novidades.

HTML.

CSS.

JavaScript.

REST.

JSON.

Git.

Cloud.

DevOps.

IA.

Todos eles crescem apoiados nas raízes.

Sem elas...

A árvore não existe.


O roadmap de evolução

Ao longo da apresentação surgiu uma estrada colorida.

Ela representa algo muito importante.

Você não aprende tudo ao mesmo tempo.

Você sobe um degrau por vez.

Primeiro passo

HTML.

Aprenda estrutura.

Nada além disso.

Não tente decorar centenas de elementos.

Entenda a lógica.


Segundo passo

CSS.

Faça páginas bonitas.

Aprenda cores.

Espaçamento.

Layouts.

Responsividade.

Não é preciso virar designer.

Apenas tornar a informação agradável.


Terceiro passo

JavaScript.

Agora a página ganha vida.

Botões passam a funcionar.

Campos são validados.

Elementos aparecem.

Desaparecem.

Mudam dinamicamente.

É nesse momento que muitos programadores COBOL começam a sorrir.

Porque finalmente enxergam lógica de programação novamente.


Quarto passo

REST.

Agora você entende que aplicações conversam.

E que praticamente toda integração moderna utiliza APIs.


Quinto passo

JSON.

Descobre que arquivos gigantes de integração deram lugar a pequenos documentos extremamente simples.


Sexto passo

Git.

Talvez seja a ferramenta que mais muda a maneira de trabalhar.

Commits.

Branches.

Merge.

Pull Request.

Code Review.

Tudo passa a fazer parte da rotina.


Sétimo passo

DevOps.

Agora o código não vive mais sozinho.

Ele entra em pipelines.

Executa testes.

É compilado automaticamente.

Implantado.

Monitorado.

Tudo praticamente sem intervenção humana.


Oitavo passo

Cloud.

Você percebe que Cloud não substituiu o Mainframe.

Ela apenas adicionou mais um ambiente de execução.

Na prática...

Os dois trabalham juntos.


Nono passo

Inteligência Artificial.

Chegamos ao presente.

Mas cuidado.

Existe um enorme equívoco acontecendo.

A IA não substitui conhecimento.

Ela acelera conhecimento.

Quanto mais experiência possui o profissional...

Melhores perguntas ele faz.

Melhores respostas recebe.


Um pequeno segredo da IBM

Existe uma curiosidade interessante.

Durante muitos anos, aprender IBM significava decorar comandos.

Hoje não.

A IBM mudou completamente sua estratégia.

Ela deseja profissionais capazes de integrar tecnologias.

É exatamente por isso que vemos cada vez mais cursos envolvendo:

  • Git

  • APIs

  • HTML

  • JavaScript

  • OpenShift

  • Red Hat

  • Linux

  • Python

  • DevOps

  • IA

Tudo convivendo naturalmente com COBOL.


Easter Egg nº 1 — O retorno da BMS

Você provavelmente achou curioso estudar HTML.

Mas observe.

Uma página HTML possui:

Header.

Body.

Campos.

Botões.

Mensagens.

Formulários.

Menus.

Parece familiar?

Porque é.

BMS fazia exatamente isso.

A diferença é que hoje existem milhões de cores.

Animações.

Responsividade.

E um mouse.

No restante...

Os conceitos continuam incrivelmente parecidos.


Easter Egg nº 2 — O navegador virou um terminal 3270

Calma...

Antes de fechar a página dizendo que enlouqueci...

Pense comigo.

O navegador:

Recebe dados.

Envia comandos.

Mostra telas.

Executa transações.

Atualiza informações.

Consulta banco.

Exatamente como um terminal.

A diferença é que o navegador ganhou superpoderes.

Renderiza vídeos.

Executa JavaScript.

Faz chamadas REST.

Mostra gráficos.

Integra mapas.

Mas continua sendo uma interface.

Assim como o 3270 sempre foi.


Easter Egg nº 3 — HTML não substitui COBOL

Esse talvez seja o maior medo de muitos iniciantes.

"Vou precisar abandonar COBOL?"

Não.

Pelo contrário.

Quanto maior a adoção de APIs...

Mais programas COBOL acabam sendo reutilizados.

Muitos sistemas escritos há quarenta anos hoje atendem aplicações Web modernas.

Mudou apenas a porta de entrada.


O maior erro dos iniciantes

Depois de ministrar diversos treinamentos, comecei a perceber um padrão.

O erro raramente é técnico.

É psicológico.

O aluno olha para a quantidade de tecnologias e conclui:

"Jamais vou aprender tudo isso."

Mas ninguém aprende.

Nem mesmo quem trabalha há trinta anos.

Todos continuam estudando.

Inclusive os IBM Fellows.

Inclusive os Distinguished Engineers.

Inclusive quem desenvolveu boa parte dessas tecnologias.

Aprender nunca termina.


O conselho que gostaria de ter ouvido em 1988

Quando comecei minha carreira, imaginava que bastava aprender COBOL.

Depois vieram CICS.

DB2.

JCL.

VSAM.

REXX.

Assembler.

TCP/IP.

MQ.

Java.

Web Services.

XML.

JSON.

REST.

Git.

Cloud.

DevOps.

IA.

No início achei que era um problema.

Hoje percebo que foi um privilégio.

Poucas profissões permitem acompanhar tantas revoluções tecnológicas sem abandonar completamente aquilo que aprendemos décadas atrás.

O programador COBOL continua reconhecendo um IF.

Um PERFORM.

Um MOVE.

Da mesma forma que reconhece hoje um IF em JavaScript.

A lógica continua sendo a mesma.

Mudam apenas as ferramentas.


O verdadeiro objetivo desta formação

Se ao terminar estas aulas você decorar todos os comandos HTML...

O curso terá sido apenas razoável.

Se aprender Flexbox.

Grid.

DOM.

Eventos.

REST.

JSON.

Também será um bom resultado.

Mas existe um objetivo muito maior.

Perder o medo da palavra "Web".

Porque ela deixou de ser um território distante.

Hoje faz parte do ecossistema IBM Z.


Uma última xícara de café...

Quando observo um IBM z17 processando milhares de transações por segundo enquanto um navegador moderno exibe gráficos, animações e respostas instantâneas, lembro-me de como essa história começou.

Lá atrás, um simples terminal verde.

Depois uma tela BMS.

Mais tarde o TCP/IP.

Vieram XML e Web Services.

Depois JSON.

REST.

Cloud.

Git.

DevOps.

Agora Inteligência Artificial.

O curioso é que, em todas essas fases, alguém decretou que o Mainframe estava ficando para trás.

E, em todas elas, o IBM Z respondeu da melhor maneira possível.

Evoluindo.

Sem perder sua essência.

Sem abandonar sua confiabilidade.

Sem deixar de ser o coração silencioso das maiores empresas do planeta.

Talvez essa seja a maior lição desta jornada.

As tecnologias mudam.

As interfaces evoluem.

As linguagens ganham novos recursos.

Mas a lógica, a arquitetura bem construída e a capacidade de resolver problemas reais continuam sendo o verdadeiro diferencial de um grande profissional.

No fim das contas, HTML, CSS, JavaScript, REST, JSON, Git, DevOps e Inteligência Artificial não são o destino.

São apenas novas ferramentas nas mãos de quem já aprendeu, há muito tempo, que um bom programa começa antes mesmo da primeira linha de código.

E enquanto houver desafios para resolver, clientes para atender e sistemas críticos para manter funcionando, sempre haverá espaço para quem estiver disposto a aprender.

Então abasteça a caneca, abra o editor de código e continue estudando.

Porque a próxima grande evolução do IBM Z provavelmente já começou.

E, quem sabe, ela será escrita por você.

Do conceito à prática: os laboratórios da Formação APPDEV

Teoria sem prática é como um programa COBOL que nunca saiu do editor: pode estar elegante, bem comentado e perfeitamente identado, mas ainda não processou uma única transação.

Por isso, a Formação APPDEV não termina quando o último slide desaparece da tela.

Ela continua nos laboratórios.

É nesses ambientes que HTML deixa de ser apenas uma sequência de tags, CSS deixa de ser decoração, JavaScript deixa de ser uma promessa e a integração com o ecossistema IBM Z começa a ganhar forma diante dos nossos olhos.

Prepare a caneca.

Abra o navegador.

E vamos colocar a mão na massa.


IBM Web Development Labs

O primeiro ponto de partida é o laboratório de desenvolvimento Web utilizado durante a formação:

IBM Web Development Labs
https://vagnerbellacosa.github.io/Lab_WebdevelopmentCoursera/

Nesse ambiente, o aluno pode revisar os fundamentos de HTML, CSS e JavaScript, observar a organização de uma aplicação Web e experimentar a construção de páginas diretamente no navegador.

É o lugar ideal para praticar:

  • estruturação de páginas com HTML;

  • aplicação de estilos com CSS;

  • criação de comportamentos com JavaScript;

  • eventos de clique e formulário;

  • manipulação do DOM;

  • organização de componentes;

  • preparação para consumo de APIs.

O objetivo não é apenas copiar códigos.

É alterar.

Quebrar.

Testar.

Corrigir.

Executar novamente.

Programação continua sendo uma ciência experimental, mesmo quando o laboratório cabe dentro de uma aba do navegador.

O endereço desse laboratório aparece diretamente na apresentação APPDEV como recurso para continuidade dos estudos.


LAB IBM IPL Mainframe

Depois de compreender o funcionamento da camada Web, vale retornar ao coração da infraestrutura:

LAB IBM IPL Mainframe
https://vagnerbellacosa.github.io/LAB_IBM_IPLMainframe/

IPL significa Initial Program Load.

É, de maneira simplificada, o processo de inicialização de um sistema IBM Z. Entretanto, compará-lo apenas ao boot de um computador pessoal seria uma simplificação quase ofensiva.

Em um ambiente corporativo, um IPL envolve planejamento, volumes, parâmetros, dispositivos, subsistemas, segurança, disponibilidade e uma sequência cuidadosamente controlada de operações.

O laboratório ajuda o estudante a enxergar o IBM Z não apenas como uma máquina que executa COBOL, mas como uma plataforma completa, composta por diversas camadas trabalhando em conjunto.

Essa visão é fundamental para o Desenvolvedor IBM Z Moderno.

Mesmo que ele não execute um IPL em produção, precisa compreender o ambiente no qual seus programas vivem.

A apresentação disponibiliza esse laboratório como uma etapa complementar da jornada.


Lab IBM Storage Management

Todo programa precisa de dados.

E todo dado precisa morar em algum lugar.

Lab IBM Storage Management
https://vagnerbellacosa.github.io/Lab_IBM_StorageManagement/

Nesse laboratório, o aluno pode ampliar a compreensão sobre armazenamento no ecossistema IBM Z.

Isso inclui conceitos relacionados a:

  • datasets;

  • volumes;

  • DASD;

  • organização de arquivos;

  • gerenciamento de espaço;

  • políticas de armazenamento;

  • disponibilidade;

  • proteção de dados;

  • relacionamento entre aplicação e infraestrutura.

No mundo Web, falamos em arquivos, pastas, objetos, buckets e bancos de dados.

No IBM Z, encontramos datasets sequenciais, PDS, PDSE, VSAM, catálogos, volumes e políticas SMS.

Novamente, mudam as ferramentas e os nomes.

A necessidade permanece a mesma:

guardar a informação correta, no lugar correto, com segurança e disponibilidade.

O link para o laboratório de Storage Management também faz parte dos materiais de continuidade presentes na apresentação.


LAB IBM Capacity

Uma aplicação pode funcionar perfeitamente para dez usuários e entrar em colapso quando o décimo primeiro aparece.

É nesse momento que descobrimos que desenvolver software não significa apenas produzir resultados corretos.

Também significa produzir resultados dentro do tempo esperado.

LAB IBM Capacity
https://vagnerbellacosa.github.io/LAB_IBM_Capacity/

O laboratório de capacidade introduz uma visão essencial para aplicações corporativas:

  • utilização de CPU;

  • consumo de memória;

  • carga de trabalho;

  • crescimento de demanda;

  • gargalos;

  • throughput;

  • tempo de resposta;

  • planejamento de recursos;

  • comportamento do ambiente em períodos de pico.

Imagine uma aplicação Web consultando uma API REST que chama z/OS Connect, entra no CICS, executa COBOL e consulta DB2.

Cada camada consome recursos.

Cada camada pode introduzir espera.

Cada componente precisa ser observado.

O usuário não está preocupado com o número de instruções executadas.

Ele apenas sabe que clicou no botão e está esperando.

Por isso, capacidade e desempenho também fazem parte da experiência do usuário.

O laboratório de Capacity aparece na apresentação como parte da trilha prática recomendada.


Lab War Room Mainframe

Alguns problemas não chegam educadamente durante o horário comercial.

Eles aparecem de madrugada.

No fechamento mensal.

Durante uma grande campanha.

Ou exatamente quando todos acreditavam que a mudança estava sob controle.

Lab War Room Mainframe
https://vagnerbellacosa.github.io/LAB_WarRoom_Mainframe/

O conceito de War Room representa a investigação coordenada de incidentes.

É o lugar — físico ou virtual — onde profissionais de diferentes áreas analisam juntos:

  • sintomas;

  • logs;

  • mensagens;

  • falhas;

  • tempos de resposta;

  • consumo de recursos;

  • dependências;

  • mudanças recentes;

  • comportamento das aplicações;

  • impacto para o negócio.

No ambiente moderno, uma falha aparentemente simples no navegador pode ter começado muito longe dele.

O botão não respondeu.

Mas a causa pode estar em:

JavaScript
    ↓
REST API
    ↓
z/OS Connect
    ↓
CICS
    ↓
COBOL
    ↓
DB2
    ↓
Storage

É por isso que o profissional capaz de compreender toda a cadeia possui enorme valor.

Ele não observa apenas a mensagem de erro.

Ele segue as pegadas.

O laboratório War Room Mainframe também está entre os recursos indicados na apresentação APPDEV.


Para ir mais longe: Bellacosa Mainframe

A formação termina.

O aprendizado, felizmente, não.

Para continuar explorando COBOL, CICS, DB2, JCL, VSAM, APIs, HTML, CSS, JavaScript, DevOps, segurança, arquitetura e cultura Mainframe, visite:

Um Café no Bellacosa Mainframe
https://eljefemidnightlunch.blogspot.com/

O blog funciona como uma grande biblioteca construída ao longo do tempo.

Há artigos para iniciantes.

Conteúdos técnicos aprofundados.

Histórias sobre a evolução da computação.

Analogias com filmes, séries, quadrinhos, ficção científica e cultura popular.

Porque aprender tecnologia também significa construir memórias.

Um conceito técnico pode ser esquecido.

Mas uma boa história costuma permanecer.

A apresentação indica o Bellacosa Mainframe como espaço para aprofundamento e continuidade dos estudos.


Projeto Coursera Web Developer no GitHub

Ler códigos é importante.

Executá-los é melhor.

Modificá-los é onde o aprendizado realmente começa.

Projeto Coursera Web Developer
https://github.com/VagnerBellacosa/Lab_WebdevelopmentCoursera

Nesse repositório, o aluno pode explorar a organização de um projeto real, comparar arquivos, analisar versões e compreender como HTML, CSS e JavaScript convivem dentro de uma estrutura profissional.

Um repositório Git não é apenas um lugar para guardar código.

Ele registra a história do projeto.

Mostra o que mudou.

Quando mudou.

Por que mudou.

E quem realizou a alteração.

Essa rastreabilidade aproxima o desenvolvimento Web das práticas modernas de DevOps utilizadas também no IBM Z.

O projeto e seu endereço no GitHub aparecem entre os materiais finais da apresentação.


Mais repositórios HTML: mão na massa

Para explorar outros exemplos, projetos e experiências relacionadas a HTML, acesse:

Repositórios HTML de Vagner Bellacosa
https://github.com/VagnerBellacosa?tab=repositories&q=html

Aqui vale seguir uma pequena rotina de laboratório:

  1. Escolha um projeto.

  2. Observe a estrutura de diretórios.

  3. Localize o index.html.

  4. Identifique os arquivos CSS.

  5. Encontre os códigos JavaScript.

  6. Execute a aplicação.

  7. Altere um elemento.

  8. Teste novamente.

  9. Quebre alguma coisa propositalmente.

  10. Descubra como corrigir.

O aprendizado verdadeiro começa quando deixamos de ser visitantes do código e passamos a ser seus investigadores.

A apresentação encerra a seção prática justamente apontando para os repositórios HTML disponíveis no GitHub.


Uma trilha prática sugerida

Para aproveitar melhor os materiais, siga esta sequência:

1. IBM Web Development Labs
              ↓
2. Projeto Web Developer no GitHub
              ↓
3. Repositórios HTML
              ↓
4. LAB IBM IPL Mainframe
              ↓
5. Lab IBM Storage Management
              ↓
6. LAB IBM Capacity
              ↓
7. Lab War Room Mainframe
              ↓
8. Bellacosa Mainframe

Começamos pela interface.

Seguimos para o código.

Entramos no controle de versões.

Descemos até a infraestrutura.

Observamos armazenamento e capacidade.

Investigamos incidentes.

E retornamos ao blog para continuar estudando.

Essa é a verdadeira jornada do Desenvolvedor IBM Z Moderno.

Ele não precisa dominar todas as áreas como especialista.

Mas precisa compreender como elas se conectam.


O diploma encerra uma etapa, não a jornada

Ao terminar a Formação APPDEV, o aluno leva muito mais do que alguns comandos HTML, propriedades CSS ou funções JavaScript.

Ele passa a compreender uma cadeia completa:

Usuário
   ↓
Browser
   ↓
HTML + CSS + JavaScript
   ↓
REST API + JSON
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
DB2
   ↓
IBM z17

Essa visão integrada é o verdadeiro resultado da formação.

O certificado registra que uma etapa foi concluída.

Os laboratórios demonstram que a prática começou.

O GitHub registra a evolução.

E o conhecimento de negócio transforma tudo isso em valor.

Por isso, quando alguém perguntar o que existe entre um botão HTML e uma transação COBOL, você não precisará mais imaginar dois mundos separados.

Verá uma única arquitetura.

Uma longa linha luminosa atravessando navegador, API, middleware, transação, programa e banco de dados.

De um lado, a experiência do usuário.

Do outro, a confiabilidade do IBM Z.

No meio deles...

O Desenvolvedor IBM Z Moderno.

Com uma caneca de café sobre a mesa e muitos caminhos ainda esperando para serem explorados.


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