Bellacosa Mainframe e advocates 

☕ Um Café no Bellacosa Mainframe

Inspetor Clouseau Entra no Dashboard IBM Z — O Caso dos 400 Advocates, dos 100 Mil Membros e do Denominador Desaparecido

Ou: por que 50 mil seguidores não são 50 mil especialistas, por que 400 pessoas também não são “o ecossistema”, e como ensinar mainframe em português pode ser mais importante do que outro foguete no PowerPoint

“Chefe, temos uma grande notícia!”, disse o agente da comunidade, entrando apressado na sala.

O Inspetor Clouseau levantou os olhos da xícara de café, que por algum motivo estava equilibrada sobre um manual de RACF.

“Ah, sim. Encontraram o assassino?”

“Melhor: conseguimos 400 Advocates! E mais de mil atos de advocacy no trimestre!”

Clouseau bateu palmas, tropeçou na cadeira, derrubou a pasta de relatórios, quase prendeu a mão na gaveta e, depois de alguns segundos fingindo que aquilo era parte da investigação, perguntou:

“Magnífico. E quatrocentos… de quantos?”

Silêncio.

Um silêncio de data center às três da manhã depois de alguém dizer: “mas eu só alterei um parâmetro”.

É aí que começa o caso.

Não é um caso sobre pessoas ruins, programas inúteis, Champions sem mérito ou estudantes que não deveriam celebrar certificados. É um caso sobre uma criatura perigosa, muito comum em apresentações corporativas, relatórios de comunidade e dashboards coloridos:

o número absoluto que foi solto na rua sem seu denominador.

Para um programador COBOL iniciante, isso pode parecer conversa de estatístico de gravata borboleta. Mas é assunto de sobrevivência profissional. Afinal, no mainframe nós aprendemos cedo que um número sozinho nunca explica a história.

CPU média de 30% parece ótima. Até você descobrir que, no fechamento, a CPU bate 100%, o batch estoura a janela, o CICS começa a sofrer e alguém pergunta por que o relatório mensal não mencionou o detalhe.

Um job terminou com RC=0. Excelente. Mas processou todos os registros? Atualizou o Db2? Gerou o arquivo de remessa? Ou simplesmente não encontrou nada para fazer e saiu feliz como um gato que derrubou um copo e fingiu que não foi ele?

O número não mente necessariamente. Mas pode estar respondendo a uma pergunta diferente daquela que a apresentação quer que você faça.

1. O primeiro suspeito: “Temos 400 Advocates!”

Vamos começar pela matemática que o Inspetor Clouseau encontrou atrás da cortina.

A IBM divulgou, em seus próprios materiais, que a comunidade IBM Z possui mais de 100 mil membros. Depois, em relatórios de advocacy, celebrou números como 197 participantes no lançamento, mais de 400 Advocates em um trimestre e mais de mil “atos de advocacy”.

Todos esses números podem ser verdadeiros.

Mas a pergunta é: o que eles provam?

Se houver 400 Advocates em uma comunidade declarada de 100 mil pessoas, temos:

$$\frac{400}{100.000} = 0,4\%$$

Isso equivale a uma pessoa em cada 250.

Imagine uma cidade com 100 mil habitantes. Quatrocentas pessoas se encontram no auditório de uma escola. Há entusiasmo, palestras, café, networking, gente talentosa e talvez um banner azul muito bonito no fundo.

A reunião é válida? Claro.

Mas se alguém disser que aquela plateia prova que “a cidade inteira está mobilizada”, o Inspetor Clouseau deveria levantar a lupa e perguntar onde estão os outros 99.600 moradores.

No mainframe, seria como dizer que um único LPAR representa toda a empresa. Ele pode ser importante, crítico, cheio de aplicações relevantes e com carga monstruosa. Ainda assim, não é automaticamente o retrato do data center inteiro.

A crítica, portanto, não é: “400 é pouco”.

A crítica correta é:

“400 pode ser um excelente resultado para um programa especializado; não é evidência suficiente, por si só, de engajamento amplo de um ecossistema com mais de 100 mil pessoas.”

Essa diferença parece pequena. Mas muda toda a investigação.

2. O denominador não é inimigo da celebração

Há quem ouça essa discussão e pense: “Então não podemos comemorar nada?”

Podemos e devemos.

Se um programa reuniu 400 pessoas dispostas a ensinar, escrever, falar, testar produtos, mentorar alunos e promover conhecimento técnico, isso merece reconhecimento. Existem comunidades menores que fazem milagres com dez pessoas e uma cafeteira que só funciona quando o ar-condicionado está desligado.

O problema aparece quando a comemoração troca de tamanho no meio da frase.

Veja a diferença:

• “Temos 400 Advocates ativos em nosso Hub.”

• “Temos 400 Advocates, portanto o ecossistema IBM Z está fortemente engajado.”

A primeira frase informa um fato.

A segunda exige prova de representatividade.

É como medir a temperatura de uma sala de CPD e concluir que o clima do Brasil inteiro está controlado. Pode estar fresquinho perto do mainframe; do lado de fora, o termômetro pode estar fritando ovo no asfalto.

3. A sala pode encolher — mas o discurso também precisa encolher

Talvez 100 mil seja um denominador amplo demais. Afinal, “comunidade” pode incluir estudantes, pessoas que assistiram a um evento, perfis inativos, curiosos, parceiros, professores, clientes, ex-clientes e pessoas que se cadastraram numa época em que ainda usávamos CD-ROM para instalar software.

Se usarmos um grupo IBM Z mais específico, com aproximadamente 26.900 membros, 197 Advocates representariam perto de 0,73%.

Ainda não chega a 1%.

Se reduzirmos a sala até um Hub especializado de cerca de 1.500 pessoas, então 400 Advocates equivaleriam a quase 27%.

Aí sim temos uma adoção bastante bonita.

Só que há uma regra de ouro que Clouseau escreveria com caneta azul, erraria a grafia de “denominador” e pisaria no próprio casaco:

Você pode usar o denominador pequeno ou a missão enorme. Não pode usar o pequeno para fazer a porcentagem parecer gigante e o enorme para fazer o programa parecer representativo.

Um Hub de fãs e multiplicadores pode ser uma excelente ferramenta de advocacy. Mas não deve ser apresentado, sem ressalvas, como espelho completo de todos os especialistas que mantêm bancos, seguradoras, governos, indústrias, companhias aéreas e varejistas funcionando.

Porque muita gente essencial simplesmente não aparece nesse tipo de fotografia.

4. O especialista invisível também existe

O Champion, o Advocate e o criador de conteúdo geralmente são pessoas visíveis. Falam em eventos, escrevem, produzem vídeos, participam de comunidades, respondem dúvidas e compartilham conhecimento.

Isso é ótimo. É trabalho real. É generosidade profissional.

Mas o ecossistema mainframe também é formado por pessoas que nunca serão vistas em um palco.

Existe a especialista RACF de um banco que não pode falar publicamente sobre o ambiente. Existe o operador que conhece os sintomas de um incidente antes de o dashboard perceber. Existe a pessoa de storage que carrega na cabeça quarenta anos de decisões estranhas, datasets críticos e procedimentos de recovery que ninguém ousa testar numa segunda-feira.

Existe o programador COBOL que não publica artigo, não participa de rede social e talvez nem tenha foto no LinkedIn — mas sabe que alterar uma definição de copybook sem mapear os programas consumidores pode criar um pequeno apocalipse de produção.

Um processo de Champion seleciona muito bem quem demonstra advocacy visível. Não foi feito para ser um censo da força de trabalho técnica.

É como fazer uma seleção de grandes cozinheiros observando quem posta receitas no Instagram. Você encontrará gente excelente. Mas talvez nunca encontre a tia que alimenta 200 pessoas numa festa de família e sabe exatamente quando o feijão vai queimar sem olhar a panela.

A vitrine pode ser bonita. Mas não é o estoque inteiro.

5. “Atos de advocacy”: quando uma unidade mede muitas coisas diferentes

Agora vamos ao segundo suspeito: o contador de “atos”.

Um programa pode registrar como advocacy:

• criar um perfil;

• compartilhar uma publicação;

• divulgar um evento;

• assistir ou participar de uma sessão;

• escrever um artigo;

• publicar vídeo;

• dar palestra;

• mentorar alguém;

• testar beta;

• participar de conselho técnico;

• contribuir para open source;

• produzir material educacional.

Tudo isso pode ter valor. Mas não é a mesma coisa.

Não se mede o mesmo impacto quando alguém:

1. preenche o perfil;

2. compartilha o convite para um evento;

3. escreve um tutorial que ajuda 500 iniciantes a entender JCL;

4. testa uma função de produto e encontra um problema antes de ele chegar ao cliente;

5. orienta um aluno que depois consegue seu primeiro emprego na área.

Misturar tudo em um contador único é útil para gamificação. Ajuda a motivar participação, distribuir badges e criar uma sensação de movimento.

Mas não basta para afirmar que a capacidade técnica do ecossistema aumentou.

No jargão Bellacosa, é como somar SUBMIT, RC=0, RC=8, ABEND, RESTART, CANCEL e PURGE em uma métrica chamada “eventos do batch” e depois concluir: “A produção foi muito ativa esta semana.”

Foi ativa? Possivelmente.

Foi saudável? Ninguém sabe.

Foi útil? Depende.

Foi melhor do que a semana anterior? Cadê os dados?

6. Alcance, participação, contribuição e impacto não são sinônimos

Esta é uma das lições mais importantes para qualquer pessoa que trabalha com comunidade, educação ou tecnologia.

Camada	Pergunta certa
Alcance	Quantas pessoas tiveram contato com o conteúdo?
Participação	Quantas voltaram e interagiram?
Contribuição	Quantas produziram algo útil para outras pessoas?
Aprendizagem	Quantas desenvolveram conhecimento verificável?
Resultado	Quantas aplicaram isso no trabalho, carreira ou produto?
Impacto	O que melhorou de forma mensurável no ecossistema?

Uma live com 50 mil visualizações é alcance.

Um grupo com 1.500 membros é comunidade potencial.

400 pessoas registrando atividades é participação.

Um artigo técnico, uma palestra ou uma mentoria podem ser contribuição.

Uma pessoa que conclui uma trilha e entende o assunto demonstra aprendizagem.

Uma pessoa que entra em uma função, ajuda a manter um ambiente, reduz um incidente ou substitui conhecimento que estava indo embora com uma aposentadoria demonstra resultado.

O “skills gap” não é fechado no momento em que alguém ganha um badge. Ele começa a ser fechado quando uma organização ganha capacidade técnica sustentável.

E isso é difícil de medir. Muito mais difícil do que contar visualizações ou pontos.

7. O caso Bellacosa: aqui a fotografia muda

Agora entra uma evidência prática de como advocacy pode ser mais profundo do que uma campanha trimestral.

Um educador técnico que mantém aproximadamente 50 mil seguidores somados em LinkedIn, YouTube, X/Twitter, Instagram, Blogspot, WhatsApp, Telegram e Facebook possui alcance potencial. Isso, sozinho, não significa 50 mil especialistas IBM Z — e seria desonesto dizer que significa.

Mas o alcance não está sozinho.

Há milhares de postagens, dezenas de vídeos, um blog com conteúdo técnico acessível a qualquer hora, histórias de CPD, explicações de COBOL, CICS, Db2, JCL, VSAM, RACF e z/OS, além de uma narrativa que não trata o mainframe como relíquia empoeirada nem como panfleto corporativo.

Há também ensino formal.

Desde 2022, mais de 500 alunos passaram por aulas de pós-graduação e cursos livres no INEFE. Como SME em um programa IBM Brasil, há atuação direta com um público estimado em aproximadamente 100 profissionais e clientes — estimativa honesta, pois o consolidado oficial não foi disponibilizado pela IBM.

Somam-se 60 horas de webaulas ao vivo, 30 horas de conteúdo gravado e materiais de apoio criados para os alunos.

Isso é uma diferença enorme.

Uma postagem pode ser vista e esquecida.

Uma aula ao vivo permite dúvida, contexto, conversa, correção de rota e aquele momento em que alguém finalmente entende por que DISP=(NEW,CATLG,DELETE) não é feitiçaria, mas também não é coisa para copiar sem pensar.

Uma aula gravada é ainda mais interessante: ela transforma horas de professor em capacidade educacional reutilizável.

O professor deixa de ser apenas uma CPU atendendo uma turma em tempo real e passa a criar uma espécie de “batch educacional”: o conteúdo continua processando novos alunos mesmo quando a aula original já acabou.

Clouseau chamaria isso de “automação pedagógica de alto risco”, derrubaria a câmera e depois ficaria satisfeito com a definição.

8. O poder do português: a porta de entrada que muita gente esquece

A maior vantagem desse modelo está na língua portuguesa.

Para quem está começando, mainframe já chega com uma coleção de barreiras:

• conceitos antigos e profundamente técnicos;

• documentação extensa;

• inglês técnico;

• siglas em toda frase;

• ferramentas que parecem menos amigáveis que um terminal de aeroporto dos anos 1980;

• histórias de produção que assustam mais do que animam;

• a sensação de que tudo é “para gente que já nasceu sabendo”.

Se o aluno precisa primeiro vencer o inglês técnico para depois descobrir o que é um dataset, o funil fica cruel:

$$\text{inglês técnico} \rightarrow \text{entendimento da documentação} \rightarrow \text{entendimento de mainframe}$$

Quando alguém explica em português, com analogias, exemplos, humor e contexto local, o caminho fica mais humano:

$$\text{entendimento inicial em português} \rightarrow \text{confiança} \rightarrow \text{vocabulário técnico} \rightarrow \text{documentação oficial em inglês} \rightarrow \text{autonomia}$$

A meta não é substituir a documentação IBM. Ela continua fundamental. Mensagens de erro, manuais, Redbooks, documentação de produto, certificações e debates globais continuarão usando muito inglês.

A meta é evitar que o inglês seja uma catraca na entrada.

Uma pessoa pode começar entendendo em português por que um S0C7 acontece, por que um VSAM tem organização própria, por que um RC=8 não é necessariamente fim do mundo e por que RACF não foi colocado ali apenas para irritar desenvolvedores.

Depois, com confiança, ela lê o manual oficial e reconhece os conceitos. A língua deixa de ser muro e vira ferramenta.

9. Como provar impacto sem cair na própria armadilha do denominador

Aqui vem a parte prática.

Se você quer demonstrar impacto em uma candidatura Champion 2027, não precisa alegar que representa todo o mainframe brasileiro. Nem precisa transformar seguidor em aluno, aluno em profissional e profissional em “caso de sucesso” sem evidência.

O caminho mais forte é montar um dossiê honesto, com números em camadas.

Passo 1 — Registre alcance

Anote os números por canal:

• seguidores;

• visualizações;

• alcance mensal;

• acessos do blog;

• vídeos publicados;

• artigos produzidos;

• crescimento ao longo do ano.

Mas não pare aí. Alcance é a porta, não a casa.

Passo 2 — Registre participação educacional

Aqui entram os dados que já possuem muito peso:

• mais de 500 alunos no INEFE desde 2022;

• aproximadamente 100 participantes e clientes no programa IBM Brasil, como estimativa;

• 60 horas de aulas ao vivo;

• 30 horas de aulas gravadas;

• materiais de apoio produzidos;

• assuntos cobertos;

• turmas e períodos de atuação.

Isso já permite dizer algo muito mais sólido que “publiquei bastante”.

Passo 3 — Separe conteúdo de transformação

Tente guardar mensagens e evidências, sempre respeitando a privacidade dos alunos, de pessoas que digam coisas como:

• “Comecei a estudar COBOL depois do seu artigo.”

• “Entendi JCL depois da sua aula.”

• “Usei seu material para me preparar para uma entrevista.”

• “Consegui concluir uma trilha.”

• “Entrei em estágio, projeto ou função relacionada.”

• “Passei a entender melhor o ambiente da empresa.”

Não é preciso fabricar grandes histórias heroicas. Cinco depoimentos concretos e autorizados podem valer mais que cem frases genéricas de “conteúdo incrível”.

Passo 4 — Mostre permanência

O conteúdo público, especialmente no blog, possui uma qualidade que a campanha momentânea não tem: ele permanece.

Um artigo sobre Db2 publicado hoje pode ser encontrado por alguém daqui a dois anos. Uma explicação sobre GDG pode salvar uma tarde de estudo. Uma história sobre CPD pode fazer o estudante perceber que mainframe não é uma tecnologia morta, mas uma infraestrutura com memória, responsabilidade e consequências reais.

O seu acervo é patrimônio educacional em construção.

Passo 5 — Conte a história com precisão

Uma apresentação forte para Champion 2026 poderia dizer:

Desde 2022, atuo na formação de profissionais em mainframe e tecnologias IBM, alcançando mais de 500 alunos em programas de pós-graduação e cursos livres no INEFE. Como Subject Matter Expert em iniciativa da IBM Brasil, contribuí com aproximadamente 60 horas de webaulas ao vivo, 30 horas de conteúdo gravado e materiais de apoio para um público estimado em cerca de 100 profissionais e clientes.

Paralelamente, mantenho uma presença educacional independente em português, com aproximadamente 50 mil seguidores somados em múltiplos canais, milhares de publicações e dezenas de vídeos. Meu trabalho reduz a barreira inicial do inglês técnico e torna conceitos de IBM Z, COBOL, z/OS, CICS, Db2, JCL, RACF, VSAM e operação mais acessíveis a estudantes e profissionais brasileiros.

Meu objetivo é criar uma ponte sustentável entre a experiência prática acumulada no mainframe e a próxima geração de profissionais que precisará manter, modernizar e evoluir essas plataformas.

Isso não é fumaça de marketing. É um caso documentável.

10. Easter egg: a pergunta que Clouseau finalmente acertou

No final da investigação, o Inspetor Clouseau encontra uma sala cheia de dashboards, badges e gráficos com setas apontando para cima.

Ele olha para o responsável e pergunta:

“Então vocês têm 1.000 atos de advocacy?”

“Sim, inspetor!”

“E quantas pessoas aprenderam algo que conseguem usar?”

“Bem…”

“E quantas entraram no mercado?”

“Bem…”

“E quantas continuam na área um ano depois?”

Silêncio.

Clouseau sorri, esbarra no cabo do projetor, apaga a apresentação inteira e diz:

“Aha! O criminoso não era o número. Era a conclusão que ele estava tentando esconder.”

É essa a lição.

Advocacy não é quantidade de posts, badges ou palmas. É capacidade de abrir portas, explicar o que parecia impossível, dar contexto, criar confiança e ajudar alguém a avançar.

Quando isso acontece em português, com conteúdo público, ensino estruturado, experiência prática e continuidade, o impacto deixa de caber em um leaderboard.

Ele aparece no aluno que entende.

E, anos depois, talvez apareça no profissional que está diante de uma tela verde às duas da manhã, vê um RC=8, respira fundo e pensa:

“Calma. Eu sei por onde começar.”

Nesse momento, sem foguete, sem confete e sem precisar de outra medalha digital, o ecossistema ficou um pouco mais forte.

 

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.