Já sou engenheiro de software. Vou voltar a ser júnior no mainframe?

Esta semana recebi um comentário interessante em um dos vídeos do canal. O autor dizia que já trabalha como engenheiro de software, desenvolve principalmente com Node.js, Spring/Java e Python e se interessa por sistemas legados. Pedia também alguma dica para quem já trabalha na área e quer fazer a transição para a plataforma mainframe com COBOL.

Achei a pergunta interessante porque quem já é desenvolvedor está em uma situação muito diferente de quem pretende começar uma carreira em programação. Ele não precisa aprender novamente o que é uma variável, uma estrutura de decisão, um banco de dados ou uma API. Precisa descobrir quais conhecimentos acrescentar àquilo que já sabe.

Você não precisa começar novamente

Imagine um desenvolvedor Java que trabalha há alguns anos com aplicações corporativas. Ele provavelmente já conhece programação estruturada e orientação a objetos, SQL, bancos de dados relacionais, Git, APIs, debugging e testes.

Talvez também tenha experiência com Agile, pipelines de CI/CD, containers e cloud. E, principalmente, já sabe uma coisa que nenhum curso de linguagem ensina rapidamente: como funciona o desenvolvimento de software em uma empresa.

Nada disso deixa de valer porque ele decidiu aprender COBOL.

Por isso, eu não enxergaria essa mudança como uma troca de carreira. Enxergaria como a aquisição de uma nova especialização.

O primeiro passo seria aprender COBOL

Aqui existe uma distinção importante: COBOL e mainframe não são a mesma coisa.

COBOL é uma linguagem de programação e pode, inclusive, ser aprendido fora de um mainframe. Para alguém que já programa em Java ou Python, conceitos como variáveis, condições, repetições, chamadas de programas e acesso a arquivos não serão exatamente novidades.

Naturalmente, a linguagem tem suas particularidades. A forma de definir dados, os tipos numéricos, o tratamento de arquivos e algumas construções serão diferentes daquilo a que esse desenvolvedor está acostumado.

Mas tenho certeza que essa será a parte mais fácil da transição.

Depois é preciso conhecer o ambiente

É aqui que começa o verdadeiro choque cultural.

Quem vem de Windows e Linux, trabalhando com VS Code ou IntelliJ, e encontra pela primeira vez uma tela preta com letras verdes do ISPF pode ter a sensação de que mudou de profissão. Surgem conceitos como datasets, GDGs, members, jobs, spool, sysouts e abends, além de ferramentas e formas de trabalhar que não existem no desenvolvimento distribuído.

À primeira vista, pode parecer que serão necessários mais 20 anos para ter alguma fluência nesse novo ambiente, mas, na verdade, são apenas conceitos – muitos deles semelhantes a estruturas e processos que o profissional já conhecia com outros nomes. Quem faz a transição de plataforma não precisa dominar todo o z/OS. Precisa apenas aprender o suficiente para conseguir trabalhar como desenvolvedor dentro desse ambiente.

Um desenvolvedor acostumado a aplicações web talvez tenha pouco contato com processamento batch. No mainframe, ele vai descobrir que enormes volumes de dados precisam ser processados dessa forma todos os dias e que o JCL é uma das peças fundamentais para executar e organizar esse processamento.

Em um primeiro momento o JCL pode assustar, por ser diferente de tudo o que o profissional conhece. Mas, depois de algum tempo, ele percebe que pode pensar nele, guardadas as devidas diferenças, como uma espécie de linguagem de script com mau humor.

Algumas coisas serão novas. Outras nem tanto.

Se o profissional em transição de plataforma já conhece SQL e bancos de dados relacionais, provavelmente vai se sentir em casa quando encontrar o DB2. Estranhará o fato de trocar o DBeaver pelo SPUFI, mas não terá nenhuma grande dificuldade para compreender a lógica de um programa COBOL com SQL embutido.

O VSAM, com seus KSDS e ESDS, será um desafio em um primeiro momento, pois exige que os dados sejam armazenados e acessados de uma maneira peculiar, que possivelmente o profissional nunca viu.

Algo semelhante acontecerá quando ele tiver contato com o CICS e o processamento transacional. Mas tenho certeza que qualquer profissional que domine a dinâmica front-end + API + back-end conseguirá entender a lógica pseudoconversacional de um programa COBOL/CICS.

E aqui eu tomaria cuidado para não transformar o caminho em uma lista interminável de pré-requisitos. Não acredito que alguém precise dominar TSO, Roscoe, COBOL, JCL, Db2, VSAM, Natural, Adabas, CICS, MQ, RACF, REXX, Endevor e mais uma dúzia de tecnologias e ferramentas antes de procurar a primeira oportunidade na área de mainframe.

O objetivo inicial deve ser construir uma base mínima que permita entender o ambiente e continuar aprendendo dentro dele.

E aí, em algum momento, os dois mundos se encontram

Talvez esta seja a parte mais interessante para quem vem de uma stack mais recente.

Mainframes hoje não vivem isolados. Aplicações COBOL participam de arquiteturas que envolvem APIs, mensageria, Git, pipelines de CI/CD, cloud e sistemas desenvolvidos em diversas outras linguagens.

Nesse momento, aquilo que o desenvolvedor sabia antes de iniciar a transição volta a ser particularmente valioso. Agora ele estará do outro lado da ponte e saberá como as coisas funcionam nas duas margens do rio.

Um profissional que conhece Java, Python ou Node.js e aprende COBOL, CICS e Db2 não precisa escolher entre ser um “desenvolvedor moderno” ou um “desenvolvedor mainframe”. Ele pode justamente se tornar alguém capaz de entender como esses dois ambientes se conectam.

Talvez seja essa a melhor maneira de enxergar a transição.

O caminho não é:

Java > esquecer tudo > COBOL.

É:

experiência atual > COBOL > ambiente mainframe > batch e dados > transacional > integração com o restante da arquitetura.

Sem dúvida há muita coisa para aprender. Mas isso é muito diferente de começar do zero. Para quem já é desenvolvedor, a pergunta não é “como abandono minha stack para trabalhar com mainframe?”.

A pergunta mais interessante é: como acrescento o mainframe àquilo que já sei?