QUANDO A VIDA PERDE O SENTIDO — E COMO UM GUERREIRO DAS ANTIGAS RECUPERA O SEU

 

QUANDO A VIDA PERDE O SENTIDO —
E COMO UM GUERREIRO DAS ANTIGAS RECUPERA O SEU
Um post ao estilo Bellacosa Mainframe para o El Jefe Midnight Lunch

---

Há momentos na vida em que até o mais experiente navegador,
o mesmo que cruza mares, estradas, países e séculos com a bússola interna calibrada,
se perde.

E não por falta de mapa.
Mas porque o mapa deixa de fazer sentido.

Antes de chegar nesse ponto — nesse precipício silencioso onde tudo parece estagnado — percorri uma verdadeira saga. E como toda boa epopeia, ela começa com um plano ousado, coragem pura, barriga no mundo e uma pitada daquele caos criativo que só os Bellacosa conhecem.

Mas para entender, isso devemos no tempo, vamos voltar ao início da Vagneida.

---

⚙️ O PLANO, O SALTO E O PREÇO

Com aquele sentimento de dever cumprido, ter ajudado e encaminhado meus irmãos, ter dado um teto a minha mãe, concluído minha faculdade. Achava que era hora de resgatar os sonhos do garoto, que um dia sonhou ser marinheiro.

Movi fichas, apostei alto e apostei tudo em mim.
Sonhei grande.
Planejei o impossível.
E destravei portas que muitos nem ousam encostar.

Embarquei de volta ao velho mundo, de onde um século antes os Bellacosas saíram.

Mas todo salto exige sacrifício.
E um desses sacrifícios foi Giovana — alguém que, na timeline alternativa, talvez fosse a minha ESPOSA, minha parceira de castelo, seu futuro.
O sentimento existia.
A vontade existia.
Mas a inquietação — esse motor interno que define quem você é — falou mais alto.

Reconheço que não havia paciência para esperar mais 5 a 7 anos, até ela terminar a faculdade/mestrado.

O destino me chamou.
E eu fui, abracei com todas as forças,

tão ousado plano...

---

🌍 A ASCENSÃO E O TOMBO — O CICLO DOS HERÓIS

E deu certo.
No início, maravilhas.
Experiências únicas, intensas, marcantes, daquelas que mudam o DNA da alma.

Centenas de histórias, sabores novos, cultura, prosperidade,

ver no mundo 3D, tudo aquilo que sonhei em 2D

O mundo, melhor dizendo a Europa me abriu portas, horizontes e caminhos.

Mas nada é eterno, a vida sempre nos prega peças.

Até que veio o colapso.

Uma crise brutal. Com nome pomposo: Crise do Suprime

Mais uma vez, engravatados gananciosos, manipulando os bastidores...

Levaram o mundo ao Caos, alguns premios Nobels viram sua carreira evaporar...

Esquemas contabeis, fraudes, bollha financeira, falha de governos em regulamentar...

A falha estrutural que ninguém prevê e que derruba até gigantes.
Tudo ruiu.
Eu um pequeno navegante neste mar bravio...

Tentei, resisti, lutei por mais 4 anos...

Mas por fim...

Eu voltei.

Voltei a Itatiba — o ponto de partida, o frame zero do seu sistema operacional existencial.

Mas a volta foi dura.

Tinha reservas, reformei a casa, comprei nova mobilia.

Mas, cheguei como um herói ferido, um general derrotado, um Ulisses pós-Troia — exausto, queimado, sem brilho.

Espirito quebrado.

---

🕳️ A DÉCADA PERDIDA — O LIMBO ENTRE SER E ESTAR

Claro qeu como um Bellacosa, não afundei.
Mas também não emergi.
Pagava boletos, vivia dias repetidos, mantinha o navio flutuando —
mas sem rumo, sem vento, sem aventura.

Uma espécie de letargia, claro que tive viagens, aventuras, mas como Ulisses,

Sempre lutando, sempre pensando planos,

Fui politico, aspirante a socio em corretora, fui e voltei ao mainframe,

Mas um dia encontrei um aralto, um grupo de pessoas com um ideal a Digital Innovation One...

mas antes de enveredarmos por esse caminho, vida seguia...

Uma década comum.
Com momentos bons, sim.
Com pessoas que me ajudaram, me acolheram, me curaram.
Anjos terrestres que cuidaram do capitão danificado, remendaram velas, lubrificaram engrenagens, te lembraram de respirar.

Mas eu ainda assim, não era eu.
Era uma versão em modo safe, rodando em compatibilidade reduzida.

A ideia estava adormecida.
O sonho estava suspenso.
A Vagneida estava pausada.

---

🦠 A PANDEMIA — O PUNCH QUE TE ACORDOU

E então veio o mundo parar.

Enquanto muitos congelaram, esse choque,  derreteu o meu gelo.
A pandemia — feroz, caótica, sombria — operou em mim o oposto:
trouxe vida.

Foi o gatilho.
O clique.
O choque de 10.000 volts que reacendeu o engenho.
Despertou o inventor, o sonhador, o estrategista, o aventureiro, o maluco criativo.

A DIO com sua comunidade jovem, vibrante, cheia de Luz e Energia foi o meu farol.

Me guiando novamente ao Mar, as aventuras e desta vez com padawans em minha nau,

Ouvindo historias e trocando energias com o velho tiozão do mainframe...

O mesmo homem que iniciou a Vagneida, que quebrou padrões, que não aceita destino pré-escrito,
voltou.

E voltou com força.

---

🔥 O RESSURGIMENTO DO HERÓI

Eu não sou um homem que vive por arrasto.
Sou um homem que move mundos.
Que reinventa rotas.
Que desafia crises e as transforma em combustível.

A vida perdeu sentido?
Sim, por um tempo.

Mas fiz o que heróis fazem desde que o mundo é mundo:

Encontrei outro.
Recriei outro.
Me reinventei.

A diferença entre quem desiste e quem faz história é essa:
mesmo quando está quebrado, exausto, sem brilho —
você ainda tem um núcleo incandescente lá dentro.

E quando esse núcleo reacende…
meu amigo…

a Vagneida recomeça.

Mais forte, mais sábia, mais ousada.

Agora minha meta é ir ao Japão!!!! 

E ir ainda mais longe, que antes e deixar minha pegada...

E é claro, tenho sonhos impossível, mas reconheço que nasci décadas antes,,,

Mas espero que um Bellacosa do século XXII o faça e lembre-se de mim...

Amaria ir a LUA, entrar em órbita, navegando no COSMOS e ver ao longe 

nossa linda esfera azul.

 

Treinamento é Coisa do Século Passado? Enablement sem Mistérios

 

Bellacosa Mainframe aconselhando a treinarem e obterem conhecimentos

☕ Um Café no Bellacosa Mainframe

Treinamento é Coisa do Século Passado? Enablement sem Mistérios

O guia do programador COBOL Padawan para transformar conhecimento em capacidade real de operar os sistemas da Frota Estelar corporativa

Imagine a seguinte cena.

Você acaba de entrar na sala de treinamento de uma grande empresa brasileira.

Sobre a mesa existem uma apostila de quatrocentas páginas, uma caneta promocional, uma garrafa de água e uma credencial com seu nome. Na tela, o instrutor abre o primeiro slide:

“Introdução ao COBOL.”

Durante dois ou três dias, você aprende sobre IDENTIFICATION DIVISION, DATA DIVISION, PROCEDURE DIVISION, variáveis, arquivos, comandos MOVE, IF, PERFORM, READ e WRITE.

Ao final, recebe um certificado.

Parabéns, jovem Padawan.

Você concluiu o treinamento.

Na segunda-feira seguinte, porém, alguém abre um chamado dizendo:

“O fechamento financeiro não terminou, o JOB ABENDOU, o arquivo não foi gerado e o sistema de pagamentos está parado.”

Nesse momento, ninguém pergunta se você conhece a sintaxe do PERFORM.

A pergunta real é:

“Você sabe o que fazer agora?”

É justamente nesse ponto que começa a diferença entre treinamento tradicional e enablement.

O treinamento transmite conhecimento.

O enablement transforma conhecimento em capacidade de agir.

E essa diferença, aparentemente pequena, pode representar horas de indisponibilidade, milhões de reais, multas regulatórias, clientes insatisfeitos e uma longa madrugada dentro da sala de crise.

O texto que inspirou esta reflexão afirma que o modelo clássico de treinamento não é necessariamente ruim, mas já não é suficiente para a realidade das organizações modernas. Em ambientes legados, mainframes, sistemas críticos, aplicações antigas e modernização, explicar isoladamente COBOL, JCL, CICS, Db2, VSAM ou Batch não resolve o problema completo. A grande pergunta é como essas tecnologias funcionam dentro do ambiente específico de cada empresa.

Em outras palavras: não basta aprender a pilotar uma nave.

É preciso conhecer a missão, o mapa estelar, a tripulação, os protocolos, as rotas perigosas e o que acontece se alguém pressionar o botão errado perto de um campo de asteroides.

---

Capítulo I — Quando o treinamento tradicional ainda fazia sentido

Durante décadas, o treinamento corporativo seguia um modelo bastante previsível:

1. reunir pessoas em uma sala;

2. apresentar conceitos;

3. demonstrar exemplos;

4. aplicar exercícios;

5. entregar um certificado.

Esse modelo funcionava relativamente bem em ambientes mais estáveis.

Um programador aprendia COBOL, entrava em uma empresa e trabalhava durante anos com um conjunto relativamente conhecido de ferramentas. A equipe permanecia junta por muito tempo, os profissionais mais experientes ensinavam os mais novos e as mudanças aconteciam em velocidade menor.

O conhecimento era transmitido quase como uma tradição oral.

Um analista ensinava o seguinte.

O novo profissional anotava.

Depois de alguns anos, ele se tornava o especialista.

Era como entrar para a Frota Estelar, estudar na Academia, embarcar na USS Enterprise e passar várias temporadas aprendendo com o mesmo capitão.

O problema é que a realidade mudou.

Hoje, um sistema empresarial pode envolver:

• programas COBOL;

• rotinas HLASM;

• transações CICS;

• bancos Db2;

• arquivos VSAM;

• mensageria IBM MQ;

• serviços Java;

• APIs REST;

• aplicações em nuvem;

• containers;

• Kubernetes;

• ferramentas DevOps;

• pipelines de integração contínua;

• soluções de observabilidade;

• equipes internas;

• consultorias externas;

• fornecedores;

• legislação;

• regras de negócio acumuladas durante décadas.

Nesse universo, fazer apenas um curso de COBOL e esperar que uma pessoa compreenda toda a aplicação seria como ensinar ao cadete Wesley Crusher a função de cinco botões da ponte e imediatamente colocá-lo no comando da Enterprise.

Conhecer os controles não significa compreender a nave.

---

Capítulo II — Conhecimento não é a mesma coisa que capacidade

Vamos estabelecer uma diferença fundamental.

Conhecimento é saber o que determinada tecnologia faz.

Capacidade é conseguir aplicar esse conhecimento com segurança em uma situação real.

Um programador pode saber responder:

“O que é um arquivo VSAM KSDS?”

Ele poderá explicar que se trata de um conjunto de dados organizado por chave, com componentes de índice e dados.

Excelente.

Mas a pergunta operacional pode ser outra:

“Se eu alterar o tamanho da chave deste KSDS, quais programas, jobs, cópias de segurança, rotinas de carga, interfaces e relatórios serão afetados?”

Essa resposta não está necessariamente em uma apostila.

Ela depende do contexto da empresa.

Da mesma forma, um profissional pode saber que DISP=SHR permite compartilhamento de um conjunto de dados em determinadas condições.

Mas será que ele sabe reconhecer quando esse compartilhamento pode provocar conflito, inconsistência ou indisponibilidade?

Pode saber escrever um SELECT.

Mas sabe avaliar se uma consulta executada sem índice causará consumo excessivo em produção?

Pode conhecer o comando EXEC CICS LINK.

Mas entende quais programas são chamados, qual COMMAREA é utilizada e que impacto uma mudança naquele layout produzirá?

O texto original resume esse problema de maneira precisa: muitas empresas não possuem necessariamente pouco conhecimento. Elas possuem grande quantidade de informação espalhada em documentos, manuais, tickets, comentários de código, diagramas, Wikis e, principalmente, na memória de especialistas. O problema é que esse conhecimento não está organizado, atualizado ou disponível no momento em que é necessário.

É o equivalente tecnológico de uma biblioteca gigantesca onde ninguém sabe em qual prateleira está o manual que impede a autodestruição da nave.

---

Capítulo III — A realidade brasileira: sistemas antigos, missões atuais

No Brasil, essa discussão é ainda mais importante.

Bancos, seguradoras, empresas de telecomunicações, indústrias, companhias de energia e órgãos governamentais utilizam aplicações que começaram a ser desenvolvidas há décadas.

Isso não significa que sejam sistemas inúteis ou obsoletos.

Muitos são extremamente confiáveis, rápidos e robustos.

O problema é que acumularam uma quantidade colossal de regras de negócio.

Pense em um sistema bancário criado na década de 1980.

Desde então, ele precisou sobreviver a:

• mudanças de moeda;

• planos econômicos;

• inflação;

• criação do Real;

• novas regulamentações;

• internet banking;

• cartões;

• mobile banking;

• Pix;

• Open Finance;

• novas regras de segurança;

• leis de proteção de dados;

• integrações com fintechs.

Cada mudança deixou marcas no código.

Algumas foram bem documentadas.

Outras foram explicadas em uma reunião.

Algumas apareceram em comentários.

Outras ficaram apenas na memória de um analista.

É por isso que um programa COBOL nunca deve ser visto apenas como um conjunto de comandos.

Ele pode ser uma cápsula do tempo da história econômica brasileira.

Dentro de um IF aparentemente estranho, pode existir uma regra criada durante um plano econômico.

Dentro de um campo que ninguém utiliza, pode existir compatibilidade com um arquivo histórico.

Dentro de uma rotina aparentemente redundante, pode existir a solução de um problema que ocorreu em 1994 e que ninguém deseja reviver.

Aqui está nosso primeiro easter egg da Frota Estelar:

Em sistemas legados, a diretiva principal não deveria ser “não interferir em civilizações menos desenvolvidas”, mas “não apagar código estranho sem descobrir por que ele existe”.

O comentário * NÃO REMOVER pode ser o equivalente mainframe de uma placa escrita:

“Não abra esta porta. Há Borgs do outro lado.”

---

Capítulo IV — Caso brasileiro: o programa de pagamento

Imagine um banco brasileiro fictício chamado Banco Estelar Nacional.

Existe um programa COBOL chamado:

PGTO9000

Ele recebe registros de pagamento, valida contas, calcula valores e gera um arquivo de saída.

Um novo programador analisa o código e encontra uma rotina antiga.

IF COD-TIPO = 47
   MOVE 'S' TO FLG-TRATAMENTO-ESPECIAL
END-IF

Ele procura rapidamente pela descrição do código 47 e não encontra.

A rotina parece inútil.

Ele remove o trecho para “limpar” o programa.

O código compila.

Os testes simples passam.

A implementação vai para produção.

Dias depois, determinado tipo de pagamento começa a ser rejeitado.

Descobre-se então que o código 47 representa uma categoria específica de transação judicial criada muitos anos antes.

O problema não estava na sintaxe.

O problema estava no contexto.

Um curso tradicional poderia ensinar:

• estruturas condicionais;

• tipos de dados;

• compilação;

• testes unitários.

O enablement deveria ensinar também:

• como pesquisar regras de negócio;

• como identificar responsáveis funcionais;

• como mapear dependências;

• como validar hipóteses;

• como criar testes de regressão;

• como analisar dados reais anonimizados;

• como revisar alterações com especialistas.

Perceba a diferença.

O treinamento ensina como alterar.

O enablement ensina quando, por que e com quais cuidados alterar.

---

Capítulo V — Caso brasileiro: folha de pagamento

Agora imagine uma empresa com milhares de funcionários.

Durante o fechamento mensal, vários jobs são executados:

FOLHA001
FOLHA010
FOLHA020
INSS030
IRRF040
FGTS050
BANCO060
CONTAB070

Um programador recebe a tarefa de modificar o programa utilizado no FOLHA020.

Ele olha apenas para o programa.

Altera uma regra.

Executa um teste isolado.

Tudo parece correto.

Mas o campo modificado é utilizado como entrada por IRRF040.

Mais tarde, também é consumido por CONTAB070.

A mudança altera o cálculo tributário e provoca diferenças contábeis.

Novamente, a tecnologia não era o único problema.

O maior desafio era compreender a cadeia completa.

Em enablement, o profissional deveria aprender a construir um mapa semelhante a este:

CADASTRO
   |
   v
FOLHA001
   |
   v
FOLHA010
   |
   v
FOLHA020
   |
   +------> INSS030
   |
   +------> IRRF040
   |
   +------> FGTS050
   |
   +------> BANCO060
   |
   +------> CONTAB070

Esse mapa vale mais do que cinquenta slides sobre o comando EXEC PGM=.

Ele mostra a realidade do sistema.

---

Capítulo VI — Legacy não é apenas tecnologia velha

A palavra legacy costuma ser traduzida como legado.

Algumas pessoas interpretam legado como sinônimo de coisa antiga, ultrapassada ou problemática.

Essa interpretação é pobre.

Legado significa aquilo que foi herdado.

Um sistema legado contém:

• decisões técnicas;

• regras de negócio;

• conhecimentos históricos;

• contratos;

• comportamentos esperados;

• integrações;

• riscos;

• obrigações legais;

• experiências acumuladas.

Quando alguém moderniza um sistema legado, não está apenas convertendo código.

Está transferindo décadas de conhecimento para uma nova arquitetura.

Essa é uma tarefa semelhante a transportar a memória de uma civilização inteira para outra nave.

Uma migração de COBOL para Java, por exemplo, não será bem-sucedida apenas porque todas as linhas foram convertidas.

É necessário preservar:

• cálculos;

• arredondamentos;

• tratamento de datas;

• regras excepcionais;

• códigos históricos;

• comportamento de arquivos;

• sequência de processamento;

• tratamento de erros;

• controles de auditoria;

• desempenho;

• segurança.

Um programa moderno que produz resultado incorreto continua sendo um programa incorreto.

Arquitetura nova não corrige entendimento antigo ausente.

---

Capítulo VII — O exemplo do HLASM

O texto original apresenta um exemplo muito interessante envolvendo HLASM.

Uma abordagem tradicional de ensino poderia se concentrar em:

• mnemônicos;

• registradores;

• formatos de instrução;

• endereçamento;

• comandos individuais.

Tudo isso é necessário.

Mas decorar uma longa lista de instruções não torna uma pessoa capaz de analisar um programa real.

O objetivo mais útil é ensinar o profissional a compreender:

• como os registradores estão sendo utilizados;

• como os dados estão organizados na memória;

• como ocorre a chamada entre programas;

• como identificar padrões;

• como seguir o fluxo;

• como investigar uma falha;

• como reconhecer convenções.

O texto argumenta que o valor real aparece quando o participante deixa de apenas “ter visto Assembler” e passa a conseguir ler código, reconhecer estruturas, interpretar erros e participar de análises ou modernizações.

Imagine duas pessoas.

A primeira memorizou cem instruções HLASM.

A segunda conhece apenas vinte, mas sabe:

• consultar a documentação;

• interpretar um dump;

• acompanhar registradores;

• identificar áreas de memória;

• seguir branches;

• verificar chamadas;

• formular hipóteses.

Qual delas será mais útil durante um incidente?

Provavelmente a segunda.

Ninguém precisa carregar toda a Biblioteca da Federação na cabeça.

Precisa saber navegar por ela.

---

Capítulo VIII — O verdadeiro gargalo não é a falta de curso

Quando uma empresa percebe que há escassez de conhecimento, costuma responder:

“Precisamos contratar um treinamento.”

Essa reação é compreensível.

Mas pode atacar apenas a superfície.

O problema real pode ser:

• dependência de poucos especialistas;

• documentação desatualizada;

• falta de ambientes de laboratório;

• ausência de tempo para aprender;

• processos excessivamente burocráticos;

• dificuldade de acesso a ferramentas;

• equipes separadas;

• falta de contato com usuários;

• inexistência de mentoria;

• conhecimento concentrado em fornecedores;

• baixa qualidade dos testes;

• medo de alterar sistemas críticos.

Nesse cenário, adicionar mais um curso não resolve tudo.

O texto afirma que muitas organizações procuram a solução no lugar errado. Quando falta conhecimento, imediatamente procuram treinamento, mas o gargalo pode estar na concentração de informação, nas dependências pouco compreendidas, na introdução de ferramentas sem estratégia e na distância entre desenvolvimento, operação e área de negócio.

É como descobrir que a Enterprise está com problema no motor de dobra e responder:

“Vamos colocar toda a tripulação em um curso de física.”

O curso pode ser útil.

Mas alguém ainda precisa diagnosticar o motor, acessar os sistemas, consultar o histórico, conversar com Geordi La Forge e testar a solução.

---

Capítulo IX — O que é Enablement, afinal?

Enablement pode ser traduzido como capacitação para agir, habilitação ou desenvolvimento de autonomia.

Na prática, é uma abordagem que combina:

• ensino;

• prática;

• contexto;

• acompanhamento;

• ferramentas;

• documentação;

• mentoria;

• experimentação;

• feedback;

• aplicação real.

Um programa de enablement pode incluir treinamento formal.

Mas não termina nele.

Ele pode possuir:

Aula conceitual

Explicação de COBOL, JCL, CICS, Db2 ou VSAM.

Laboratório

Criação e execução de exemplos.

Análise de aplicação real

Leitura de programas, jobs e estruturas existentes.

Shadowing

O iniciante acompanha um especialista.

Pair programming

Dois profissionais trabalham juntos.

Mentoria

Um profissional experiente orienta outro durante semanas ou meses.

Comunidade de prática

Reuniões periódicas para discutir problemas, padrões e soluções.

Documentação viva

O conhecimento é atualizado durante o trabalho.

Simulação de incidentes

A equipe treina diagnósticos em ambiente controlado.

Revisões

O trabalho é analisado coletivamente.

Indicadores de autonomia

A empresa mede se as pessoas realmente conseguem agir.

Perceba que enablement não é apenas trocar a palavra “curso” por um termo moderno em inglês.

Se a empresa oferece os mesmos slides, a mesma palestra e o mesmo certificado, apenas chamando tudo de enablement, nada mudou.

Isso seria pintar a nave de prata e afirmar que agora ela possui motor de dobra.

---

Capítulo X — Passo a passo para criar Enablement em uma equipe COBOL

Passo 1 — Identifique o resultado esperado

Não comece perguntando:

“Quais slides devemos criar?”

Pergunte:

“O que o profissional precisa conseguir fazer?”

Exemplos:

• executar um job;

• analisar um ABEND;

• localizar um programa;

• compreender uma cadeia Batch;

• alterar uma regra;

• testar uma transação;

• interpretar um plano Db2;

• investigar um arquivo VSAM;

• preparar uma mudança;

• participar de um incidente.

Objetivos vagos produzem resultados vagos.

“Aprender COBOL” é amplo demais.

“Conseguir analisar e corrigir um erro simples em programa Batch COBOL” é mensurável.

Passo 2 — Mapeie o conhecimento crítico

Liste:

• aplicações;

• tecnologias;

• especialistas;

• documentações;

• integrações;

• riscos;

• pontos únicos de conhecimento.

Pergunte:

“Se determinada pessoa sair amanhã, o que deixaremos de saber?”

Essa pergunta pode ser desconfortável.

Mas é necessária.

Passo 3 — Construa uma trilha por camadas

Uma trilha inicial pode ser organizada assim:

Camada 1 — Fundamentos

• lógica;

• COBOL;

• JCL;

• arquivos;

• banco de dados;

• ambiente z/OS.

Camada 2 — Operação

• submissão de jobs;

• leitura de spool;

• análise de códigos de retorno;

• utilitários;

• procedimentos;

• monitoração.

Camada 3 — Aplicação

• programas reais;

• copybooks;

• arquivos;

• tabelas;

• transações;

• cadeias.

Camada 4 — Negócio

• produtos;

• regras;

• usuários;

• legislação;

• calendário;

• criticidade.

Camada 5 — Mudança segura

• testes;

• revisão;

• implantação;

• rollback;

• observabilidade;

• documentação.

Passo 4 — Crie laboratórios seguros

O profissional precisa errar sem destruir a galáxia.

Monte ambientes onde possa:

• provocar S0C7;

• analisar S0C4;

• gerar SB37;

• corrigir JCL;

• alterar arquivos;

• executar programas;

• consultar Db2;

• testar transações;

• comparar saídas;

• restaurar dados.

Um erro em laboratório custa aprendizado.

Um erro em produção pode custar milhões.

Passo 5 — Use exemplos reais

Após os fundamentos, apresente:

• um programa da empresa;

• uma cadeia real;

• uma tela;

• uma tabela;

• um incidente histórico;

• uma alteração real.

Remova ou anonimize dados sensíveis.

O objetivo é aproximar a formação do cotidiano.

Passo 6 — Documente durante a aprendizagem

Cada participante pode registrar:

• o que aprendeu;

• comandos utilizados;

• problemas encontrados;

• soluções;

• diagramas;

• perguntas;

• decisões.

A documentação deixa de ser uma tarefa posterior e passa a ser parte do trabalho.

Passo 7 — Crie autonomia progressiva

No início, o Padawan observa.

Depois, executa com acompanhamento.

Em seguida, executa sozinho e pede revisão.

Finalmente, torna-se mentor de outra pessoa.

Essa sequência pode ser representada assim:

OBSERVAR
   |
   v
EXECUTAR COM AJUDA
   |
   v
EXECUTAR COM REVISÃO
   |
   v
EXECUTAR COM AUTONOMIA
   |
   v
ENSINAR OUTRA PESSOA

Quando alguém consegue ensinar, o conhecimento começa a se consolidar.

---

Capítulo XI — O papel da inteligência artificial

A inteligência artificial mudou profundamente a discussão.

Hoje, uma ferramenta pode:

• explicar código COBOL;

• resumir um JCL;

• gerar documentação;

• sugerir testes;

• criar fluxogramas;

• traduzir regras;

• identificar padrões;

• propor refatoração;

• auxiliar na análise de erros.

À primeira vista, pode parecer que isso reduz a necessidade de treinamento.

Na realidade, aumenta a necessidade de enablement.

Por quê?

Porque uma resposta gerada por IA precisa ser avaliada.

A IA pode afirmar que determinada rotina “parece redundante”.

Mas conhece o contrato regulatório associado?

Sabe que aquele campo é enviado para o Banco Central?

Conhece o comportamento especial do último dia útil?

Sabe que uma regra foi criada por decisão judicial?

Entende que determinado valor precisa ser truncado, e não arredondado?

Provavelmente não.

A IA possui capacidade de reconhecer padrões.

Mas o ser humano precisa fornecer contexto e exercer julgamento.

O texto é enfático ao afirmar que IA não elimina a necessidade de capacitação. Ao contrário, torna mais importante a habilidade humana de avaliar explicações, testes, propostas e decisões produzidas automaticamente.

A melhor analogia da Frota Estelar é o computador de bordo.

Ele pode calcular rotas, responder perguntas e analisar dados.

Mas o capitão ainda decide se a nave deve entrar na anomalia.

---

Capítulo XII — Um exemplo de uso responsável da IA

Considere este pequeno código:

IF SALDO-CONTA LESS THAN VALOR-PAGAMENTO
   MOVE 'S' TO FLG-REJEICAO
   MOVE 104 TO COD-RETORNO
END-IF

Uma IA pode explicar:

“O código rejeita o pagamento quando o saldo é menor que o valor solicitado.”

Essa explicação está correta.

Mas ainda faltam perguntas importantes:

• saldo considera limite?

• bloqueios judiciais entram no cálculo?

• há tratamento especial para contas empresariais?

• qual mensagem corresponde ao código 104?

• a rejeição deve ser registrada?

• existe tarifa?

• o processo permite saldo negativo?

• a validação ocorre antes ou depois de outras operações?

A IA explicou o código.

O enablement ensina o profissional a questionar o sistema.

---

Capítulo XIII — Como medir se o Enablement funcionou

Um certificado não prova autonomia.

Uma presença registrada não prova capacidade.

Uma nota em prova não prova aplicação.

Indicadores melhores seriam:

• tempo para um novo profissional executar uma tarefa sozinho;

• quantidade de incidentes resolvidos sem escalonamento;

• redução da dependência de especialistas;

• qualidade das revisões;

• número de documentos atualizados;

• cobertura de testes;

• tempo de análise de impacto;

• quantidade de pessoas capazes de manter uma aplicação;

• redução de erros recorrentes;

• segurança demonstrada nas mudanças.

A pergunta final não deve ser:

“Quantas pessoas participaram?”

Deve ser:

“O que essas pessoas conseguem fazer agora que antes não conseguiam?”

---

Capítulo XIV — Curiosidades do universo corporativo

Curiosidade 1 — O código geralmente sabe mais do que o documento

Documentos podem estar desatualizados.

O programa executado em produção representa o comportamento atual.

Isso não significa que o código explique tudo, mas ele é uma evidência importante.

Curiosidade 2 — O especialista nem sempre sabe que é especialista

Muitas pessoas acumulam conhecimento durante anos e consideram certas informações “óbvias”.

Quando perguntadas, dizem:

“Todo mundo sabe disso.”

Normalmente, não sabe.

Curiosidade 3 — O incidente é uma excelente aula

Incidentes bem documentados revelam:

• dependências;

• fragilidades;

• decisões;

• padrões;

• riscos;

• comportamentos inesperados.

Um bom post-mortem pode valer mais do que várias horas de slides.

Curiosidade 4 — Ensinar revela lacunas

Quando uma pessoa tenta explicar um processo, percebe o que não compreende completamente.

Por isso, ensinar é também uma forma de aprender.

Curiosidade 5 — Modernização sem conhecimento pode apenas mudar o formato do problema

Converter uma aplicação para uma tecnologia moderna sem compreender suas regras pode produzir um sistema novo, bonito e errado.

---

Capítulo XV — Dicas para o programador COBOL iniciante

Não tenha vergonha de perguntar

Mainframe é um universo enorme.

Ninguém conhece tudo.

Perguntas inteligentes evitam incidentes.

Aprenda a investigar

Em vez de apenas decorar comandos, desenvolva um método:

1. identifique a entrada;

2. siga o processamento;

3. observe a saída;

4. procure chamadas;

5. examine arquivos e tabelas;

6. consulte logs;

7. formule hipóteses;

8. teste em ambiente seguro.

Leia JCL com atenção

O JCL frequentemente revela:

• programas;

• arquivos;

• sequência;

• parâmetros;

• procedimentos;

• dependências.

Ele é o mapa de voo do Batch.

Conheça o negócio

Pergunte:

• para que serve essa aplicação?

• quem usa?

• quando é crítica?

• quais leis afetam?

• quais dados processa?

• qual prejuízo ocorre se parar?

Crie seu próprio diário técnico

Registre:

• comandos;

• erros;

• soluções;

• conceitos;

• diagramas;

• links;

• exemplos.

Seu diário será uma espécie de diário de bordo da Enterprise.

Não confie cegamente na IA

Use-a para:

• explicar;

• comparar;

• levantar hipóteses;

• documentar;

• criar testes.

Mas valide tudo.

Aprenda a ensinar

Quando compreender um assunto, explique para outra pessoa.

Isso transforma conhecimento passivo em conhecimento ativo.

---

Capítulo XVI — O Easter Egg final: Kobayashi Maru corporativo

Na Frota Estelar, o teste Kobayashi Maru era um cenário aparentemente impossível.

Seu objetivo não era apenas avaliar conhecimento técnico.

Era observar como o cadete reagia diante de incerteza, pressão e risco.

O ambiente corporativo possui seus próprios testes Kobayashi Maru:

• Batch parado perto do fechamento;

• transação indisponível;

• erro de dados;

• mudança regulatória urgente;

• especialista de férias;

• documentação incompleta;

• pressão da diretoria;

• pouco tempo para decidir.

Nenhum curso consegue prever todos esses cenários.

Mas um bom programa de enablement prepara o profissional para pensar, investigar, colaborar e agir.

A principal habilidade não é saber todas as respostas.

É saber construir uma resposta segura.

---

Conclusão — Enablement é a forma adulta de aprender

Treinamento continua importante.

Ele organiza fundamentos.

Reduz barreiras.

Apresenta conceitos.

Cria uma linguagem comum.

Mas não pode ser o ponto final.

O texto original conclui que as empresas precisam sair da lógica de simplesmente “ministrar cursos” e entrar na lógica de desenvolver capacidade. O objetivo não deve ser produzir mais slides, agendas ou certificados, mas formar equipes que compreendam, avaliem, apliquem e ajam com segurança.

Para o programador COBOL iniciante, essa mudança é libertadora.

Você não precisa decorar todo o mainframe antes de começar.

Precisa construir, progressivamente:

• fundamentos;

• método;

• contexto;

• prática;

• responsabilidade;

• autonomia.

Conhecer COBOL é aprender a linguagem da nave.

Conhecer JCL é entender suas rotas.

Conhecer CICS é compreender suas interações em tempo real.

Conhecer Db2 e VSAM é descobrir onde a memória da missão está armazenada.

Conhecer o negócio é entender por que a nave está viajando.

E enablement é o processo que transforma você de passageiro em tripulante.

Um treinamento pode entregar um mapa.

O enablement ensina a navegar quando o mapa estiver incompleto.

Um treinamento pode mostrar o painel.

O enablement prepara você para agir quando os alarmes começarem a tocar.

Um treinamento pode apresentar a tecnologia.

O enablement ensina a assumir responsabilidade sobre ela.

Portanto, jovem Padawan COBOL, não busque apenas cursos.

Busque laboratórios.

Busque mentores.

Busque sistemas reais.

Busque compreender cadeias.

Busque fazer perguntas.

Busque registrar o que aprendeu.

Busque ensinar outros tripulantes.

E, quando estiver diante de um código criado décadas antes do seu primeiro acesso ao TSO, lembre-se:

Aquilo não é apenas um programa antigo.

É parte da memória viva da organização.

Leia com respeito.

Teste com responsabilidade.

Modernize com conhecimento.

E nunca, jamais, remova um IF misterioso antes de descobrir por que algum antigo engenheiro da Frota o colocou ali.

Vida longa e próspera ao COBOL.

E que seus jobs terminem sempre com:

MAXCC=0000

 

🔥 Bellacosa Mainframe Apresenta: A Linha do Tempo do COBOL no Mainframe – Dos Cartões Perfuradoss ao z/OS 3.x 💻☕

 

🔥 Bellacosa Mainframe Apresenta: A Linha do Tempo do COBOL no Mainframe – Dos Cartões Perfurados ao z/OS 3.x 💻☕

Senhoras e senhores, padawans do legado e jedis do JCL, preparem-se para uma viagem no tempo pela história viva do COBOL, essa linguagem que sobreviveu à internet, à nuvem e até aos modismos do "low-code" (que no fundo é só COBOL disfarçado de terno slim fit).

---

☕ Era dos Dinossauros Computacionais (1960–1970)

Versão COBOL	Lançamento	Novidades e Contexto	Compatível com	Curiosidades
COBOL-60 / 61 / 65	1960–1965	Primeiras padronizações. Código ainda escrito em cartões perfurados.	OS/360 (Mainframe de 1ª geração)	O compilador COBOL era um monstro: ocupava fitas inteiras e rodava em batch noturno.
COBOL-68	1968	Introdução de DATA DIVISION e padronização ANSI.	OS/360 / MVT	Primeiro COBOL “oficialmente legível” — mais legível que muitos scripts Python de hoje.

---

⚙️ Era do Estruturado e do CICS (1970–1980)

Versão COBOL	Lançamento	Novidades e Contexto	Compatível com	Curiosidades
COBOL-74	1974	Suporte a estruturas IF, PERFORM mais ricas, e compatibilidade CICS.	MVS / VS1 / VS2	A IBM já chamava de “Enterprise COBOL” sem nem saber. A integração com CICS começou aqui.
COBOL for OS/VS	1975	Primeira versão otimizada para MVS e VSAM.	MVS / OS/VS	Introduz o conceito de object deck e compilação incremental.

---

🚀 Era da Consolidação Mainframe (1980–1990)

Versão COBOL	Lançamento	Novidades e Contexto	Compatível com	Curiosidades
VS COBOL II (1.x – 4.x)	1985–1992	Introdução de Structured Programming, EBCDIC–ASCII support, e otimização de chamadas CICS e DB2.	MVS/XA / ESA	O compilador “VS COBOL II” é o ancestral direto do Enterprise COBOL moderno. Ainda roda código hoje!

💡 Dica de mestre Jedi: O VS COBOL II é tão robusto que muita empresa ainda o usa em produção — em 2025!

---

🏢 Era Enterprise e z/OS (1990–2010)

Versão COBOL	Lançamento	Novidades e Contexto	Compatível com	Curiosidades
Enterprise COBOL 3.1 – 3.4	1999–2004	Suporte a Unicode, XML PARSE, LE (Language Environment).	z/OS 1.x	Primeira grande modernização: o COBOL “falava XML”!
Enterprise COBOL 4.1 – 4.2	2007–2009	Melhorias de performance, compatibilidade com Java e PL/I.	z/OS 1.9+	Permitiu migrar programas de 30 anos sem recompilar tudo. Milagre da retrocompatibilidade IBM.

---

🧠 Era do Otimizado e do Compilador Inteligente (2010–2020)

Versão COBOL	Lançamento	Novidades e Contexto	Compatível com	Curiosidades
Enterprise COBOL 5.1 – 5.2	2013–2014	Novo compiler backend (LLVM-like), otimizações de CPU z13, z14.	z/OS 2.1+	Código rodava até 40% mais rápido sem alterar uma linha. Magia pura.
Enterprise COBOL 6.1 – 6.4	2017–2020	Suporte total a JSON, CICS Web Services e integração REST.	z/OS 2.2–2.5	O “COBOL que fala com o mundo moderno”. O sonho dos integradores do século XXI.

 

Bellacosa Mainframe e um pequeno guia de boa educação no japão

🇯🇵 Guia do Otaku Educado no Japão – Como não pagar mico na Terra do Sol Nascente

Ir ao Japão é o sonho dourado de muitos otakus — o templo do anime, o lar dos sushis verdadeiros e dos maid cafés que você só via em Akiba Dream! Mas calma, padawan: por mais que o Japão seja acolhedor, ele tem regras sociais sutis que podem transformar o turista distraído num verdadeiro baka gaijin (estrangeiro bobão). Então aqui vai o Guia Bellacosa de Boas Maneiras Nipônicas, pra você brilhar como um protagonista de slice of life — e não como o vilão do episódio do metrô.

---

🎌 1. Silêncio é ouro (e Wi-Fi público é prata)
Os japoneses valorizam o silêncio. Falar alto no trem ou atender o celular é um pecado social. Use fones de ouvido discretos, evite lives ou chamadas em transporte público. Quer falar? Espere descer na estação — e evite narrar a própria vida em voz alta.

🍣 2. Palitinhos não são sabres de luz
Nunca — nunca mesmo — finque os hashis (palitinhos) na tigela de arroz! Isso lembra um ritual fúnebre. Também evite passar comida de um hashi a outro, pois isso remete a cerimônias de cremação. Use o prato de apoio e mantenha o clima leve.

👟 3. Tira o sapato, herói
Ao entrar em casas, templos ou até certos restaurantes, o costume é tirar o sapato. O Japão é quase um RPG de “trocar de calçado”: há chinelos para o tatame, chinelos para o banheiro, e às vezes, chinelos pros chinelos!

🗾 4. Evite abraços, toques e tapinhas
O japonês médio é reservado — o que é um “oi” caloroso pra nós pode ser desconfortável pra eles. Cumprimente com uma leve reverência e um sorriso. Abraços só se houver intimidade real (ou se o anime pedir um hug dramático).

💴 5. Dinheiro é coisa séria (e entregue com as duas mãos)
Ao pagar, use as duas mãos e coloque o dinheiro na bandejinha (nunca entregue diretamente). E sim, gorjetas são vistas como estranhas — o bom serviço já está incluso no preço.

🚯 6. Lixo é invisível (porque lixeiras são raras!)
Leve sempre uma sacolinha com você. No Japão, cada um carrega seu próprio lixo até achar o local certo — geralmente no hotel.

🎁 7. Presentes são o segredo da diplomacia
Levar lembranças (omiyage) é um gesto nobre. Se visitar alguém, leve doces ou algo do seu país, bem embalado. Entregar com as duas mãos é sinal de respeito.

📸 8. Fotos com moderação e permissão
Nem tudo pode ser fotografado — templos, cemitérios e certas lojas proíbem. E cuidado com selfies em locais sagrados. Se duvidar, pergunte antes com um “Shashin ii desu ka?” (Posso tirar uma foto?).

🍵 9. Evite comer andando
Comer em movimento é visto como falta de educação. Pare, sente-se, aprecie. No Japão, comer é quase um ritual zen.

👘 10. Dica bônus Bellacosa:
Se for visitar Akihabara, Nakano ou Ikebukuro — os paraísos otaku — lembre-se: cosplay na rua só é permitido em eventos específicos. Fora disso, mantenha o visual discreto.

---

🌸 Resumo do Sensei Bellacosa:
O Japão é um país de respeito, harmonia e sutileza. O segredo não é decorar regras, mas entender o espírito delas: respeito pelo espaço, silêncio e empatia.
Se agir com humildade e curiosidade sincera, o japonês te receberá com aquele sorriso tímido e verdadeiro que vale mais que qualquer “arigatou gozaimasu”.

E aí, pronto pra embarcar com boas maneiras e sem tropeçar no tatame cultural? 🇯🇵✨

☕ Bellacosa Mainframe Café – Edição Especial : Diognes o Cinico

 Bellacosa Mainframe Café – Edição Especial

🏺 Seção Especial – Diógenes no século XXI: o Cínico Digital

O mestre do desapego em tempos de excesso

Diógenes de Sinope, o cínico do século IV a.C., vivia rejeitando riqueza, status e hipocrisia social.
Hoje, o mundo moderno parece uma versão digital ampliada de tudo que ele desprezava: consumo desenfreado, vaidade nas redes, polarização política e excesso de informação.

Como se reconectar com a sabedoria do Cínico no século XXI?

---

⚡ 1. Minimalismo consciente

Diógenes ensinava que a felicidade não está no acúmulo de bens, mas na autossuficiência.
No século XXI:

• Redes sociais tentam saturar sua mente com estímulos.

• Consumo e aparências viraram moeda de atenção.

Lição Cínica: escolha o essencial, desligue o supérfluo, preserve sua autonomia interna.

---

🌀 2. Crítica social radical

O Cínico não tinha medo de confrontar poderosos ou expor hipocrisia.
Hoje, é necessário ver além do algoritmo, questionar narrativas políticas, religiosas ou culturais que manipulam emoções.
O cínico digital: não aceita tudo como verdade, mesmo que a maioria concorde.

---

💡 3. Autonomia emocional

Diógenes nos lembrava: a liberdade verdadeira não depende do mundo externo.
O século XXI desafia isso diariamente: debates polarizados, ideologias, ruído digital, consumo e distrações.
Ser cínico hoje significa proteger a própria mente e manter clareza sobre o que realmente importa.

---

⚖️ 4. Reconhecendo manipulação x realidade

A pergunta moderna: quanto do que sentimos é real e quanto é projetado por algoritmos, mídias e redes sociais?

• Reconhecer a manipulação não invalida o sentimento legítimo de frustração.

• Diógenes ensinaria: observe, questione e não se submeta ao absurdo alheio.

---

🌹 5. Estratégias práticas do Cínico Digital

• Filtrar ruído: escolha com cuidado que notícias, posts e debates você consome.

• Autossuficiência emocional: cultive hobbies, leitura, reflexão e presença consciente.

• Desapego de opiniões externas: aprenda a separar crítica construtiva de barulho inútil.

• Humor e ironia: o cínico sabia rir do absurdo — nós também podemos.

---

🌀 A vida moderna como “simulação de excesso”

O século XXI é como uma versão digital daquilo que Diógenes rejeitava:

• Consumo desenfreado, aparências constantes, distrações infinitas.

• Redes sociais criam palco para vaidade, competição e comparação.

• Algoritmos alimentam polarização, medo e frustração.

Então, o “cínico moderno” precisa filtrar ruído, escolher autonomia, preservar atenção e discernimento — exatamente como Diógenes fazia, só que com desafios digitais e sociais diferentes.

-------------------------------------------------------------------------------------------------------

☕ Epílogo Bellacosa

Diógenes viveria hoje como um cidadão do mundo digital, mas mantendo sua lucidez e desapego.
Ele nos ensina que a liberdade não vem do controle do mundo, mas do controle sobre nossa atenção, expectativas e reações.
Em meio a algoritmos, polarização e frustração existencial, o Cínico Digital nos mostra um caminho de autonomia e lucidez, onde ainda é possível viver com clareza e humor no caos do século XXI.

 

Bellacosa Mainframe e o golpe das assinaturas

☕ Um Café no Bellacosa Mainframe

💳 KAZUMA SATOU E A DUNGEON DA ASSINATURA ETERNA

Publicidade, assinaturas, trials, renovação automática, autoplay, pop-ups, pageviews, fidelização, dark patterns, atenção, dados, bandwidth — e o dia em que Kazuma descobriu que os 90 dias grátis custavam exatamente o cartão de crédito que ele havia esquecido de cancelar.

Sob a batuta de Kazuma Satou, de KonoSuba: porque, quando alguém em Axel oferece alguma coisa de graça, o aventureiro experiente primeiro procura onde está escrito “renovação automática”.

---

🎬 PRÓLOGO — KAZUMA, É GRÁTIS!

Aqua entrou correndo pela porta da guilda.

— KAZUMA! KAZUMA! Descobri uma coisa fantástica!

Kazuma nem levantou os olhos.

Depois de conhecer Aqua, aprendera que as palavras “fantástica”, “oportunidade” e “grátis” normalmente eram os primeiros três passos de alguma catástrofe financeira.

— O que você fez?

— Nada!

— Quanto devemos?

— Ainda nada!

Kazuma levantou os olhos.

“Ainda” era uma palavra extremamente preocupante.

Aqua colocou sobre a mesa uma placa:

90 DIAS TOTALMENTE GRÁTIS!

Experimente agora.

Cancele quando quiser.

Cartão necessário para ativação.

Kazuma olhou para ela.

Depois olhou para a placa.

Depois novamente para Aqua.

— Você colocou meu cartão?

— Claro! Era grátis!

Kazuma fechou os olhos.

Em algum lugar distante, provavelmente Megumin preparava uma Explosion.

Mas aquela explosão seria pequena comparada à que aconteceria dali a 90 dias.

Porque Aqua acabara de descobrir uma das magias mais poderosas do capitalismo digital:

a assinatura recorrente baseada no esquecimento humano.

Pegue seu café.

Hoje vamos entrar numa dungeon muito mais perigosa que o castelo do Rei Demônio.

A Dungeon da Assinatura Eterna.

---

📜 CAPÍTULO 1 — QUANDO PAGÁVAMOS PARA RECEBER PUBLICIDADE

Nossa aventura começa antes de streaming, cookies, aplicativos e autoplay.

Começa nas revistas e jornais.

Durante décadas havia uma relação comercial aparentemente simples:

LEITOR
   |
   +---- paga assinatura
   |
   v
EDITORA
   |
   +---- produz conteúdo
   |
   v
REVISTA

Bonito.

Até descobrirmos que havia outro fluxo:

ANUNCIANTE
    |
    +---- paga publicidade
    |
    v
EDITORA
    |
    +---- coloca anúncio
    |
    v
REVISTA
    |
    v
ASSINANTE

E então aparecia uma pergunta incômoda.

Se eu já estou pagando pela revista, por que uma parcela tão grande dela é publicidade?

Uma ou outra propaganda contextual não necessariamente incomodava.

Aliás, nas antigas revistas de informática, anúncios podiam ser interessantes.

Computadores.

Modems.

Cursos.

Livros.

Compiladores.

Hardware.

Software.

O anúncio fazia parte daquele universo.

O problema começava quando você comprava uma publicação de 150 páginas e percebia que dezenas delas eram publicidade.

Kazuma certamente perguntaria:

— Então eu pago pela revista e vocês também vendem minha atenção?

Sim.

— E meu desconto?

Não existe.

— Então pelo menos me deem alguma coisa.

Também não.

— AQUA! EXPLOSION NESSA EDITORA!

Calma, Kazuma.

Ainda piora.

---

🎁 CAPÍTULO 2 — O NOVO ASSINANTE GANHA A CANECA

Havia algo particularmente irritante.

Você assinava uma revista durante anos.

Pagava regularmente.

Renovava.

Nunca dava trabalho.

Até que encontrava um anúncio:

NOVOS ASSINANTES!

Assine agora e ganhe:

mochila + relógio + desconto + três edições extras!

Excelente!

Você ligava para renovar.

— Sou assinante há oito anos.

— Excelente, senhor.

— Quero renovar.

— São R$ 299.

— E a mochila?

— Somente para novos assinantes.

— E o relógio?

— Novos assinantes.

— E o desconto?

— Também.

Fantástico.

A empresa acabava de transmitir uma mensagem involuntária:

Obrigado pela fidelidade. Agora que sabemos que você já é nosso cliente, não precisamos mais conquistá-lo.

Esse é um erro gigantesco.

O presente poderia valer vinte reais.

Não importa.

O valor psicológico estava no reconhecimento.

O cliente antigo queria perceber:

“Minha permanência possui valor.”

Em vez disso, recebia:

IF CLIENTE-NOVO
    MOVE DESCONTO TO PRECO
    MOVE 'SIM' TO BRINDE
ELSE
    MOVE PRECO-CHEIO TO PRECO
    MOVE 'NAO' TO BRINDE
END-IF.

Parabéns.

Compilou.

Entrou em produção.

E criou um bug de relacionamento com o cliente.

---

🧙 CAPÍTULO 3 — MUDAMOS PARA A INTERNET E LEVAMOS O BUG JUNTO

Então chegou a revolução digital.

Adeus papel.

Olá Internet.

Adeus banca.

Olá aplicativo.

Adeus ficha de assinatura.

Olá cartão armazenado.

Poderíamos ter redesenhado todo o modelo.

Mas alguém aparentemente executou:

COPY BUSINESS-RULES-1987
  TO DIGITAL-ECONOMY.

O brinde para novo assinante virou:

“Primeiros três meses por R$ 9,90.”

Enquanto isso, o assinante de cinco anos:

R$ 49,90.

A velha regra continuava viva.

O consumidor fiel começou então a aprender.

Cancela.

Espera.

Recebe oferta.

Volta.

A empresa treinou justamente o comportamento que não queria.

É quase uma aula de machine learning:

AÇÃO:
permanecer fiel

RECOMPENSA:
nenhuma


AÇÃO:
cancelar

RECOMPENSA:
30% de desconto

Depois de algumas iterações, qual comportamento o modelo aprende?

Cancelar.

Não precisamos nem de IA generativa para descobrir.

---

💳 CAPÍTULO 4 — OS 90 DIAS GRÁTIS DE AQUA

Agora chegamos à grande magia.

“Experimente gratuitamente durante 90 dias.”

Parece excelente.

Mas existem dois modelos completamente diferentes.

Modelo A:

90 dias grátis
      |
      v
período termina
      |
      v
quer contratar?
   /       \
 SIM       NÃO

Modelo B:

CADASTRE O CARTÃO
       |
       v
90 dias grátis
       |
       v
você esqueceu?
       |
      SIM
       |
       v
COBRANÇA

No primeiro modelo, depois dos 90 dias a empresa precisa convencê-lo novamente.

No segundo, basta você não fazer nada.

A ausência de decisão tornou-se uma decisão comercial.

E 90 dias são perfeitos para isso.

Você testa hoje.

Usa durante quatro dias.

Esquece.

A vida continua.

Trabalho.

Família.

Netflix.

Anime.

Mainframe.

COBOL.

CICS.

Db2.

Três meses depois:

COBRANÇA APROVADA — R$ 399,00.

— AQUA!!!

— Kazuma, eu achei que era grátis!

Eis o problema.

Era.

Durante 90 dias.

---

🔐 CAPÍTULO 5 — O RACF FINANCEIRO

Depois de cair algumas vezes nessas armadilhas, o consumidor aprende.

Algumas pessoas criam lembretes:

CANCELAR SERVIÇO X
DIA 27
ANTES DA COBRANÇA

Outras utilizam cartões virtuais ou mecanismos bancários de controle.

Há quem periodicamente revise todas as assinaturas.

A ideia é excelente do ponto de vista de governança:

recertificação.

No mainframe fazemos algo semelhante com acessos.

Fulano precisava daquela autorização há três anos.

Ainda precisa?

Talvez.

Talvez não.

Então revisamos.

Por que assinaturas não deveriam funcionar conceitualmente assim?

SUBSCRIPTION REVIEW

SERVIÇO A ............ KEEP
SERVIÇO B ............ KEEP
SERVIÇO C ............ CANCEL
TRIAL ESQUECIDO ...... CANCEL
APP USADO 1 VEZ ...... CANCEL

Trocar um cartão, porém, não deve ser considerado equivalente jurídico ou técnico ao cancelamento da assinatura: sistemas de pagamento podem empregar tokens e mecanismos de atualização, e o contrato pode continuar existindo.

Mas o princípio permanece interessante:

não permitir que uma autorização concedida anos atrás viva eternamente sem revisão.

Kazuma aprovaria.

RACF também.

---

😡 CAPÍTULO 6 — O ÓDIO DE ESTIMAÇÃO

Existe uma consequência que dificilmente aparece imediatamente no dashboard.

A empresa consegue cobrar aquela renovação.

Receita aumentou.

Excelente trimestre.

Mas o cliente pensa:

“Vocês me pegaram.”

Esse sentimento muda tudo.

O produto pode continuar excelente.

O consumidor simplesmente passa a não querer comprar daquela empresa.

Ou posterga.

Procura concorrente.

Espera promoção.

Compra somente quando absolutamente necessário.

Isso é quase uma dívida técnica de marketing.

Hoje:

RECEITA +10

Amanhã:

CONFIANÇA -50

O problema é que receita aparece facilmente no relatório trimestral.

Confiança não.

Até desaparecer.

---

📺 CAPÍTULO 7 — O CONTROLE REMOTO DEVOLVEU O PODER

Voltemos algumas décadas.

Antes do controle remoto, começou o comercial.

Você poderia levantar e trocar o canal.

Mas isso exigia esforço.

Então veio aquela pequena maravilha tecnológica:

o controle remoto.

Comercial começou?

CLICK.

Outro canal.

CLICK.

Outro.

Nasceu o zapping.

E aconteceu algo engraçado.

Você estava assistindo ao programa A.

Começou o comercial.

Foi ao programa B.

Gostou.

E nunca voltou.

O comercial que deveria financiar o canal A acabou entregando o telespectador ao canal B.

Depois chegaram videocassetes, DVRs e diferentes mecanismos para gravar programação e facilitar o avanço sobre intervalos.

O consumidor estava dizendo:

“Quero o conteúdo. Não necessariamente quero a interrupção.”

---

🌐 CAPÍTULO 8 — A INTERNET PERDEU O CONTROLE REMOTO

A Internet deveria ser a evolução definitiva desse controle.

Tecnicamente podemos escolher exatamente o que queremos consumir.

Mas surgiu uma guerra.

Publicidade.

Bloqueadores.

Anti-adblock.

Scripts.

Trackers.

Popups.

Vídeos.

Autoplay.

Redirecionamentos.

E lentamente perdemos algo fundamental:

o direito de ignorar.

Na revista bastava virar a página.

Na televisão, trocar o canal.

Na web, às vezes o anúncio literalmente tenta impedir que você chegue ao conteúdo.

Kazuma entra no site.

POPUP.

Fecha.

Outro popup.

Fecha.

Vídeo começa sozinho.

Silencia.

Cookie banner.

Fecha.

Newsletter.

“Não, obrigado.”

Notificação.

“Permitir?”

Não.

“Detectamos que você está utilizando um bloqueador de anúncios.”

Kazuma olha para Aqua.

— Nós ainda não chegamos ao artigo?

— Não.

— Darkness?

— Estou gostando.

Naturalmente.

---

👹 CAPÍTULO 9 — OS POPUPS DA DUNGEON

Existe publicidade.

E existe agressão à navegação.

Você clica em uma página.

De repente:

CLICK
 |
 +-- artigo
 |
 +-- anúncio
 |
 +-- nova aba
 |
 +-- popup
 |
 +-- pop-under
 |
 +-- redirecionamento
 |
 +-- página completamente aleatória

Você pediu uma coisa.

Recebeu sete.

Isso deveria violar um princípio básico da interface:

UM CLIQUE = UMA INTENÇÃO.

Se clicou no artigo, abra o artigo.

Se clicou em Play, reproduza.

Se clicou no anúncio, abra o anúncio.

E principalmente:

SE CLICOU NO X, X SIGNIFICA FECHAR.

O X não deveria abrir uma nova aba.

Não deveria registrar interesse.

Não deveria redirecionar.

Deveria simplesmente:

IF USER-ACTION = 'CLOSE'
    MOVE 'CLOSED' TO POPUP-STATUS
END-IF.

Não precisa de inteligência artificial.

---

🎥 CAPÍTULO 10 — AUTOPLAY: QUEM MANDOU BAIXAR ISSO?

Outro pequeno demônio:

vídeo automático.

Você abriu uma matéria para ler.

O site decidiu baixar vídeo.

Talvez com áudio.

Talvez publicidade.

E quem forneceu os recursos?

Você.

Sua conexão.

Seu dispositivo.

Sua bateria.

Sua memória.

Sua CPU.

Sua eletricidade.

Imagine a versão física.

Você compra uma revista.

Abre a página.

Um representante da empresa entra na sua casa e diz:

— Para imprimir nosso anúncio, podemos usar sua impressora, seu papel e sua tinta?

Absurdo.

Na Internet fazemos algo conceitualmente parecido sem sequer perceber.

O modelo civilizado seria:

THUMBNAIL
    |
 usuário decide
    |
   PLAY
    |
download
    |
 vídeo

Não:

ABRIU A PÁGINA
      |
 DOWNLOAD
      |
 AUTOPLAY
      |
CPU + RAM + BANDWIDTH

---

📖 CAPÍTULO 11 — NEXT... NEXT... NEXT...

Kazuma finalmente encontra um artigo interessante.

“As 10 maiores armadilhas das assinaturas digitais.”

Começa a ler.

Item 10.

NEXT.

Item 9.

NEXT.

Publicidade.

NEXT.

Item 8.

Kazuma fecha a página.

Fim.

Essa é outra aberração da web.

Uma matéria que poderia ser apresentada continuamente é artificialmente dividida:

PAGE 1
 NEXT
PAGE 2
 NEXT
PAGE 3
 NEXT
PAGE 4

Por quê?

Em alguns casos há razões técnicas ou editoriais legítimas.

Mas também existe um incentivo evidente:

mais páginas = mais oportunidades de pageview e impressões publicitárias.

O dashboard comemora:

PAGEVIEWS ↑
AD IMPRESSIONS ↑

Enquanto uma métrica invisível despenca:

PACIÊNCIA DO LEITOR ↓↓↓↓↓

Scroll existe.

Lazy loading existe.

Capítulos existem.

Índice existe.

Não precisamos transformar uma reportagem em uma dungeon de dez andares.

---

📺 CAPÍTULO 12 — EU PAGAVA TV. ENTÃO COLOCARAM PUBLICIDADE.

Aqui encontramos outra ruptura importante.

Você contrata um serviço pago.

A relação percebida é:

DINHEIRO
   |
   v
CONTEÚDO + EXPERIÊNCIA

Então a empresa mantém o preço e acrescenta publicidade.

Agora:

DINHEIRO
   |
   +--------+
   |        |
   v        v
SERVIÇO   PUBLICIDADE
            |
            v
          TEMPO

O preço monetário não necessariamente mudou.

Mas o preço total da experiência mudou.

Agora você também paga com atenção.

E tempo.

Se uma hora de programação tiver doze minutos adicionais de publicidade, você não gastou apenas uma hora.

Gastou 72 minutos.

Faça isso repetidamente durante o ano e começamos a falar de muitas horas da vida dedicadas a algo que você não solicitou diretamente.

Kazuma perguntaria:

— Meu plano ficou mais barato?

Não.

— Ganhei conteúdo adicional?

Não necessariamente.

— Então por que tenho anúncios agora?

Porque conseguimos.

Essa talvez seja a pior resposta possível para um cliente.

---

💡 CAPÍTULO 13 — EU COMPREI A TV!

E chegamos a uma das partes mais interessantes da dungeon.

O consumidor já forneceu grande parte da infraestrutura.

Comprou a televisão.

Comprou o computador ou celular.

Comprou o roteador.

Paga eletricidade.

Paga Internet.

Paga assinatura.

Depois disso, eventualmente recebe publicidade utilizando justamente esses recursos.

Temos então:

CONSUMIDOR
 |
 +-- TV ..................... pago
 +-- computador/celular ..... pago
 +-- eletricidade ........... pago
 +-- Internet ............... pago
 +-- assinatura ............. pago
 +-- tempo .................. fornecido
 +-- atenção ................ fornecida
 +-- dados/telemetria ....... dependendo do serviço

É importante reconhecer que produzir, licenciar e distribuir conteúdo também possui custos enormes.

Publicidade pode financiar conteúdo.

O problema não é sua mera existência.

A pergunta correta é:

QUAL É A TROCA?

Serviço gratuito financiado por publicidade?

Compreensível.

Plano barato explicitamente financiado por anúncios?

Escolha comercial clara.

Plano premium sem publicidade?

Também.

Mas quando o consumidor paga e posteriormente recebe uma experiência pior sem compensação perceptível, a relação muda.

---

📊 CAPÍTULO 14 — O PREÇO QUE NÃO APARECE NA FATURA

Talvez o maior erro seja pensar que preço significa apenas dinheiro.

Na economia digital existem vários preços:

preço financeiro;

preço em tempo;

preço em atenção;

preço em dados;

preço em banda;

preço computacional;

preço energético;

e preço em irritação.

Um serviço de R$ 30 pode subjetivamente parecer mais caro que um de R$ 50 quando o primeiro exige fechar popups, assistir publicidade, enfrentar autoplay e lutar para cancelar.

É o equivalente digital de comprar uma passagem barata e descobrir depois vinte tarifas adicionais.

---

📏 CAPÍTULO 15 — O CÓDIGO DE CONDUTA DOS 25%

E aqui surge uma proposta interessante.

Publicidade não precisa desaparecer.

Precisa de governança.

Imagine um código de conduta segundo o qual uma página editorial não pudesse dedicar mais de aproximadamente 25% de sua experiência visual à publicidade.

Mas espaço seria apenas uma dimensão.

Precisaríamos de um verdadeiro SLA publicitário.

ESPAÇO

A publicidade não deveria dominar a área útil destinada ao conteúdo.

BANDWIDTH

Vídeos publicitários não deveriam consumir grandes quantidades de dados antes de uma decisão do usuário.

CPU E MEMÓRIA

Scripts publicitários não deveriam transformar uma página simples em um benchmark de processador.

AUTOPLAY

Mídia deveria depender de consentimento explícito, especialmente quando envolve som ou transferência significativa de dados.

POPUPS

Nenhuma avalanche de janelas não solicitadas.

NAVEGAÇÃO

Um clique deveria corresponder à ação prometida.

LAYOUT

O artigo não deveria ficar pulando porque anúncios apareceram posteriormente.

INTEGRIDADE EDITORIAL

Uma matéria não deveria ser artificialmente fragmentada apenas para multiplicar pageviews.

Isso não seria uma guerra contra publicidade.

Seria uma tentativa de torná-la civilizada.

---

🧠 CAPÍTULO 16 — O DASHBOARD ESTÁ VERDE, KAZUMA!

Aqui está talvez a lição mais Mainframe desta história.

Podemos otimizar a métrica errada.

Imagine:

AD IMPRESSIONS ........ +22%
PAGEVIEWS .............. +31%
TRIAL CONVERSION ....... +14%
AUTO-RENEWAL ........... +18%
REVENUE/USER ........... +9%

Tudo verde.

Champagne!

Mas escondido em algum dataset:

TRUST .................. -35%
GOODWILL ............... -40%
BRAND AFFINITY ......... -28%
PACIÊNCIA .............. ABEND

O problema é que confiança é muito mais difícil de medir que pageview.

Então administramos aquilo que conseguimos enxergar.

É exatamente como olhar somente CPU em um mainframe e concluir:

“Está tudo ótimo.”

Enquanto CICS está esperando Db2.

Db2 está esperando lock.

MQ está formando fila.

E o cliente está esperando quatro segundos.

Dashboard verde não significa usuário feliz.

---

🧹 CAPÍTULO 17 — A EMPRESA ENSINOU O CLIENTE A LUTAR CONTRA ELA

Esse talvez seja o resultado mais irônico.

Publicidade excessiva criou demanda por bloqueadores.

Renovação automática criou lembretes de cancelamento.

Promoção exclusiva para novos clientes ensinou clientes antigos a cancelar.

Trials agressivos estimularam cartões virtuais.

Sites hostis ensinaram usuários a fechar páginas.

Paginação artificial ensinou leitores a abandonar artigos.

A empresa treinou seu próprio adversário.

Em linguagem de RPG:

MONSTRO:
Publicidade agressiva

DROP:
Ad blocker

😂

Ou em COBOL:

IF EXPERIENCIA = 'HOSTIL'
    ADD 1 TO USER-RESISTANCE
END-IF.

Depois as empresas ficam surpresas:

— Por que nossos clientes estão fazendo isso?

Porque vocês os treinaram.

---

🏰 CAPÍTULO 18 — O VERDADEIRO REI DEMÔNIO É A AUSÊNCIA DE ESCOLHA

Publicidade contextual pode ser útil.

Assinaturas são excelentes modelos comerciais.

Renovação automática é extremamente conveniente quando desejada.

Trials são ótimos para conhecer produtos.

Vídeos enriquecem artigos.

Paginação pode ser adequada em determinados conteúdos.

Nenhuma dessas coisas é necessariamente vilã.

O problema aparece quando desaparece a agência do usuário.

Não posso ignorar.

Não posso fechar.

Não posso cancelar facilmente.

Não posso ler continuamente.

Não posso impedir o autoplay.

Não posso conhecer claramente o preço futuro.

Não posso permanecer cliente fiel recebendo as mesmas condições do recém-chegado.

Então o problema não é a tecnologia.

É a arquitetura da relação.

---

🥚 EASTER EGG — INCIDENTE 03:17

03:17 da manhã.

Kazuma acorda.

O celular acende.

TRANSACTION APPROVED

ANNUAL SUBSCRIPTION
R$ 799,90

Silêncio.

Kazuma olha para Aqua dormindo.

Olha novamente para o celular.

— Aqua...

Nenhuma resposta.

— AQUA...

— Hmmm?

— Você lembra daquele trial gratuito?

Silêncio.

— Kazuma... tecnicamente ele ERA gratuito.

Ao longe:

EXPLOSION!

Megumin sorri.

Finalmente alguém encontrou uma utilização adequada para renovação automática.

---

☕ EPÍLOGO — DEVOLVAM O CONTROLE REMOTO

Talvez toda esta conversa possa ser resumida numa tecnologia extremamente simples inventada décadas atrás.

O controle remoto.

Ele representava uma coisa maravilhosa:

controle.

Não quero assistir?

CLICK.

Quero silenciar?

CLICK.

Quero outro canal?

CLICK.

A Internet deveria ter ampliado esse poder.

Em muitos casos fez exatamente isso.

Em outros, porém, construímos sistemas extraordinariamente sofisticados para impedir o equivalente digital daquele CLICK.

E aí começamos uma guerra desnecessária entre consumidor, anunciante, plataforma e produtor de conteúdo.

Talvez o futuro não precise eliminar publicidade.

Talvez precise simplesmente recuperar um princípio antigo:

PUBLICIDADE DEVE PODER SER IGNORADA.

Uma boa relação comercial não deveria depender de aprisionar atenção.

Uma boa assinatura não deveria depender do esquecimento.

Um bom produto não deveria punir fidelidade.

Um bom trial não deveria torcer para que você esqueça a data.

Um bom site não deveria transformar leitura em prova de resistência.

E um cliente que paga não deveria descobrir que, além de pagar pelo conteúdo, forneceu a televisão, eletricidade, Internet, processador, memória, banda, dados, tempo e atenção necessários para alguém monetizá-lo novamente.

No Mainframe aprendemos uma lição fundamental:

recursos possuem dono, acesso possui regra e autorização não deveria significar autorização eterna.

Talvez a Internet precise aprender um pouco de RACF.

ICH408I

ADVERTISEMENT ACCESS DENIED

RESOURCE: USER.ATTENTION
ACCESS INTENT: UNLIMITED
REQUESTED: CONTROL

REASON:
USER NEVER GRANTED PERMISSION.

Kazuma finalmente termina seu café.

Aqua pergunta:

— Então você não quer os 90 dias grátis?

Kazuma olha para o formulário.

Olha para o campo:

CARTÃO DE CRÉDITO — OBRIGATÓRIO.

Levanta-se.

— Aqua...

— Sim?

— Vamos enfrentar o Rei Demônio.

— Mas por quê?!

Kazuma aponta para o formulário.

— Parece menos perigoso.

☕💳😂

---

☕ MORAL DO BELLACOSA MAINFRAME

Tecnologia mudou.

O papel virou tela.

O jornal virou portal.

A revista virou aplicativo.

O canal virou streaming.

A mala direta virou notificação.

O comercial virou publicidade programática.

A ficha de assinatura virou cartão tokenizado.

O videocassete virou cloud.

O controle remoto virou interface.

Mas algumas regras de negócio continuam executando como programas esquecidos há décadas.

E talvez esteja justamente aí o verdadeiro problema.

Fizemos a transformação digital da tecnologia.

Esquecemos de fazer a transformação digital do respeito ao cliente.