☕ Um Café no Bellacosa Mainframe

A Terra dos Badges — Quando Dilbert Entrou no IBM Z, Dogbert Criou um Dashboard e Catbert Descobriu que um S0C7 Não Liga para Seu LinkedIn

Ou: por que aprender mainframe de verdade ainda exige mais do que clicar em “Complete Course”, ganhar uma medalha digital e posar ao lado de um Easy Button

Imagine a seguinte cena.

Você é um programador COBOL iniciante. Acabou de descobrir que existe uma máquina chamada IBM Z capaz de processar transações de banco, cartões, seguros, governos, companhias aéreas e boa parte das coisas que fazem o mundo não virar uma feira livre toda segunda-feira às oito da manhã.

Você está animado.

Abre o portal de aprendizado. Há uma trilha. Depois outra trilha. Depois um badge. Depois uma comunidade. Depois um webinar. Depois uma campanha. Depois uma proposta de publicar um post usando um kit de redes sociais. Depois um convite para chamar outro colega. E, antes de ter submetido seu primeiro JCL com erro de sintaxe, aparece uma medalha digital dizendo que você está “engajado”.

Nesse momento, Dilbert pergunta:

— “Então agora eu sei COBOL?”

Dogbert, vestido de consultor estratégico, responde:

— “Não. Mas seu nível de advocacy subiu 14%, e isso cabe maravilhosamente no gráfico trimestral.”

Catbert, o malvado diretor de RH, entra carregando uma prancheta:

— “Excelente. Vamos chamá-lo de Mainframe Evangelist Associate Bronze. Não precisa entender DISP=(NEW,CATLG,DELETE) agora. Isso fica para a próxima jornada.”

E é exatamente aqui que mora uma discussão importante sobre IBM Z, LinuxONE, badges, comunidades, treinamento e a diferença entre parecer que você está aprendendo e realmente conseguir trabalhar quando o lote bancário resolve explodir às 2h17 da madrugada.

O assunto não é “mainframe é ruim”, “IBM não presta” ou “badge não serve para nada”. Isso seria tão infantil quanto dizer que COBOL é ultrapassado porque seu editor tem menos emojis do que o celular. O assunto é mais sério:

como formar gente capaz de operar, evoluir e defender uma plataforma crítica sem transformar a jornada inteira em um parque de diversões corporativo de medalhas, slogans e dashboards?

Vamos abrir o SYSOUT, chamar Igor para buscar café e entender essa história sem atirar no escuro.

---

1. IBM Z não vendeu apenas computadores: vendeu uma civilização

Para entender o problema, o jovem padawan COBOL precisa primeiro respeitar o tamanho da coisa.

Durante muitas décadas, comprar um mainframe IBM não significava apenas instalar uma máquina no datacenter. Significava entrar em uma civilização técnica inteira. Você comprava ou contratava uma combinação de:

• hardware;

• z/OS;

• JES2;

• TSO/ISPF;

• RACF;

• CICS;

• IMS;

• Db2;

• MQ;

• VSAM;

• COBOL, PL/I, Assembler, REXX e JCL;

• storage;

• rede;

• backup;

• recuperação de desastre;

• suporte;

• treinamento;

• consultoria;

• processos;

• documentação;

• certificações;

• e siglas em quantidade suficiente para fazer um dicionário parecer um panfleto de pizzaria.

Isso não aconteceu por maldade. Um banco não pode processar milhões de transações, manter saldo consistente, impedir fraude, recuperar uma região CICS, proteger dados pessoais e fechar o dia financeiro usando a filosofia “vamos subir em produção e ver no que dá”.

No IBM Z, a complexidade muitas vezes é uma defesa contra o caos.

Quando você trabalha com transações, integridade, auditoria, criptografia, disponibilidade e compatibilidade de décadas, simplicidade absoluta não existe. A pergunta correta não é “por que é tão complexo?”, mas:

qual parte dessa complexidade protege o negócio, e qual parte só protege uma burocracia que aprendeu a se reproduzir?

Esta é a divisão central do artigo que motivou nossa conversa.

Complexidade que gera valor	Complexidade que só atrapalha
COMMIT e ROLLBACK coerentes	Pedir acesso por e-mail para descobrir um tutorial
RACF protegendo recursos	Depender de um “dono da planilha”
WLM priorizando workloads	Documentação fragmentada em cinco portais
JCL controlando execução batch	Processo opaco para testar software
Db2 preservando integridade	Badge usada como substituto de experiência
CICS coordenando transações	Caminho de entrada cheio de rituais vazios

O problema nunca foi exigir que alguém aprenda o que está fazendo antes de alterar o sistema que paga aposentadorias ou liquida cartões. O problema é confundir segurança com inacessibilidade.

---

2. O Undo: uma pequena tecla que mudou a filosofia da computação

Parece estranho começar uma conversa sobre mainframe falando de Undo, mas a metáfora é excelente.

Nos primeiros tempos da computação, a máquina mandava e o humano obedecia. Se você fazia algo errado, o sistema dizia, em termos técnicos:

“Parabéns. Agora conviva com as consequências.”

O Undo trouxe outra ideia: pessoas erram. Pessoas experimentam. Pessoas aprendem destruindo coisas pequenas antes de serem autorizadas a mexer em coisas grandes.

Essa é uma mudança civilizatória no design de sistemas.

Um bom ambiente de aprendizado não elimina consequências; ele reduz o preço do erro. Você pode montar um JCL errado, receber JCL ERROR, abrir o SDSF, ler a mensagem, corrigir e tentar novamente. Ninguém perdeu dinheiro, nenhum cliente ficou sem cartão, e você aprendeu algo que não esquecerá.

É por isso que laboratório vale mais do que slogan.

Um curso pode explicar:

ADD WS-VALOR TO WS-TOTAL

Mas só um exercício real ensina que:

• o campo pode ter tamanho inadequado;

• o valor pode chegar inválido;

• o arquivo pode não abrir;

• o FILE STATUS pode trazer uma surpresa;

• o job pode nem chegar a executar;

• e o problema talvez esteja no JCL, não no COBOL.

Dogbert chamaria isso de “experiência de aprendizagem baseada em atrito produtivo”. Nós chamamos de “tomar uma paulada educativa do SYSOUT”.

---

3. Badge é certificado de passagem, não diploma de sobrevivência

Vamos falar com justiça: badges não são inúteis.

Para quem está começando, uma badge pode ajudar a:

• descobrir um tema;

• manter disciplina;

• organizar o estudo;

• demonstrar interesse inicial;

• obter visibilidade;

• abrir conversa com recrutador, professor, gestor ou mentor;

• provar que concluiu uma trilha específica.

Você próprio pode ter uma coleção saudável de cursos e credenciais e, ainda assim, continuar estudando. Isso não é contradição. É maturidade.

A falha aparece quando a empresa faz esta conta errada:

$$\text{Badge obtida} = \text{profissional pronto}$$

Não é.

A conta mais honesta é:

$$\text{Badge obtida} = \text{evidência de que uma atividade definida foi concluída}$$

Pode ser uma boa evidência. Pode ser o primeiro degrau. Mas ainda não responde perguntas fundamentais:

• a pessoa consegue ler um programa COBOL desconhecido?

• sabe diferenciar erro de compilação de erro de execução?

• consegue localizar um S0C7?

• sabe o que fazer diante de um SQLCODE -805?

• entende a diferença entre CANCEL COBOL e CANCEL CICS?

• sabe por que um COMMIT feito no momento errado pode estragar uma unidade de trabalho?

• sabe investigar se o problema está no programa, no Db2, no dataset, na região CICS, no JCL ou na parametrização?

Se a resposta for “não”, não há vergonha alguma. Todo mundo começa em algum ponto. O problema é entregar ao iniciante um crachá dourado e fingir que ele saiu da academia pronto para comandar a nave.

---

4. Dilbert, Dogbert e Catbert montam um programa de advocacy

Vamos montar uma empresa fictícia: a MegaZ Corporation.

Dilbert recebe a missão de fortalecer o ecossistema técnico. Ele propõe:

— “Vamos criar ambientes de prática, documentação clara, pipelines de CI, testes repetíveis e acesso para estudantes.”

Dogbert olha a proposta e diz:

— “Isso é caro, lento e difícil de colocar num slide.”

Então ele lança o plano alternativo:

1. criar um portal colorido;

2. dividir o aprendizado em pequenas jornadas;

3. dar pontos por assistir vídeos;

4. entregar badges;

5. premiar quem fizer posts;

6. contar publicações como “atos de advocacy”;

7. mostrar crescimento de engajamento;

8. marcar uma reunião para celebrar a reunião que discutiu o engajamento.

Catbert acrescenta:

— “E vamos exigir experiência de marketing para o cargo que deveria expandir uma plataforma técnica. Conhecer IBM Z será desejável, mas opcional.”

Parece piada, mas aponta para um risco real: medir divulgação com mais rigor do que medir competência, acesso e contribuição técnica.

Existe advocacy bom. Você, leitor, pode escrever um artigo ensinando um novato a entender JCL, explicar por que COBOL não é um fóssil, traduzir um ABEND para linguagem humana ou mostrar uma carreira possível. Isso tem valor.

Mas advocacy se torna teatro quando o participante apenas replica uma narrativa pronta para ganhar um ponto.

Advocacy técnico de verdade	Advocacy de dashboard
Publica laboratório reproduzível	Republica arte pronta
Explica um erro e a correção	Usa uma frase promocional
Mostra fonte, JCL e log	Mostra badge e slogan
Ajuda alguém a destravar	Gera uma métrica de campanha
Revela limites do produto	Só divulga vitórias

O teste é simples: alguém consegue fazer algo útil com aquilo?

Se não consegue reproduzir, testar, instalar, entender ou investigar, talvez o conteúdo tenha sido marketing vestido de capacete.

---

5. “Funciona uma vez” não é sinônimo de suporte

Este ponto é ouro para qualquer programador COBOL iniciante.

Imagine que você escreveu um programa, compilou, executou e viu no terminal:

PROCESSAMENTO REALIZADO COM SUCESSO

Ótimo. Mas isso não prova que o programa está pronto para produção.

Talvez você tenha testado apenas:

• um CPF válido;

• um arquivo existente;

• uma conta com saldo;

• uma data normal;

• nenhum erro de I/O;

• nenhum SQLCODE negativo;

• nenhum volume de dados;

• nenhuma concorrência;

• nenhum reinício após falha.

Em ambiente profissional, “funcionou uma vez” é o começo da investigação, não o fim.

Com software para IBM Z e LinuxONE ocorre a mesma coisa. Um pacote pode:

• compilar uma vez em s390x;

• aparecer em uma demonstração;

• ter uma imagem de marketing;

• ser citado num anúncio de parceria;

…sem possuir suporte sustentável.

Suporte sustentável significa:

• build repetível;

• dependências versionadas;

• testes automatizados;

• integração contínua;

• documentação de instalação;

• evidência de desempenho;

• responsável pelo produto;

• processo de correção;

• caminho claro para escalar incidentes;

• manutenção quando a próxima versão quebrar alguma coisa.

A diferença é enorme:

Frase de marketing	Pergunta do profissional
“Roda em IBM Z”	Em qual versão, com quais limites e suporte?
“Compatível com s390x”	Há CI contínuo para garantir isso?
“Demonstrado em LinuxONE”	A instalação é reproduzível?
“Integrado ao ecossistema”	Quem corrige quando quebra?
“Parceria anunciada”	Existe compromisso técnico contínuo?

Um pacote abandonado não fica mantido porque três pessoas receberam badge. Um bug de compilador não se corrige com um webinar. Um iniciante sem ambiente de testes não aprende porque recebeu um post pronto para publicar.

---

6. A métrica que falta: quantos viraram mainframers de verdade?

Empresas adoram métricas de funil:

• inscritos;

• visualizações;

• cursos iniciados;

• cursos concluídos;

• membros em comunidades;

• badges emitidas;

• posts publicados;

• webinars realizados;

• atos de advocacy.

Essas métricas não são mentiras. Elas só são incompletas.

Elas contam atividade próxima do botão. Clicar em “inscrever-se” gera um registro. Terminar um curso gera outro. Publicar um post gera outro. Tudo tem data, hora e gráfico.

Mas a pergunta difícil é esta:

quantos desses alunos se tornaram profissionais que trabalham, permanecem e evoluem no ecossistema?

A trajetória real é bem mais longa:

Curiosidade
   ↓
Curso
   ↓
Laboratório prático
   ↓
Acesso a ambiente realista
   ↓
Primeiro projeto ou estágio
   ↓
Capacidade de diagnosticar e entregar
   ↓
Responsabilidade em produção
   ↓
Carreira sustentável
   ↓
Transferência de conhecimento

É chato medir isso porque leva anos, envolve empregadores diferentes e não cabe em uma apresentação trimestral. Mas é exatamente isso que importa para resolver a alegada escassez de profissionais.

O jovem padawan não deve desprezar uma badge. Deve apenas fazer a pergunta certa:

— “Depois da badge, qual problema real eu consigo resolver?”

Se você não consegue responder, seu próximo passo não é colecionar mais cinco. É procurar prática.

---

7. O plano de estudo que Dogbert não colocaria no dashboard

Se você está começando em COBOL e mainframe, faça o contrário da colecionação compulsiva de credenciais. Use cursos como mapa, não como destino.

Passo 1 — Aprenda o mínimo de COBOL que permite ler um programa

Comece por:

• divisões;

• WORKING-STORAGE;

• PIC;

• MOVE;

• IF;

• PERFORM;

• READ;

• WRITE;

• DISPLAY;

• FILE STATUS;

• COMP-3;

• nível 88.

Seu objetivo inicial não é criar um sistema bancário. É olhar um programa e dizer: “sei onde entra, onde lê, onde calcula, onde grava e onde pode quebrar”.

Passo 2 — Entenda JCL antes de tentar ser herói

JCL não é um detalhe externo. É a instrução que coloca seu programa na estrada.

Aprenda a identificar:

• JOB;

• EXEC;

• DD;

• DSN;

• DISP;

• SPACE;

• DCB;

• SYSOUT;

• STEPLIB;

• SYSIN;

• SYSOUT;

• retorno RC;

• JCL ERROR.

Quando algo falhar, não chute. Abra o SDSF e leia a sequência de mensagens. O log é o narrador da tragédia; ignore-o e você será apenas o ator que entrou no palco errado.

Passo 3 — Faça pequenos erros de propósito

Crie um programa simples e teste:

• arquivo inexistente;

• chave duplicada;

• campo numérico com dado inválido;

• divisão por zero;

• condição de fim de arquivo;

• retorno SQL negativo;

• dataset sem espaço;

• JCL com DD incorreto.

O objetivo é aprender o que o sistema diz quando algo quebra.

Passo 4 — Use as badges como trilha, não como troféu

Ao terminar uma credencial, pergunte:

1. O que eu consigo explicar sem consultar o curso?

2. O que consigo fazer num laboratório?

3. Que erro eu sei reconhecer agora?

4. Que conceito consigo ensinar a outra pessoa?

5. Onde esta habilidade apareceria num incidente real?

Se você não consegue responder, revise. Não corra para a próxima medalha.

---

8. Curiosidade escondida: o mainframe já praticava várias ideias modernas

Existe uma ironia divertida nessa história.

Muita gente imagina que o mundo moderno inventou tudo: isolamento, automação, observabilidade, controle de carga, segurança centralizada, continuidade e governança.

O IBM Z olha para isso e diz:

— “Interessante. Em que ano vocês descobriram?”

WLM organiza prioridades. RACF centraliza proteção. CICS coordena transações. Db2 mantém integridade. JES2 gerencia batch. Sysplex trabalha disponibilidade e escala. Ferramentas de automação e monitoramento há décadas lidam com coisas que hoje reaparecem em slides de cloud como grandes revelações.

O problema do IBM Z não é falta de engenharia moderna. Muitas vezes, é a dificuldade de permitir que novas pessoas encontrem essa engenharia sem precisar atravessar uma floresta de portais, permissões, contratos e cerimônias.

A máquina não precisa ficar banal para ficar mais acessível.

---

Epílogo — Catbert emite o badge, mas o S0C7 emite a verdade

No final da reunião, Dogbert apresenta o dashboard:

• 10 mil novos inscritos;

• 2 mil badges;

• 400 posts;

• 800 atos de advocacy;

• gráfico verde;

• seta para cima;

• aplausos.

Catbert anuncia uma nova credencial: “Certified Frictionless Ecosystem Explorer — Platinum”.

Então, do canto da sala, chega uma mensagem:

ABEND=S0C7
PROGRAM=FATUR001
STEP=PGM001

Silêncio.

O S0C7 não sabe quantos seguidores você tem. O -805 não respeita seu banner de LinkedIn. O IEC141I não se impressiona com sua coleção de medalhas. A região CICS não volta porque alguém escreveu “I’m proud to be an advocate”.

Ela volta porque alguém entende o problema, lê a evidência, faz a pergunta certa, testa a correção e sabe o impacto de cada decisão.

Badges podem abrir a porta. Cursos podem iluminar o corredor. Comunidades podem oferecer companhia na caminhada. Marketing pode chamar gente nova para dentro.

Mas, para atravessar a sala de máquinas, ainda será preciso aprender a ler o painel.

E talvez essa seja a lição mais saudável para o programador COBOL iniciante: não despreze a trilha, não despreze a credencial e não despreze a comunidade. Apenas não confunda o mapa com a viagem, o crachá com a profissão, nem o aplauso do dashboard com o momento em que você finalmente consegue fechar o chamado.