Bellacosa Mainframe e o risco de badges demais nao criar tecnicos necessarios

☕ Um Café no Bellacosa Mainframe

A Lanterna de Diôgenes na Terra dos Badges — Quando o Filósofo Entrou no IBM Z, Encontrou 47 Certificados e Perguntou Quem Sabia Ler o Spool

Ou: por que uma medalha digital pode abrir a porta do mainframe, mas não conserta um S0C7, não explica um ICH408I e não segura a produção às duas da manhã

Prólogo — O homem com a lanterna e o dashboard luminoso

Diôgenes de Sinope caminhava pela praça, dizem, com uma lanterna acesa em pleno dia, procurando um homem honesto. Se o velho cínico aparecesse hoje numa conferência sobre IBM Z e LinuxONE, talvez trocasse a lanterna por um notebook, abrisse o painel de métricas e perguntasse, sem a menor delicadeza:

“Muito bonito. Quantas pessoas receberam badges. Agora mostrem-me uma que consiga descobrir por que o job de fechamento morreu.”

O salão ficaria em silêncio. Alguém apontaria para o gráfico de engajamento. Outro explicaria que a comunidade cresceu 38%. Um terceiro ofereceria café, camiseta e um QR Code para a próxima trilha. Diôgenes continuaria com a mesma cara que faria diante de uma estátua de ouro vendida como virtude:

“Eu não perguntei quem clicou em Complete Course. Perguntei quem sabe fazer a maldita coisa funcionar.”

É duro, mas a crítica que deu origem a este café tem nervo. Ela afirma que o ecossistema IBM Z/LinuxONE não precisa de mais uma iniciativa baseada em checklist, linguagem de marketing que amacia a engenharia até ela perder o significado, ou líderes celebrando movimento enquanto o conhecimento operacional se rarefaz. O texto não está dizendo que cursos e badges são inúteis. Está dizendo algo mais preciso: eles viraram, muitas vezes, o fim da jornada quando deveriam ser o começo dela.

Para quem está começando em COBOL, isso importa muito. Você não precisa desprezar um curso, nem fingir que nasceu sabendo JCL, Db2, RACF e CICS. Mas precisa compreender desde cedo a diferença entre reconhecer uma palavra e carregar uma responsabilidade. O mainframe não exige heroísmo teatral; exige método, curiosidade, disciplina e respeito por sistemas que movimentam dinheiro, benefícios, documentos, cargas, saúde e a vida cotidiana de milhões de pessoas.

1. Badge é recibo, não diploma de guerra

Vamos pôr as coisas no lugar. Um badge pode ser útil. Ele prova, no máximo, que você percorreu uma trilha, foi exposto a conceitos e concluiu um conjunto de atividades definido por alguém. Para o iniciante, isso tem valor real: cria vocabulário, reduz o medo de uma plataforma aparentemente fechada e dá uma primeira direção.

Mas ele não é uma prova completa de competência. Um badge de COBOL não responde às perguntas que aparecem quando o programa entra em produção:

• Você identifica em que ponto um PIC 9(5)V99 recebeu dado alfanumérico?

• Você sabe por que um S0C7 pode ser sintoma de dado ruim, e não simplesmente de “erro no comando MOVE”?

• Você consegue localizar o SYSOUT, ler o JESMSGLG, distinguir RC=0004 de RC=0012 e descobrir qual step realmente falhou?

• Você entende por que um SQLCODE -805 pode ter relação com package, collection, bind e plano de execução — não apenas com “o Db2 caiu”?

Uma certificação pode dizer que o candidato ouviu essas palavras. A experiência demonstrável é o que mostra se ele consegue conectá-las numa investigação.

Pense num curso de direção. O certificado de conclusão não significa que o motorista sabe dirigir numa madrugada chuvosa, com caminhão na faixa ao lado, freio estranho e uma criança atravessando a rua. Significa que ele passou pela primeira etapa. No ambiente corporativo, o erro está em pendurar o certificado na parede e declarar: “pronto, formamos um piloto de Fórmula 1”.

Diôgenes chamaria isso de confundir o rótulo da ânfora com o vinho dentro dela.

2. A diferença entre presença, conhecimento e capacidade

Há três degraus que empresas adoram misturar porque o relatório fica mais bonito quando todos parecem equivalentes.

O primeiro é a presença: a pessoa compareceu à live, abriu os slides, assistiu ao curso, entrou na comunidade. Isso é alcance.

O segundo é o conhecimento declarativo: ela consegue dizer o que é COBOL, JCL, VSAM, CICS, Db2 ou LinuxONE. Isso é vocabulário e compreensão inicial.

O terceiro é a capacidade operacional: ela recebe uma situação imperfeita, formula hipóteses, coleta evidência, executa uma correção segura, registra o que fez e sabe quando deve parar e escalar. Isso é engenharia.

O erro está em anunciar presença como capacidade. É como dar medalha de bombeiro para quem assistiu a uma palestra sobre incêndios. A palestra é necessária; a medalha só deveria vir depois de mostrar que a pessoa reconhece a fumaça, entende o risco, usa o equipamento certo e não joga água numa instalação elétrica por entusiasmo.

No mundo COBOL, um exemplo simples deixa isso claro. Considere um processamento de arquivo de clientes. O aluno lê a teoria: OPEN, READ, AT END, PERFORM UNTIL, WRITE, CLOSE. Ótimo. Depois vem o laboratório honesto:

1. Execute o job com um arquivo de entrada válido e guarde o spool.

2. Execute com uma linha contendo valor inválido onde deveria existir número.

3. Observe o abend ou o FILE STATUS.

4. Acrescente validação antes da operação aritmética.

5. Reexecute.

6. Compare as saídas e explique, em português claro, o que mudou e por quê.

Nesse momento, o estudante começa a deixar de ser colecionador de comandos e passa a aprender causa, efeito e evidência. É aí que mora a diferença entre “sei COBOL” e “posso ser confiável com COBOL”.

3. Simplificar a entrada não é falsificar a montanha

O texto original ataca a simplificação excessiva. É uma crítica importante, desde que não seja convertida em nostalgia cruel. Ninguém deve precisar sofrer desnecessariamente para aprender IBM Z. Não há mérito pedagógico em esconder documentação, negar ambiente de prática ou fazer o novato decorar siglas como se fosse catecismo.

Mas existe uma fronteira entre tornar a porta mais acessível e fingir que, depois dela, não há montanha.

O IBM Z não é complexo porque alguém quis assustar programadores jovens. Ele é complexo porque foi construído para oferecer disponibilidade, isolamento, compatibilidade, auditoria, desempenho e continuidade em escala monumental. LinuxONE não é apenas “um Linux mais caro”; ele participa de uma arquitetura que leva a sério virtualização, segurança, criptografia, resiliência e consolidação de cargas.

Esconder isso sob slogans como “é só clicar e inovar” produz um recém-chegado frustrado na primeira ocorrência real. Mais cedo ou mais tarde, o padawan vai encarar um JCL, um dataset, um retorno de job, uma permissão RACF, um bloqueio Db2, uma transação CICS e um incidente de produção. É melhor que ele encontre esses bichos primeiro em ambiente de aprendizado, com tutor e log, do que pela primeira vez quando o telefone toca às 2h17.

Boa educação faz o contrário da maquiagem: ela quebra a complexidade em partes sem mentir sobre o todo.

4. O que um engenheiro IBM Z realmente precisa aprender

Não existe uma única profissão chamada “mainframe”. Há programador COBOL, analista de suporte, administrador Db2, especialista CICS, profissional de RACF, operador, engenheiro de automação, arquiteto, especialista em Linux, SRE, desenvolvedor de APIs, gente de storage, rede e muito mais. Ninguém precisa dominar todo o planeta antes de escrever o primeiro DISPLAY.

Porém, toda formação séria precisa dar ao iniciante um mapa. Para o programador COBOL, o mapa mínimo poderia ser este:

Território	Pergunta que você deve saber responder
COBOL	O que o programa faz com os dados e em que condição ele pode falhar?
JCL	Como o programa é compilado, executado e recebe seus arquivos?
JES/SDSF	Onde está a evidência do que ocorreu?
Dados	O layout, o tipo e a chave realmente correspondem ao esperado?
Db2/VSAM	Onde o dado mora e como a aplicação o acessa com segurança?
CICS	O que muda quando o programa atende uma transação online?
RACF	Quem pode fazer o quê — e por que não se deve “liberar tudo”?
Operação	Como corrigir sem criar uma segunda falha maior que a primeira?

Veja que isso não exige que o iniciante seja um super-homem. Exige que ele entenda as fronteiras. Um bom programador COBOL não precisa administrar RACF, mas deve saber que um erro de autorização não se resolve pedindo acesso universal. Não precisa ser DBA, mas precisa saber que um COMMIT não é enfeite e que um ROLLBACK não desfaz uma mensagem já enviada para todos os universos possíveis.

5. O laboratório vale mais que o aplauso

Se Diôgenes fosse responsável por uma academia técnica, ele teria uma regra cruel e justa: cada módulo termina com uma entrega verificável. Nada de apenas questionário com três alternativas obviamente erradas e uma frase do instrutor em letras grandes.

Para COBOL iniciante, uma trilha prática de verdade poderia ter cinco missões.

Missão 1 — O programa que fala. Crie um COBOL simples, compile e execute. Não pare no HELLO WORLD: leia o listing, encontre a data de compilação, o módulo gerado e a saída no spool.

Missão 2 — O arquivo que responde. Processe um arquivo sequencial com registros de clientes. Faça o programa contar lidos, aceitos e rejeitados. Use FILE STATUS. Gere relatório de rejeições em vez de fingir que dado inválido não existe.

Missão 3 — O JCL deixa rastros. Altere um DDNAME propositalmente, execute e descubra a falha pelo SDSF. Depois altere espaço, disposition ou nome do dataset com cuidado e explique o efeito.

Missão 4 — O dado tem memória. Faça uma consulta simples em Db2 ou, se o ambiente ainda não permitir, modele a disciplina relacional: chave, validação, atualização, confirmação e tratamento de erro. Entenda que um sistema não é confiável porque contém EXEC SQL; ele é confiável quando trata resultado, concorrência e recuperação.

Missão 5 — O incidente simulado. Receba um programa que falha. Sem roteiro de correção, produza um pequeno relatório: sintoma, evidência, hipótese, causa provável, correção, teste e prevenção. Essa é a semente do pensamento de produção.

O aluno que completa essas missões talvez tenha menos badges para exibir. Em compensação, começa a ter histórias técnicas para contar — e histórias técnicas são a moeda real de uma equipe madura.

6. Produção não é palco para improviso

Há uma romantização perigosa do “herói que entra, digita um comando secreto e salva o banco”. O engenheiro bom geralmente é menos cinematográfico. Ele respira, delimita o impacto, preserva evidência, consulta procedimentos, pede segunda opinião quando necessário e só então muda algo.

O ciclo saudável é quase sempre:

1. Definir o sintoma, sem inventar causa.

2. Coletar logs, spool, mensagens e horários.

3. Avaliar impacto: quem parou, qual dado pode estar comprometido, qual é a urgência.

4. Formular hipóteses e eliminar as fracas com evidência.

5. Corrigir no menor raio de explosão possível.

6. Testar e monitorar.

7. Registrar o aprendizado para o próximo humano não repetir a caça ao tesouro.

Um S0C7, por exemplo, não é uma oportunidade para procurar no Google “como eliminar S0C7” e colar a primeira receita. Ele é uma pista: em algum ponto, uma operação numérica encontrou conteúdo incompatível. Pode ser dado externo, arquivo corrompido, copybook divergente, campo não inicializado, conversão implícita ou caminho lógico esquecido. A pergunta de engenheiro é: qual valor, qual campo, em qual registro, sob qual condição e por que nossa validação não o deteve antes?

Essa mentalidade vale para todo o ecossistema. No LinuxONE, uma carga lenta não é automaticamente “problema do hardware”. Pode ser CPU, I/O, memória, configuração de virtualização, rede, aplicação, banco, coleta de métricas inadequada ou simplesmente uma expectativa mal definida. A ferramenta poderosa não dispensa diagnóstico; ela torna a ausência dele mais cara.

7. Comunidade que produz, não plateia que aplaude

O autor do manifesto pede “comunidades que produzam contribuidores”. Esta talvez seja a parte mais importante. Comunidade não é calendário de webinars. Webinar pode ser a porta, mas comunidade existe quando alguém sai com algo útil nas mãos e deixa algo útil para o próximo.

Exemplos concretos de contribuição valiosa:

• Um guia claro para ler JESMSGLG, JESJCL e JESYSMSG.

• Um repositório de pequenos exercícios COBOL com casos normais e casos quebrados.

• Um template de post-mortem sem caça às bruxas.

• Uma tradução comentada de mensagens frequentes de z/OS, CICS ou Db2.

• Um laboratório que ensina autorização pelo princípio do menor privilégio.

• Um vídeo curto mostrando não só a solução, mas o caminho da investigação.

É aí que educadores, IBM Champions, parceiros, universidades e clientes podem fazer diferença. A plataforma não sobreviverá porque alguém proclamou que ela é estratégica. Ela sobreviverá quando pessoas novas conseguirem entrar, aprender com rigor, entregar valor e, depois, ensinar o que aprenderam sem esconder o mapa.

8. Métricas que fariam Diôgenes parar de resmungar

Diôgenes não odiava números; odiava números usados como fantasia moral. Portanto, medir é necessário, mas é preciso medir a coisa certa.

Em vez de celebrar somente inscritos, certificados e visualizações, uma iniciativa madura deveria acompanhar:

• taxa de conclusão de laboratórios práticos;

• qualidade de entregas revisadas por pares ou mentores;

• capacidade de diagnosticar incidentes simulados;

• tempo de onboarding até contribuição supervisionada;

• retenção dos novos profissionais após seis e doze meses;

• documentação e automações produzidas pela comunidade;

• redução de erros repetitivos e de dependência em uma única pessoa;

• contratação ou progressão profissional decorrente do programa.

Não se trata de transformar cada aluno em estatística de fábrica. Trata-se de provar que a educação mudou a capacidade do ecossistema. Se uma trilha emite dez mil badges, mas ninguém consegue fazer manutenção com segurança, o relatório é verde e a realidade é vermelha.

9. O risco do elitismo: a montanha não é clube privado

Agora, um aviso ao veterano que leu tudo isto e sentiu vontade de fechar a porta: não use a crítica aos badges como desculpa para humilhar iniciantes. “Na minha época era tudo mais difícil” não é método de transferência de conhecimento; é apenas uma maneira lenta de extinguir a profissão.

O padawan COBOL não deve ser punido por ainda não entender um dump. Deve ser convidado a lê-lo. Não deve ouvir “isso é básico” quando pergunta sobre um REDEFINES; deve receber uma explicação, um exemplo e um exercício que revele o perigo de interpretar bytes iguais como coisas diferentes.

Mentoria técnica de verdade combina exigência e generosidade. Ela diz: “você ainda não sabe, mas vamos descobrir juntos; depois você me explicará de volta.” Não simplifica a realidade, não reduz a barra e não se alimenta da ignorância alheia.

10. O compromisso do jovem padawan COBOL

Se você está entrando agora, não espere que a IBM, a empresa, o curso ou o instrutor façam toda a obra por você. Use badges como mapa, nunca como residência permanente. Ao fim de cada assunto, faça cinco perguntas:

1. Eu consigo explicar isso sem repetir a frase do slide?

2. Eu consigo executar uma versão pequena disso?

3. Eu sei onde olhar quando falhar?

4. Eu sei qual evidência preciso antes de mudar algo?

5. Eu consigo deixar uma anotação que ajude outra pessoa?

Mantenha um caderno de guerra. Guarde mensagens, códigos de retorno, hipóteses que deram errado, comandos úteis, exemplos de JCL, diferenças entre ambientes e traduções suas para as siglas. Depois de alguns meses, você terá algo melhor que uma coleção de ícones digitais: terá memória operacional.

E, sobretudo, aprenda a dizer “não sei ainda, mas vou investigar”. No mainframe, arrogância sem evidência é um tipo de abend humano. Ninguém espera que um iniciante saiba tudo; todos percebem rapidamente quando ele finge saber e altera algo sem compreender o impacto.

Epílogo — A lanterna não procurava um herói

No fim da conferência imaginária, alguém perguntaria a Diôgenes o que ele queria encontrar. Um arquiteto? Um líder iluminado? Um especialista com quarenta anos de casa?

Ele talvez apontasse para uma jovem programadora, ainda confusa com a DATA DIVISION, mas curiosa o suficiente para abrir o spool em vez de declarar que “o sistema está com problema”. E responderia:

“Procuro alguém que respeite a complexidade sem adorá-la; que queira aprender sem posar de pronto; que teste antes de afirmar; que documente depois de descobrir; e que deixe a plataforma um pouco menos misteriosa para o próximo.”

Esse é o engenheiro que IBM Z e LinuxONE precisam. Não um acumulador profissional de badges. Não o guardião rancoroso de siglas. Não o líder que celebra o dashboard enquanto a sala de operações perde gente capaz de ler os rastros.

O hardware é extraordinário. A engenharia que o sustenta é digna de orgulho. Mas nenhum sistema é salvo pelo brilho da própria máquina. Ele é protegido por pessoas treinadas com seriedade, comunidades que compartilham prática e lideranças capazes de trocar aplauso por resultado.

Badge pode abrir a porta. Laboratório ensina o corredor. Incidente ensina humildade. Documentação preserva a descoberta. Mentoria transforma sobreviventes em time.

E a produção, sempre desconfiada, será a única banca examinadora que não se impressiona com medalhas digitais.