Aprender a linguagem é apenas o primeiro passo — e talvez o menor — para trabalhar em um mainframe real
O mercado repete há anos que faltam profissionais COBOL. Ao mesmo tempo, quem tenta entrar na área encontra vagas que pedem experiência em produção, JCL, DB2, CICS, VSAM, ferramentas de mudança, suporte a incidentes e conhecimento de negócio.
A contradição é evidente. Se faltam profissionais, por que tantas portas de entrada parecem exigir alguém que já tenha atravessado a porta?
Talvez a pergunta esteja formulada de maneira incompleta. O problema não seja simplesmente a quantidade de pessoas interessadas em aprender COBOL. Talvez estejamos formando pessoas que conhecem a linguagem COBOL, mas não necessariamente profissionais capazes de trabalhar em um ambiente mainframe corporativo.
Essa distinção é decisiva.
Aprender COBOL não é o mesmo que aprender a trabalhar profissionalmente com COBOL. E confundir as duas coisas cria uma falsa sensação de preparação para o aluno, uma expectativa irreal para o recrutador e uma frustração previsível para ambos.
Aprender COBOL não significa estar preparado para trabalhar com COBOL
Um curso introdutório pode ensinar variáveis, divisões, PERFORM, OCCURS, REDEFINES, arquivos sequenciais e estruturas condicionais. Isso é necessário. Sem essa base, não existe formação posterior.
Mas essa base não responde a perguntas que aparecem diariamente no trabalho real:
- Como o programa será compilado, link-editado e executado em z/OS?
- Onde estão os arquivos que o programa utiliza?
- Qual é a relação entre o SELECT do COBOL, o DDNAME e o dataset definido no JCL?
- Como um job batch é submetido e monitorado?
- O que significa um COND CODE inesperado?
- Como investigar um S0C7, um S0C4 ou um erro de alocação?
- Como identificar, no spool, se o problema está no programa, no JCL, no dataset ou no ambiente?
- Como uma alteração em um copybook afeta dezenas de programas?
- Como testar uma mudança sem quebrar uma regra de negócio que não está documentada em nenhum manual?
- Como promover o código entre ambientes seguindo as regras da empresa?
Nenhuma dessas perguntas é resolvida apenas conhecendo a sintaxe da linguagem.
O profissional COBOL de um ambiente corporativo trabalha em uma cadeia. O programa é apenas uma parte dessa cadeia. Ele se relaciona com JCL, datasets, compiladores, bibliotecas, schedulers, bancos de dados, monitores transacionais, ferramentas de debugging, controles de segurança, processos de mudança e sistemas externos.
A própria documentação técnica da IBM descreve o desenvolvimento em z/OS como uma combinação de processamento batch ou online, datasets, VSAM, DB2, preparação de programas, compilação, link-edit e execução. O programa COBOL não vive isolado em um arquivo .cob esperando ser executado.
Ele vive dentro de um sistema.
O que muitos cursos ensinam — e o que frequentemente deixam para depois
A oferta atual não é homogênea. Existem materiais excelentes, trilhas práticas e iniciativas que tentam aproximar o aluno do ambiente real. Também existem cursos curtos cujo objetivo é apenas apresentar a linguagem ou permitir que o aluno escreva os primeiros programas.
O problema começa quando esses objetivos diferentes são apresentados como se fossem equivalentes.
O GnuCOBOL, por exemplo, é uma excelente porta de entrada. Ele permite instalar um compilador livre, escrever programas localmente, testar conceitos e compreender a estrutura da linguagem sem depender de uma infraestrutura IBM. O manual documenta compilação, formatos fixed e free, opções de dialeto, geração de executáveis e recursos de depuração.
Isso tem enorme valor educacional. Reduz custos, facilita experimentos e permite que mais pessoas tenham contato com COBOL.
Mas o fluxo local do GnuCOBOL não é o fluxo completo de um ambiente Enterprise COBOL em z/OS. Aprender a executar cobc -x programa.cob não ensina automaticamente a trabalhar com JCL, JES, datasets, TSO/ISPF, SDSF, CICS, DB2 for z/OS, VSAM, RACF ou ferramentas corporativas de change management.
Essa não é uma crítica ao GnuCOBOL. É uma crítica à transferência indevida de competência.
O aluno pode concluir, legitimamente, que aprendeu COBOL. O erro acontece quando alguém conclui, por isso, que ele já está preparado para atuar em um sistema mainframe de produção.
Há uma diferença entre as duas afirmações:
“Consigo escrever e executar um programa COBOL.”
“Consigo alterar, testar, diagnosticar e promover um programa COBOL dentro de um ambiente corporativo crítico.”
A primeira é uma conquista importante. A segunda exige uma formação muito mais ampla.
Há bons caminhos — mas eles ainda são fragmentados
Seria injusto dizer que ninguém está tentando resolver esse problema.
O Open Mainframe Project mantém um curso público estruturado em módulos de introdução, aprendizagem de COBOL, tópicos avançados e testes. O material inclui VS Code, Zowe Explorer, datasets, submissão de JCL, consulta de jobs e spool, processamento de arquivos, VSAM, SQL embarcado, APIs e testes automatizados.
O IBM Z Xplore oferece uma plataforma baseada em desafios, com trilhas que incluem datasets, JCL, USS, VS Code, COBOL, VSAM, DB2 e TSO/ISPF.
Há também treinamentos corporativos mais próximos da realidade operacional. O programa Mainframe Foundations, da Broadcom, aborda z/OS, TSO/ISPF, JES, SDSF, JCL, utilitários, VSAM, USS e COBOL.
Esses exemplos são importantes porque mostram que a formação pode, sim, conectar linguagem e ecossistema.
O problema é que o estudante frequentemente precisa montar essa ponte sozinho. Um curso ensina COBOL. Outro apresenta JCL. Um terceiro aborda DB2. Um laboratório demonstra Zowe. Um vídeo fala de CICS. A integração entre essas peças — justamente a parte que mais se aproxima do trabalho profissional — fica por conta do aluno.
Essa fragmentação também aparece nas discussões de comunidades. Há relatos de estudantes que consideram determinados materiais longos, pouco práticos ou difíceis de conectar. Um participante descreveu ter lido muitos textos e realizado laboratórios sem sentir que havia escrito código de maneira efetiva. Outro criticou a coerência de materiais introdutórios do Open Mainframe Project.
Esses relatos não são estatística e não provam que os cursos sejam ruins. Mas revelam um problema de experiência pedagógica: um material pode conter os tópicos corretos e ainda falhar em mostrar como eles se encaixam em uma tarefa real.
Um profissional não precisa apenas saber que JCL, DB2 e CICS existem. Ele precisa entender quando cada um entra no fluxo, que tipo de falha ocorre na fronteira entre eles e como investigar o problema.
O que as vagas realmente estão pedindo
A amostra de vagas consultada no Brasil e no exterior mostra um padrão consistente.
No Brasil, anúncios de empresas como Indra/Minsait e EY combinam COBOL com JCL, DB2, CICS, SQL, batch, processamento online, TSO/ISPF, datasets, VSAM, análise de abends, controle de jobs, Git, testes, métodos ágeis e integração com novas tecnologias. Em vários casos, o domínio de negócio é financeiro: bancos, fintechs, seguros, pagamentos e mercado de capitais.
No exterior, aparecem os mesmos fundamentos, mas com especializações adicionais. Vagas recentes no Canadá e nos Estados Unidos associam COBOL a DB2, CICS, JCL, VSAM e IBM MQ, além de suporte produtivo, análise de causa-raiz, releases, testes de integração e conhecimento de seguros, saúde ou brokerage.
No Reino Unido, uma vaga de desenvolvimento com CICS Web Services pedia COBOL, CICS, JCL, DB2, VSAM, SOAP, REST, WSDL, XML, JSON, MQ, API gateways, DevOps e ferramentas como Jenkins, Git e Endevor ou Changeman.
Na Austrália, uma posição de liderança técnica combinava COBOL, CICS e DB2 com APIs, cloud, AWS, contêineres, automação, CI/CD, DevSecOps e desenvolvimento assistido por IA.
Não se deve transformar essa amostra em ranking estatístico do mercado. Ela não é um censo e não permite calcular a porcentagem de vagas que exige cada tecnologia. Mas ela revela algo importante: o rótulo “profissional COBOL” frequentemente descreve uma combinação de competências que vai muito além de COBOL.
O núcleo clássico continua sendo essencial:
- COBOL e seus dialetos corporativos;
- JCL e processamento batch;
- datasets e organização de arquivos;
- VSAM;
- DB2 e SQL embarcado;
- CICS ou IMS, conforme o ambiente;
- TSO/ISPF e ferramentas de operação;
- leitura de spool e análise de return codes;
- debugging, ABENDs e dumps;
- manutenção de programas existentes;
- entendimento das regras de negócio.
A esse núcleo se somam, em muitos contextos:
- Git, Endevor ou Changeman;
- testes automatizados e de regressão;
- CI/CD e DevOps;
- APIs REST e OpenAPI;
- mensageria, especialmente MQ;
- observabilidade;
- cloud híbrida;
- Java ou Python;
- arquitetura e integração.
A pergunta correta não é se todo iniciante precisa dominar tudo isso antes de conseguir o primeiro emprego. Não precisa.
A pergunta é outra: o curso deixa claro qual parte ele ensina e qual parte ainda falta aprender?
O abismo chamado experiência
A discussão sobre escassez de profissionais COBOL costuma ignorar a palavra mais importante: experiência.
O Global Mainframe Skills Report 2024, produzido pela The Futurum Group, registrou que 79% dos empregadores pesquisados buscavam profissionais de meio de carreira, enquanto 51% declararam contratar posições de entrada. Esses números não representam todas as empresas nem todas as vagas, mas ajudam a explicar o paradoxo.
Existe uma porta de entrada. Porém, a demanda por pessoas capazes de assumir sistemas reais, interpretar regras de negócio e participar de incidentes é maior do que a oferta de profissionais nessa etapa intermediária.
O relatório também encontrou um dado relevante: 65% dos respondentes universitários afirmaram haver mais profissionais mainframe qualificados do que cinco anos antes, mas 61% ainda identificaram uma lacuna significativa de habilidades. Ou seja, a oferta pode estar crescendo sem acompanhar o tipo de competência que as empresas precisam.
Pesquisas da Kyndryl apontam na mesma direção, com uma ressalva importante. Em 2025, as maiores lacunas declaradas pelas organizações foram IA generativa, cloud e integração; apenas 23% citaram linguagens legadas. Isso enfraquece a frase simplista “falta COBOL”. O que parece faltar, em muitos casos, é a capacidade de conectar legado, operação e tecnologias modernas.
O círculo vicioso é plausível:
- A empresa precisa de alguém produtivo.
- Para reduzir risco, exige experiência.
- Poucas empresas oferecem uma primeira experiência real.
- Cursos e laboratórios não substituem completamente a exposição supervisionada.
- O profissional demora a alcançar o nível intermediário.
- A empresa conclui que não há gente pronta no mercado.
Isso não foi demonstrado como uma cadeia causal por nenhum dos estudos consultados. Não há uma base longitudinal que acompanhe alunos desde o primeiro curso até a contratação, produtividade, retenção e evolução profissional.
Mas a hipótese é coerente com os requisitos observados nas vagas, com os relatos de iniciantes e com a preferência declarada por profissionais experientes.
Talvez o mercado esteja reclamando de uma escassez que ele próprio ajuda a produzir.
Empresas que terceirizam continuamente a manutenção, contratam apenas profissionais seniores e não estruturam programas de aprendizagem podem resolver a demanda imediata. Mas não necessariamente formam a próxima geração.
COBOL não vive sozinho
O profissional que conhece perfeitamente PERFORM, OCCURS e REDEFINES ainda pode ficar completamente perdido diante de um job que falha antes de executar a primeira linha do programa.
Pode não saber se o problema está no dataset, na alocação, no DISP, no catálogo, no encoding, no JCL ou no programa. Pode não saber onde localizar a mensagem relevante no spool. Pode não reconhecer a diferença entre um erro de dados, um problema de copybook, uma falha de bind ou uma condição de execução.
A documentação IBM e de fornecedores de ferramentas deixa claro que o diagnóstico profissional exige mais do que ler o código. O z/OS Debugger oferece recursos para debugging de COBOL, batch, DB2 e CICS. Ferramentas como Abend-AID, InterTest e SymDump trabalham com listings, storage, registradores, SQLCA, trace, backtrace e causa provável de ABEND.
Isso não significa que um programador iniciante precise dominar todas essas ferramentas no primeiro dia. Significa que a formação deveria mostrar a existência do fluxo completo e criar oportunidades progressivas para praticá-lo.
Um exercício mais próximo do trabalho real não seria apenas:
“Escreva um programa que leia três registros e imprima um relatório.”
Seria algo como:
“Altere um programa existente para incluir uma regra de negócio. Submeta a mudança via JCL. O job falhará por uma condição de dados. Use o spool para encontrar a mensagem, depure o programa, corrija o problema, execute o teste de regressão e documente o impacto da alteração.”
Esse exercício ensina muito mais do que sintaxe. Ensina investigação, ciclo de entrega, responsabilidade e contexto.
O segundo erro: ensinar apenas o COBOL tradicional
Existe também um risco no sentido oposto.
Depois de reconhecer que a linguagem continua essencial, algumas formações param no COBOL clássico, no JCL e nas telas tradicionais. Isso também pode produzir um profissional incompleto.
As vagas de modernização mostram demanda por APIs, Git, CI/CD, DevOps, mensageria, cloud, observabilidade, Java, Python e arquitetura. O IBM z/OS Connect, por exemplo, permite expor programas COBOL, transações CICS e serviços IMS por meio de APIs REST.
O Zowe oferece CLI, exploradores de datasets, JES, USS, TSO e integração com editores e pipelines. A IBM documenta práticas de CI/CD para z/OS com Git, build, testes, pull requests e deploy. O IBM Z Observability Connect trabalha com traces, métricas e logs por OpenTelemetry.
Essas tecnologias não tornam o mainframe irrelevante. Elas mostram que o mainframe está sendo integrado a uma arquitetura mais ampla.
O profissional COBOL moderno não precisa abandonar o legado para aprender APIs. Precisa entender como o legado pode ser consumido, protegido, observado, testado e evoluído dentro de uma arquitetura híbrida.
Java e Python também devem ser tratados com equilíbrio. Java pode ser relevante em iniciativas de refatoração ou replatforming. Python pode apoiar automação, testes, scripts e análise. Mas não há evidência de que um deles deva substituir universalmente COBOL.
A mesma cautela vale para IA. IBM, AWS e Google já oferecem ferramentas para análise, documentação, transformação e geração assistida de código legado. Porém, essas ferramentas exigem revisão humana, testes de equivalência, rastreabilidade e validação das regras de negócio.
Transformar código automaticamente não significa compreender o sistema.
Quem deveria formar esses profissionais?
Não é razoável transferir toda a responsabilidade para cursos, professores ou iniciantes.
Cursos têm limitações concretas. Um ambiente mainframe completo é caro, complexo e difícil de disponibilizar. Licenciamento, acesso a z/OS, DB2, CICS, dados e ferramentas corporativas são barreiras reais. É legítimo começar com GnuCOBOL, exemplos locais e exercícios simples.
Universidades também não precisam formar especialistas em todos os produtos IBM. Seu papel pode ser oferecer fundamentos de programação, arquivos, bancos de dados, sistemas operacionais, engenharia de software e arquitetura, além de apresentar o mainframe como um ambiente relevante.
Comunidades e projetos abertos podem ajudar a preencher a lacuna de acesso. O Open Mainframe Project, Zowe e IBM Z Xplore mostram que é possível oferecer experiências mais próximas do ambiente profissional sem reproduzir toda a infraestrutura de uma grande instituição financeira.
Mas as empresas têm uma responsabilidade que não pode ser terceirizada: formar experiência de produção.
Nenhum curso aberto consegue reproduzir integralmente a cultura de mudança, os riscos, as regras de segurança, os incidentes e o conhecimento tácito de uma organização. Empresas que dizem sofrer com escassez precisam criar apprenticeships, estágios técnicos, rotação entre desenvolvimento e sustentação, pairing com profissionais experientes e ambientes de teste com problemas realistas.
Se toda vaga inicial exigir cinco anos de experiência, o mercado não está apenas selecionando profissionais. Está reduzindo deliberadamente a quantidade de pessoas que poderão se tornar seniores no futuro.
Como fazer diferente
Uma formação profissional progressiva poderia ser organizada em camadas.
Primeira camada: linguagem e fundamentos. COBOL estruturado, tipos de dados, copybooks, arquivos, tratamento de erros, COMP-3, formatos fixed/free e leitura de código existente.
Segunda camada: ambiente z/OS. TSO/ISPF, datasets, JCL, JES, SDSF, compile/link/bind, batch, return codes e análise inicial de ABENDs.
Terceira camada: subsistemas e dados. VSAM, DB2 com SQL embarcado, SQLCA, precompile ou coprocessor, bind, CICS, MQ e IMS conforme o perfil da trilha.
Quarta camada: engenharia de entrega. Git, revisão de código, testes unitários e de regressão, CI/CD, ferramentas de change management, debugging, dumps e promoção entre ambientes.
Quinta camada: negócio e manutenção. Análise de impacto, regras de negócio, programas existentes, copybooks compartilhados, dependências, documentação e risco de mudança.
Sexta camada: integração e modernização. APIs REST, OpenAPI, JSON/XML, mensageria, observabilidade, cloud híbrida, Java ou Python como complementos e uso responsável de IA.
O objetivo não é transformar todo iniciante em arquiteto, administrador de segurança e especialista CICS ao mesmo tempo. É deixar visível o mapa do território e oferecer uma sequência de aprendizagem coerente.
A avaliação também precisa mudar. Em vez de medir apenas se o aluno consegue escrever um programa novo do zero, é preciso testar se ele consegue trabalhar com um programa existente, interpretar uma falha, rastrear dados, executar uma mudança com segurança e explicar o impacto para o negócio.
Conclusão: o erro está na promessa, não no primeiro passo
É razoável começar ensinando sintaxe COBOL. É razoável usar GnuCOBOL. É razoável utilizar VS Code. É razoável propor exercícios pequenos antes de apresentar JCL, DB2, CICS, dumps e produção.
O problema não está no primeiro passo.
O problema está em parar no primeiro passo — ou em apresentar esse primeiro passo como se fosse a jornada completa.
Hello World não prepara ninguém para investigar um ABEND de madrugada. Mas também não se deve exigir que um iniciante saiba administrar todo o z/OS antes de escrever seu primeiro programa.
A formação precisa ser progressiva, explícita e conectada.
O profissional COBOL que o mercado realmente precisa não é apenas alguém que conhece a linguagem. É alguém capaz de compreender o sistema em que a linguagem opera: seus dados, transações, jobs, interfaces, regras de negócio, riscos, ferramentas e caminhos de modernização.
A base clássica continua valiosa. O que não é mais suficiente é tratá-la como ponto final.
Não estamos formando errado por ensinar COBOL. Estamos formando de modo incompleto quando confundimos aprender COBOL com aprender a trabalhar profissionalmente com COBOL.
