Pontos de Função: um pouco sobre métricas. Parte I

Agora nossa agenda conta com 163 cursos gratuitos em diversas tecnologias, para animar ainda mais novos bootcamps e acelerações é muita notícia fantástica, hoje meu trabalho esta próximo do limiar, este é o artigo 99° escrito com muito carinho, uma retribuição a nossa comunidade por tanta coisa recebida, da minha parte venho enriquecer um pouco mais nosso Gruppen com velhas historias de mainframe, preparados? Agora é hora de voltar ao laptop e bora terminar de escrever sobre Ponto de Função. Leia na Integra

 

☕ Um Café no Bellacosa Mainframe

Todos os Homens do Prefeito — Quando Bellacosa Ligou a Câmera, o YouTube Sofreu um ABEND e Itatiba Descobriu que a Verdade Tinha Backup

Ou: uma nota de repúdio chegou pronta, um menor apareceu no centro de uma acusação, vinte mil pessoas receberam o log da confusão, cinquenta mil apertaram PLAY — e um programador COBOL aprendeu que narrativa política sem trilha de auditoria é apenas um arquivo sequencial escrito por quem chegou primeiro.

---

Prólogo — A redação, a garagem e a câmera que não deveria estar ali

Em All the President’s Men, dois repórteres seguem pistas, conferem versões, protegem fontes e descobrem que o poder não teme apenas denúncias. O poder teme documentos que possam ser verificados por alguém de fora do círculo oficial.

Nossa história não se passa em Washington, não começa no edifício Watergate e não tem uma fonte misteriosa fumando num estacionamento subterrâneo. Ela acontece em Itatiba, no interior de São Paulo, entre 2016 e 2019, dentro e ao redor de uma Câmara Municipal onde situação e oposição travavam suas batalhas políticas semanais.

No lugar dos repórteres do Washington Post, havia um suplente do PMDB conhecido como Vagner Bellacosa. No lugar do caderninho, uma câmera digital. No lugar de uma máquina de escrever, YouTube, Facebook e grupos de WhatsApp. E, no lugar do conselho “siga o dinheiro”, o sistema parecia sussurrar:

Siga a sequência dos acontecimentos.

Bellacosa frequentava as sessões da Câmara quase toda quarta-feira. Não era um observador invisível: tinha posição política, relações partidárias e acesso a muitos grupos locais. Mas carregava algo que se tornaria mais importante que qualquer discurso — a capacidade de registrar o evento inteiro.

Esse detalhe parece banal numa época em que todos possuem celular. Não era. Uma câmera na posição correta funciona como o SYSLOG de um ambiente político: ela não elimina conflitos, mas dificulta que alguém reescreva o processamento depois do RETURN-CODE.

---

1. Quando o incidente aconteceu, a narrativa já estava compilada

Segundo o relato de Bellacosa, houve uma discussão entre grupos ligados à oposição e à situação. O confronto era essencialmente verbal. Entretanto, pessoas dispostas a criar confusão teriam sido colocadas no ambiente, entre elas um menor de idade. Em algum momento surgiu a acusação de que o menor havia levado um golpe.

A engrenagem começou a funcionar depressa.

Havia a suposta vítima. Havia testemunhas. Houve registro na delegacia. E a prefeitura publicou rapidamente uma nota de repúdio, já assinada, condenando o episódio.

Rapidez, sozinha, não prova planejamento. Uma assessoria pode redigir uma nota em pouco tempo. Da mesma forma, coincidência não é evidência automática de conspiração. Um bom analista precisa separar três campos:

• aquilo que está documentado;

• aquilo que foi testemunhado;

• aquilo que é inferido a partir dos indícios.

Essa separação é tão importante na política quanto em COBOL. Se um campo PIC X(10) contém texto, não devemos tratá-lo como PIC 9(10) apenas porque gostaríamos de somá-lo. Fato, testemunho e hipótese possuem formatos diferentes.

Ainda assim, a combinação era politicamente devastadora. O acusado enfrentava uma narrativa completa: menor agredido, testemunhas, ocorrência policial, posicionamento oficial e provável repercussão no jornal. Em circunstâncias normais, a versão inicial ganharia velocidade antes que a defesa conseguisse calçar os sapatos.

O problema para os autores da narrativa era que existia um log independente.

Bellacosa havia filmado o acontecimento.

Não apenas o segundo mais barulhento. Não somente a reação de alguém. O contexto estava registrado: aproximações, posições, movimentos, falas, antes e depois. A câmera estava no lugar certo.

Em investigação, continuidade vale ouro. Um corte de oito segundos pode transformar defesa em ataque, ironia em ameaça e reação em provocação. Uma sequência longa permite reconstruir a ordem dos eventos.

Para o programador iniciante, é a diferença entre receber apenas a mensagem ABEND S0C7 e possuir também o dump, o offset, o conteúdo dos campos e o job log completo.

---

2. A nota oficial era o relatório; o vídeo era o dump

Uma nota de repúdio é uma interpretação institucional. Pode ser sincera, precipitada ou deliberadamente orientada. Ela organiza os acontecimentos numa estrutura compreensível para o público: vítima, agressor, ato condenável e resposta da autoridade.

O vídeo não era neutro no sentido filosófico — toda câmera possui posição, enquadramento e limitações. Porém, fornecia elementos verificáveis que a nota não controlava.

Uma testemunha dizia ter visto um golpe? O vídeo permitia localizar o segundo, verificar a distância e observar o movimento. Alguém afirmava que a agressão surgiu do nada? A gravação mostrava o que ocorreu antes. Uma versão omitia a provocação? A linha do tempo a recuperava.

O documento não precisava dizer “a prefeitura está errada”. Bastava tornar impossível sustentar determinados detalhes sem enfrentar as imagens.

Essa é uma lição fundamental sobre evidência digital:

A prova mais poderosa nem sempre é aquela que acusa. Muitas vezes é aquela que obriga todas as versões a caberem na mesma linha do tempo.

Em sistemas corporativos, chamamos isso de rastreabilidade. Uma transação financeira séria deixa identificadores, horários, usuário, terminal e estados intermediários. Se cada departamento puder escrever sua própria versão sem correlação, não existe auditoria — existe literatura criativa.

Na política local, o vídeo de Bellacosa introduziu um TIMESTAMP que ninguém conseguia editar por decreto.

---

3. O jornal chegou à banca; a réplica já estava em produção

Aqui começa a parte que as antigas estruturas de comunicação demoraram a compreender.

Bellacosa participava de numerosos grupos de WhatsApp de Itatiba. Mal o jornal impresso chegou às bancas, o vídeo já estava carregado no YouTube e compartilhado com aproximadamente vinte mil pessoas. Os destinatários fizeram aquilo que redes distribuídas fazem melhor: replicaram.

O vídeo original alcançou cerca de cinquenta mil visualizações.

Antes da internet, a contestação dependeria do mesmo porteiro que havia publicado a acusação. Seria necessário pedir espaço no jornal, aguardar a edição seguinte, negociar tamanho, título e posição. Quando a correção aparecesse, a acusação já teria se transformado em memória coletiva.

WhatsApp e YouTube eliminaram essa janela de controle.

O YouTube funcionou como repositório. O WhatsApp, como middleware de distribuição. Os cidadãos, como nós de replicação. O vídeo não precisava convencer todos os habitantes; precisava chegar rapidamente às pessoas interessadas no assunto e permitir que elas próprias comparassem as versões.

Para um aluno COBOL, podemos representar o processamento assim:

ENTRADA: acontecimento filmado
VALIDAÇÃO: sequência integral e contexto
ARMAZENAMENTO: upload no YouTube
DISTRIBUIÇÃO: grupos de WhatsApp
REPLICAÇÃO: encaminhamentos dos usuários
SAÍDA: pressão pública por correção

A prefeitura acabou emitindo uma nota corrigindo o texto. Mais importante: a pessoa acusada utilizou o vídeo na própria defesa durante o inquérito. Como a gravação continha o acontecimento, a acusação não avançou e o envolvido foi inocentado, conforme o relato de Bellacosa.

O vídeo deixou de ser apenas conteúdo político. Tornou-se elemento defensivo com consequência concreta.

---

4. Quando não foi possível refutar o arquivo, tentaram provocar DELETE

A história poderia terminar com a correção. Não terminou.

O primeiro upload sofreu uma campanha de denúncias no YouTube. Algumas pessoas alegavam “violência gratuita”. Outras afirmavam que aquilo “não era real”. As reclamações eram incompatíveis: se a violência era real e gratuita, o vídeo não podia simultaneamente ser uma fabricação completa.

Essa inconsistência sugere que a preocupação central não era classificar corretamente o conteúdo. O objetivo aparente era encontrar qualquer regra capaz de retirá-lo do ar.

O nome moderno desse comportamento é brigading: um grupo coordenado ou convergente aciona em massa os mecanismos de denúncia de uma plataforma. É uma espécie de DDoS burocrático. Em vez de sobrecarregar um servidor com pacotes, sobrecarrega-se a moderação com reclamações.

Bellacosa precisou contestar e lutar para manter o material disponível. O link que sobrevive atualmente corresponde a um segundo upload.

Aqui aparece uma das vulnerabilidades centrais da internet regulada por plataformas: a assimetria.

• Denunciar exige alguns cliques.

• Defender exige contexto, documentos, recursos e persistência.

• A remoção pode ser imediata.

• A restauração pode chegar depois que o interesse público desapareceu.

Se a plataforma teme multas pesadas por manter conteúdo denunciado, mas enfrenta pouca consequência por remover injustamente uma publicação legítima, seu algoritmo escolherá a precaução. Remover primeiro e analisar depois torna-se a opção economicamente racional.

É assim que uma ferramenta criada para combater violência, fraude e abuso pode ser transformada numa borracha política.

Easter egg para o operador veterano: quem nunca viu um usuário tentar resolver um problema cancelando o job errado não sabe o que é governança.

---

5. Passo a passo: como preservar uma evidência sem virar Igor da perícia

Se você presencia um acontecimento de interesse público, não basta apertar REC. A utilidade jurídica e histórica do material depende da preservação.

Passo 1 — Filme a sequência, não apenas o clímax

Quando for seguro, registre o antes, o durante e o depois. Evite interromper a gravação para produzir pequenos clipes. Contexto reduz a possibilidade de interpretação enganosa.

Passo 2 — Preserve o arquivo original

Não edite a única cópia. Mantenha o arquivo exatamente como saiu da câmera ou do celular, incluindo metadados. Produza versões separadas para publicação.

Passo 3 — Crie redundância

Use pelo menos três cópias: dispositivo original, armazenamento externo e local remoto confiável. Uma evidência guardada apenas numa plataforma pode desaparecer por denúncia, falha técnica ou perda da conta.

Passo 4 — Registre a integridade

Um hash criptográfico, como SHA-256, funciona como impressão digital do arquivo. Qualquer alteração posterior gera outro resultado. Ele não prova sozinho quem filmou, mas ajuda a demonstrar que determinada cópia não foi modificada.

Passo 5 — Documente o contexto

Anote data, horário aproximado, local, posição da câmera e pessoas capazes de confirmar a gravação. Preserve mensagens, avisos de remoção e protocolos de recurso.

Passo 6 — Proteja pessoas vulneráveis

Se houver menores, vítimas ou dados sensíveis, avalie ocultar rostos e informações na versão pública. O original deve permanecer preservado para advogado ou autoridade competente.

Passo 7 — Entregue a prova pelo canal adequado

Viralização não substitui defesa jurídica. Quando houver inquérito ou processo, o advogado deve receber o original e avaliar a forma correta de juntada.

Passo 8 — Não aceite provocações

Depois de publicar material politicamente sensível, considere que alguém poderá tentar produzir um segundo episódio contra você. Mantenha autocontrole, evite confrontos e registre ameaças pelos canais apropriados.

Em resumo: não seja Igor copiando o arquivo para VIDEO-FINAL-AGORA-VAI-3.MP4 e apagando o original para economizar espaço.

---

6. “Cuidado, o Bellacosa está presente”

Depois do episódio, Bellacosa virou uma espécie de piada interna na Câmara. Quando ele aparecia, alguém dizia:

“Olha que o Bellacosa está presente e pode te filmar.”

Era brincadeira, mas também aviso operacional.

Sua presença modificava o comportamento do ambiente. Ele havia demonstrado que sabia registrar, publicar, distribuir, enfrentar denúncias e permanecer em cena. Mesmo quando a câmera não estivesse ligada, ninguém teria certeza.

Isso é o efeito do observador aplicado à política: pessoas calculam melhor suas ações quando existe possibilidade de auditoria independente.

Ao mesmo tempo, transformar o episódio em piada ajudava a instituição a digerir o constrangimento. Era mais confortável retratar Bellacosa como “o homem da câmera” do que discutir por que uma gravação externa havia sido necessária para impedir uma acusação injusta.

Nos dias seguintes, porém, não havia apenas humor. Bellacosa comparecia às sessões com medo. Continuar indo toda quarta-feira reforçava sua posição: ele sustentava publicamente aquilo que havia publicado. Mas também se expunha a intimidação, provocação ou agressão.

Sua condição partidária oferecia alguma proteção. Como integrante do PMDB e suplente, possuía relações e custo político. Um militante de partido pequeno, isolado ou facilmente rotulado como radical talvez não tivesse o mesmo escudo.

Essa constatação impede que romantizemos a expressão “qualquer pessoa pode publicar”. Tecnicamente, qualquer pessoa pode. Nem todas conseguem suportar campanha de denúncias, pressão presencial, advogado, exposição pública e risco físico.

Liberdade formal sem proteção prática pode existir apenas para quem possui rede, recursos ou coragem para enfrentar o corredor na quarta-feira seguinte.

---

7. Eleição 2020: a hipótese da mão santa

No pleito municipal de 2020, o mesmo prefeito tentou a reeleição. Segundo Bellacosa, o político costumava brincar que Facebook não ganhava eleição.

Na reta final, Bellacosa decidiu apoiar um candidato da oposição e realizou campanha intensa dentro das regras eleitorais. Àquela altura, a rede original de aproximadamente vinte mil pessoas teria crescido em mais vinte mil depois dos acontecimentos anteriores.

O prefeito perdeu a reeleição por pouco mais de seiscentos votos.

É possível provar que Bellacosa decidiu o pleito? Não.

Não existe grupo de controle, pesquisa individual de exposição, rastreamento entre postagem e voto ou experimento capaz de isolar sua influência das demais variáveis. Alcance também não corresponde a eleitores únicos: há duplicidade, pessoas de outras cidades, apoiadores já convencidos, abstenções e mensagens nunca abertas.

Mas podemos fazer uma conta divertida.

Se quarenta mil pessoas estavam potencialmente na rede, seiscentos votos representam 1,5% desse total. Num confronto direto, quando um eleitor deixa o prefeito e escolhe o adversário, a margem se altera em dois votos: um sai de um lado e entra no outro. Em modelo extremamente simplificado, pouco mais de trezentas conversões poderiam gerar uma diferença superior a seiscentos votos.

Isso não demonstra causalidade. Mostra apenas plausibilidade.

A formulação cientificamente honesta seria:

“Não posso provar que minha mão derrubou o prefeito. Numa eleição decidida por pouco mais de seiscentos votos, ninguém também pode provar que ela foi irrelevante.”

No Boteco de Itatiba, depois de uma cerveja, essa hipótese recebe seu nome acadêmico definitivo: Teoria da Mão Santa de Bellacosa.

Correlação não é causalidade. Mas algumas correlações combinam maravilhosamente com amendoim.

---

8. O que um programador COBOL aprende com essa investigação

O iniciante costuma imaginar COBOL como linguagem de contas, arquivos e relatórios. Na realidade, sistemas confiáveis ensinam uma filosofia de responsabilidade.

Registro é diferente de narrativa

O relatório gerencial apresenta uma interpretação. O log preserva eventos. Precisamos dos dois, mas nunca devemos confundi-los.

Ordem importa

Em processamento sequencial, trocar dois registros pode alterar o resultado. Em vídeo, remover o que ocorreu antes de uma reação pode transformar completamente seu significado.

Auditoria exige independência

Se a mesma entidade pratica o ato, registra o ato, interpreta o registro e decide quem pode consultá-lo, não temos uma auditoria robusta.

Redundância protege contra falhas e interesses

Backup não serve apenas para disco quebrado. Também protege contra remoção indevida, erro humano e tentativa deliberada de apagar evidências.

Autoridade não substitui validação

Uma nota oficial merece atenção, mas não se torna verdadeira apenas porque possui brasão. Da mesma maneira, um arquivo marcado como PRODUCAO não está correto apenas porque foi colocado na biblioteca principal.

Toda automação possui viés de incentivo

Se o sistema de moderação é punido por deixar algo no ar e quase nunca por remover injustamente, ele será programado para retirar em excesso. A regra de negócio molda o algoritmo.

O operador também faz parte da segurança

Bellacosa tinha câmera, arquivo e plataforma. O elemento decisivo, contudo, foi insistir: preservar, reenviar, contestar e continuar comparecendo. Tecnologia sem operador disposto a sustentá-la vira apenas equipamento caro.

---

Epílogo — A verdade não venceu sozinha

É tentador encerrar dizendo que a verdade sempre vence. Seria bonito, cinematográfico e falso.

A verdade daquele episódio precisou de câmera posicionada corretamente, gravação contínua, arquivo preservado, upload rápido, vinte mil contatos iniciais, dezenas de milhares de visualizações, pessoas dispostas a compartilhar, recurso contra denúncias e alguém com coragem para voltar à Câmara na quarta-feira seguinte.

Ela não venceu porque possuía uma força mística. Venceu porque recebeu infraestrutura.

Essa talvez seja a maior lição para quem discute regulação da internet. Redes sociais espalham mentiras, fraudes e violência, e precisam de mecanismos responsáveis. Porém, os mesmos mecanismos de denúncia podem ser capturados por grupos organizados para retirar provas legítimas. Uma regra mal desenhada não pergunta quem está dizendo a verdade; pergunta apenas qual lado consegue produzir maior risco para a plataforma.

Uma internet livre não é uma internet sem lei. É uma internet em que remoções possuem fundamento, transparência, possibilidade de recurso e proteção especial para documentação de interesse público. É uma rede na qual autoridades também podem ser contestadas por registros independentes.

No final, o prefeito tinha nota, assessoria, testemunhas e máquina política. Bellacosa tinha uma câmera, uma conta no YouTube, grupos de WhatsApp e backup.

Anos depois, resta uma vitória moral impossível de colocar numa planilha eleitoral. Talvez sua campanha tenha influenciado cinquenta votos. Talvez trezentos. Talvez mil. Não sabemos.

Mas toda vez que a caneca toca o balcão do Boteco de Itatiba, o sistema executa novamente o mesmo pequeno programa:

       IF PREFEITO-PERDEU
          AND DIFERENCA-DE-VOTOS <= 0600
              MOVE 'MAO SANTA' TO PARECER-HISTORICO
              PERFORM BRINDE-ATE-FECHAR-O-BOTECO
       END-IF.

No rodapé do relatório, uma observação permanece piscando em verde-fósforo:

Causalidade não comprovada. Satisfação pessoal processada com sucesso.

E, em algum estacionamento escuro de Itatiba, uma voz misteriosa completa:

“Siga o log.”

 

 

 

Bellacosa Mainframe e o passo a passo ao MS Copilot

☕ Um Café no Bellacosa Mainframe

Padawan COBOL e o Copilot — Um Guia Passo a Passo para Sair do “O Que Esse Código Faz?” até “Crie, Teste e Explique a Alteração”

Ou: como usar o GitHub Copilot sem transformar o Jedi iniciante em operador de copiar-e-colar — e por que a primeira regra da Força é simples: o Copilot sugere, mas quem responde pelo código é você

Se você está começando em COBOL e ouviu falar de Copilot, é fácil imaginar duas coisas extremas.

A primeira:

“Agora não preciso mais aprender COBOL.”

A segunda:

“Se eu usar IA, nunca vou aprender de verdade.”

As duas estão erradas.

O melhor uso do Copilot para um iniciante é como instrutor auxiliar, navegador de código, explicador de sintaxe, gerador de exemplos e parceiro de testes.

Ele pode acelerar seu aprendizado.

Mas também pode acelerar seus erros.

A diferença está no método.

Então, para um Padawan COBOL, vamos seguir uma progressão segura:

ENTENDER
   ↓
EXPLICAR
   ↓
PERGUNTAR
   ↓
SUGERIR
   ↓
ALTERAR
   ↓
TESTAR
   ↓
REVISAR

Não comece pela última etapa.

Começar diretamente com:

“Faça tudo para mim”

é aproximadamente o equivalente a entregar um sabre de luz para alguém que acabou de descobrir qual lado segura.

Vamos por partes.

---

1. Primeiro passo — entenda qual Copilot você realmente quer usar

Quando falamos em programação, o produto mais relevante é o GitHub Copilot.

Ele é diferente do Microsoft 365 Copilot.

Pense assim:

Microsoft 365 Copilot
→ Word
→ Excel
→ Outlook
→ Teams
→ documentos
→ reuniões
→ trabalho corporativo

GitHub Copilot
→ código
→ IDE
→ repositório
→ testes
→ desenvolvimento

Para aprender COBOL, você provavelmente estará mais interessado no GitHub Copilot integrado a um editor ou IDE.

Exemplos comuns:

VS Code
Visual Studio
JetBrains
GitHub

No universo COBOL moderno, o VS Code é especialmente relevante quando você trabalha com extensões como:

IBM Z Open Editor
Zowe Explorer
Enterprise Developer Tools

Dependendo da sua empresa e ambiente.

---

2. Segundo passo — instale e autentique o GitHub Copilot

No VS Code, o fluxo típico é simples.

Abra:

Extensions

Procure por:

GitHub Copilot

Instale.

Depois autentique sua conta GitHub.

O editor normalmente solicitará login.

Depois disso, o Copilot pode funcionar em duas formas principais:

INLINE COMPLETION

e:

CHAT

Inline Completion significa:

você começa a escrever e ele sugere continuação.

Chat significa:

você pergunta algo diretamente.

Para aprender COBOL, recomendo começar mais pelo Chat do que pelo autocomplete.

Por quê?

Porque o Chat obriga você a formular perguntas.

E fazer boas perguntas é uma das melhores formas de aprender.

---

3. Terceiro passo — comece usando o Copilot como professor

Pegue um programa COBOL simples.

Exemplo:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLO01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-NOME PIC X(20).

       PROCEDURE DIVISION.

           MOVE 'PADAWAN COBOL' TO WS-NOME

           DISPLAY 'OLA ' WS-NOME

           STOP RUN.

Agora, em vez de pedir:

“Melhore isso.”

pergunte:

“Explique este programa linha por linha para alguém que está começando em COBOL.”

Excelente.

Depois:

“Qual é a função da IDENTIFICATION DIVISION?”

Depois:

“Por que WS-NOME usa PIC X(20)?”

Depois:

“O que aconteceria se eu usasse PIC 9(20)?”

Esse tipo de pergunta transforma Copilot em ferramenta de aprendizagem.

---

4. Quarto passo — aprenda COBOL por comparação

Uma técnica excelente é pedir comparações.

Por exemplo:

“Compare PIC X(10), PIC 9(10) e PIC S9(7)V99.”

O Copilot pode explicar:

PIC X(10)
→ texto

PIC 9(10)
→ número inteiro

PIC S9(7)V99
→ número com sinal e duas casas decimais implícitas

Depois peça exemplos.

“Mostre um exemplo de MOVE válido e inválido para cada um.”

Essa abordagem é muito mais poderosa do que decorar sintaxe.

---

5. Quinto passo — use o Copilot para entender código legado

Agora entramos no verdadeiro planeta COBOL.

Código legado.

Você recebe algo como:

       IF WS-STATUS = 'A'
           PERFORM 3000-PROCESSA
       ELSE
           MOVE 12 TO WS-RETURN-CODE
           PERFORM 9000-ERRO
       END-IF

Um iniciante pode olhar e pensar:

“O que exatamente está acontecendo aqui?”

Pergunte:

“Explique o fluxo deste trecho COBOL em linguagem simples.”

Depois:

“Quais condições levam ao PERFORM 9000-ERRO?”

Depois:

“Quais campos eu deveria investigar antes de alterar este código?”

Isso é ótimo.

Você está usando IA como navegador de fluxo.

---

6. Sexto passo — nunca pergunte só “o que isso faz?”

A melhor pergunta é:

“O que isso faz, quais premissas assume e o que pode dar errado?”

Essa diferença é enorme.

Compare:

Pergunta pobre:
"O que este código faz?"

Pergunta melhor:
"O que este código faz,
quais entradas ele espera,
quais saídas produz,
quais condições de erro existem,
e quais riscos aparecem se eu alterá-lo?"

Isso força uma análise mais completa.

---

7. Sétimo passo — peça ao Copilot para criar um mapa do programa

Para programas maiores, peça:

“Crie um mapa lógico deste programa COBOL.”

Exemplo esperado:

MAIN
 |
 +-- 1000-INICIALIZA
 |
 +-- 2000-LE-ARQUIVO
 |
 +-- 3000-PROCESSA
 |
 +-- 4000-GRAVA-SAIDA
 |
 +-- 9000-FINALIZA

Depois pergunte:

“Qual parágrafo controla o loop principal?”

Ou:

“Qual parágrafo pode alterar WS-RETURN-CODE?”

Isso ajuda muito a compreender programas antigos.

---

8. Oitavo passo — use o Copilot para aprender FILE SECTION

COBOL e arquivos são inseparáveis.

Exemplo:

       FILE SECTION.

       FD ARQ-CLIENTE.

       01 REG-CLIENTE.
          05 CLI-ID      PIC 9(8).
          05 CLI-NOME    PIC X(30).
          05 CLI-SALDO   PIC S9(7)V99.

Pergunte:

“Explique a diferença entre FD, 01 e 05.”

Depois:

“Mostre como este registro ficaria em bytes.”

Depois:

“Quantos bytes esse registro ocupa?”

Depois:

“Explique o que significa V em PIC S9(7)V99.”

Esse tipo de aprendizado é extremamente eficiente.

---

9. Nono passo — peça exemplos pequenos

Uma regra essencial para aprender com IA:

não peça um sistema inteiro.

Peça pequenos exemplos.

Ruim:

“Crie um sistema bancário COBOL.”

Bom:

“Crie um exemplo COBOL que leia um saldo, aplique uma taxa e exiba o resultado.”

Depois evolua.

PASSO 1
DISPLAY simples

PASSO 2
IF

PASSO 3
PERFORM

PASSO 4
arquivo

PASSO 5
subprograma

PASSO 6
DB2

PASSO 7
CICS

Aprendizado incremental é muito melhor.

---

10. Décimo passo — use Copilot para aprender PERFORM

PERFORM costuma confundir iniciantes.

Pergunte:

“Explique PERFORM como se eu conhecesse loops em Java ou Python.”

Depois peça exemplos:

       PERFORM 1000-PROCESSA

Depois:

       PERFORM 1000-PROCESSA
           UNTIL WS-FIM = 'S'

Depois:

       PERFORM VARYING WS-I FROM 1 BY 1
           UNTIL WS-I > 10

Compare.

Esse é um ótimo uso do Copilot.

---

11. Décimo primeiro passo — use IA para entender mensagens de compilação

Essa é uma das melhores aplicações para um Padawan.

Imagine receber:

IGYPS2121-S

Em vez de entrar em pânico, pergunte:

“Explique esta mensagem de compilação COBOL e mostre causas prováveis.”

Mas envie contexto.

Não diga apenas:

“Erro IGYPS2121-S.”

Diga:

“Estou compilando este trecho COBOL e recebi IGYPS2121-S nesta linha. Explique a provável causa sem inventar.”

Melhor ainda:

“Mostre três hipóteses e diga como validar cada uma.”

Isso transforma a resposta em troubleshooting.

---

12. Décimo segundo passo — Copilot não substitui o compilador

Aqui está uma regra gravada em pedra.

Copilot pode dizer:

“Esse código parece correto.”

O compilador diz:

ERROR

Quem ganha?

O compilador.

Sempre.

Por quê?

Porque Copilot trabalha com probabilidade.

O compilador trabalha com gramática e regras formais.

Então:

COPILOT
→ hipótese

COMPILADOR
→ evidência

Não confunda os dois.

---

13. Décimo terceiro passo — peça ao Copilot para gerar testes

Quando você já entende o código, pergunte:

“Quais cenários de teste devo criar?”

Exemplo:

       IF WS-SALDO < ZERO
           MOVE 'E001' TO WS-ERRO
       END-IF

Peça:

“Crie cenários de teste para este IF.”

Resposta esperada:

Caso 1
SALDO = 100
Resultado esperado: sem erro

Caso 2
SALDO = 0
Resultado esperado: sem erro

Caso 3
SALDO = -1
Resultado esperado: E001

Caso 4
SALDO = valor mínimo permitido
Resultado esperado: validar limite

Isso ensina uma habilidade importantíssima:

pensar em bordas.

---

14. Décimo quarto passo — peça testes antes da implementação

Essa técnica é excelente.

Antes de pedir código, diga:

“Antes de implementar, liste os testes que definem o comportamento correto.”

Isso força você e o Copilot a concordarem sobre o problema primeiro.

Fluxo ideal:

REQUISITO
   ↓
TESTES
   ↓
IMPLEMENTAÇÃO
   ↓
EXECUÇÃO
   ↓
REVISÃO

Muito melhor que:

"Código aí qualquer coisa."

---

15. Décimo quinto passo — use Copilot para revisar seu código

Depois que você escrever alguma coisa, pergunte:

“Revise este código sem reescrevê-lo.”

Isso é importante.

Porque se você disser:

“Melhore”

o Copilot pode mudar tudo.

Peça:

“Aponte erros, riscos e melhorias, mas não altere o código ainda.”

Primeiro diagnóstico.

Depois intervenção.

---

16. Décimo sexto passo — peça explicação antes da correção

Essa é uma regra maravilhosa para iniciantes.

Em vez de:

“Corrija meu programa.”

diga:

“Explique primeiro por que está errado. Depois mostre a menor correção possível.”

Assim você aprende.

Exemplo:

       MOVE 'ABC' TO WS-NUMERO

Pergunte:

“Por que isso é problemático se WS-NUMERO for PIC 9(3)?”

Depois peça correção.

Isso evita o comportamento:

CTRL+C
CTRL+V
Ctrl+Esperança

---

17. Décimo sétimo passo — aprenda SQL embutido com ajuda do Copilot

Quando entrar em COBOL + Db2, use IA como tutor.

Exemplo:

       EXEC SQL
           SELECT NOME
             INTO :WS-NOME
             FROM CLIENTE
            WHERE ID = :WS-ID
       END-EXEC.

Pergunte:

“Explique o papel das host variables.”

Depois:

“O que significa SQLCODE +100?”

Depois:

“Qual diferença entre erro de compilação COBOL e erro SQL?”

Depois:

“O que o precompiler faz?”

Isso ajuda muito a montar o mapa mental.

---

18. Décimo oitavo passo — use Copilot para explicar JCL

Padawan COBOL rapidamente encontra JCL.

Exemplo:

//JOB01    JOB ...
//STEP01   EXEC PGM=MEUPGM
//STEPLIB  DD DSN=...
//SYSOUT   DD SYSOUT=*
//ARQENT   DD DSN=...

Pergunte:

“Explique cada DD e sua relação com o programa COBOL.”

Depois:

“Qual arquivo COBOL corresponde a ARQENT?”

Isso conecta:

COBOL
ASSIGN
SELECT
FD
JCL
DD
DATASET

Esse casamento é essencial.

---

19. Décimo nono passo — use Copilot para estudar CICS sem medo

Quando chegar em CICS, não peça:

“Explique CICS.”

É amplo demais.

Pergunte:

“Explique esta instrução EXEC CICS READ.”

Depois:

“O que é RESP?”

Depois:

“Qual diferença entre LINK e XCTL?”

Depois:

“Explique COMMAREA.”

Copilot funciona melhor quando você quebra o monstro em pedaços.

---

20. Vigésimo passo — aprenda a formular prompts técnicos

Aqui está um modelo de prompt excelente.

Contexto:
Sou iniciante em COBOL.

Objetivo:
Quero entender este trecho.

Faça:
1. explique linha por linha;
2. identifique variáveis relevantes;
3. descreva o fluxo;
4. mostre possíveis erros;
5. dê um exemplo de entrada e saída;
6. não altere o código ainda.

Essa estrutura é simples e poderosa.

---

21. Um prompt Bellacosa para estudar código legado

Use:

Analise este programa COBOL como um instrutor. Primeiro descreva sua finalidade provável. Depois identifique divisions, sections, paragraphs, arquivos, copybooks, chamadas externas e variáveis importantes. Crie um mapa do fluxo principal. Explique os pontos difíceis para um iniciante. Não modifique nada. Se alguma conclusão não puder ser confirmada pelo código disponível, diga explicitamente que é uma hipótese.

Essa última frase é ouro:

“diga explicitamente que é uma hipótese.”

Porque IA adora completar lacunas.

---

22. Um prompt para debugging

Use:

Estou recebendo este erro ao compilar ou executar. Analise o código e a mensagem. Liste as causas possíveis em ordem de probabilidade. Para cada causa, mostre como validar. Não sugira alterações antes de explicar a causa.

Excelente para aprender investigação.

---

23. Um prompt para criar alteração

Quando estiver mais confiante:

Analise primeiro o impacto desta alteração. Identifique campos, paragraphs, copybooks, arquivos, SQL, chamadas externas e testes potencialmente afetados. Proponha a menor mudança possível. Explique antes de gerar o código.

Isso evita alterações espalhafatosas.

---

24. Um prompt para testes

Crie uma matriz de testes para esta regra COBOL. Inclua caminho feliz, zero, valores limites, dados inválidos, erros de arquivo, condições não encontradas e regressões possíveis. Para cada teste, informe entrada, condição e resultado esperado.

Muito útil.

---

25. Um prompt para revisão

Revise este código COBOL como um revisor sênior. Não reescreva ainda. Identifique problemas de lógica, legibilidade, tratamento de erro, risco de truncamento, tipos incompatíveis, uso de campos, loops e possíveis impactos de negócio.

Agora você começa a utilizar Copilot como mentor técnico.

---

26. O perigo do autocomplete automático

Inline suggestion é útil.

Mas para iniciantes pode virar armadilha.

Você digita:

       IF WS-STATUS =

Copilot sugere:

       IF WS-STATUS = 'A'
           PERFORM PROCESSA-ATIVO
       END-IF

Parece perfeito.

Mas de onde veio 'A'?

Talvez no seu sistema:

A = BLOQUEADO

e:

L = LIBERADO

O Copilot pode gerar código sintaticamente elegante e semanticamente errado.

Regra:

nunca aceite uma regra de negócio só porque parece plausível.

---

27. O truque Jedi: pergunte “como você sabe?”

Depois de uma resposta, pergunte:

“Que parte do código sustenta essa conclusão?”

Ou:

“Isso está explícito no código ou você inferiu?”

Esse é um truque excelente.

Ele obriga a separar:

FATO

de:

INFERÊNCIA

---

28. Nunca passe segredos

Não cole no Copilot:

senhas
tokens
chaves
credenciais
dados de clientes
dados regulados
informações sensíveis

Especialmente em ambiente empresarial, siga as políticas da organização.

O Padawan precisa dominar o sabre.

Mas também precisa saber onde não balançá-lo.

---

29. Não use Copilot para driblar revisão

Outro erro:

“Se a IA escreveu, deve estar certo.”

Não.

O correto é:

IA GERA
   ↓
VOCÊ REVISA
   ↓
COMPILA
   ↓
TESTA
   ↓
REVISA RESULTADO

Nunca:

IA GERA
   ↓
PRODUÇÃO

Essa linha deveria produzir um alarme equivalente a:

ICH408I

---

30. Um laboratório simples para começar

Crie um programa pequeno:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SALDO01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-SALDO PIC S9(5)V99 VALUE 100.00.
       01 WS-STATUS PIC X(10).

       PROCEDURE DIVISION.

           IF WS-SALDO < ZERO
               MOVE 'NEGATIVO' TO WS-STATUS
           ELSE
               MOVE 'OK' TO WS-STATUS
           END-IF

           DISPLAY WS-STATUS

           STOP RUN.

Agora siga esta sequência:

1. Peça explicação linha por linha.

2. Pergunte o que significa S9(5)V99.

3. Pergunte por que ZERO funciona.

4. Peça três testes.

5. Altere WS-SALDO manualmente.

6. Execute.

7. Compare o resultado com a previsão.

8. Peça uma melhoria.

9. Entenda a melhoria.

10. Só depois aceite a mudança.

Esse laboratório ensina COBOL e ensina a usar IA ao mesmo tempo.

---

31. Exercício Jedi 2 — arquivo sequencial

Depois faça um programa com:

INPUT
CLIENTE
SALDO
STATUS

Peça ao Copilot:

“Ajude-me a criar o layout, mas explique cada PIC.”

Depois:

“Ajude-me a montar SELECT, FD, OPEN, READ e CLOSE.”

Mas não peça tudo de uma vez.

Construa passo a passo.

Assim você aprende a ligação:

ENVIRONMENT DIVISION
        ↓
SELECT
        ↓
FILE SECTION
        ↓
FD
        ↓
READ
        ↓
JCL DD

---

32. Exercício Jedi 3 — Db2

Crie uma consulta simples.

Pergunte:

“Como transformar este SELECT em SQL embutido COBOL?”

Depois:

“Onde entra SQLCA?”

Depois:

“Como tratar SQLCODE +100?”

Depois:

“Como tratar SQLCODE negativo?”

Você estará usando Copilot não apenas para escrever.

Estará usando para construir conhecimento conectado.

---

33. Quando usar Agent Mode?

Somente depois de dominar bem o básico.

Agent Mode pode trabalhar em várias etapas.

Exemplo:

“Adicione validação de saldo negativo e crie testes.”

O agente pode:

analisar arquivos
 ↓
editar
 ↓
executar build
 ↓
rodar testes
 ↓
corrigir

Isso é poderoso.

Para iniciante, também é perigoso.

Porque várias mudanças podem acontecer sem você entender.

Use inicialmente em projetos pequenos e controlados.

---

34. Antes de usar agente, peça plano

Regra:

Planeje antes de executar.

Prompt:

“Não faça alterações ainda. Primeiro analise o repositório e mostre o plano.”

Leia o plano.

Pergunte:

“Por que precisa alterar esse arquivo?”

Depois autorize.

Esse comportamento aproxima você de engenharia profissional.

---

35. Quando o Copilot errar, comemore um pouco

Sim.

Errar pode ensinar muito.

Se ele sugerir:

       MOVE WS-TEXTO TO WS-NUMERO

e der erro, investigue.

Pergunte:

“Por que sua sugestão anterior falhou?”

Você aprende:

tipos
PIC
conversão
truncamento
data exceptions

Uma IA perfeita seria um professor pior.

Os erros criam oportunidades de debugging.

---

36. O Padawan precisa aprender a desconfiar

Uma boa relação com Copilot não é confiança absoluta.

É confiança calibrada.

Use esta escala:

EXPLICAÇÃO CONCEITUAL
→ confiança moderada

SINTAXE
→ validar

REGRA DE NEGÓCIO
→ validar fortemente

SEGURANÇA
→ validar fortemente

PRODUÇÃO
→ revisão obrigatória

Quanto maior o impacto, menor deve ser sua disposição em aceitar algo sem evidência.

---

37. Uma rotina diária de 30 minutos

Para aprender COBOL com Copilot:

10 min
Leia código sozinho.

5 min
Anote o que você acha que acontece.

5 min
Pergunte ao Copilot.

5 min
Compare as explicações.

5 min
Execute ou teste.

O ponto mais importante:

tente entender antes de perguntar.

Se você pergunta primeiro, seu cérebro pode entrar em modo espectador.

---

38. A regra dos três “porquês”

Para qualquer resposta importante, pergunte:

Por quê?

Como você sabe?

Como eu posso validar?

Essa tríade vale ouro.

Exemplo:

Copilot:

“Esse campo pode sofrer truncamento.”

Você:

“Por quê?”

Depois:

“Como você sabe?”

Depois:

“Como posso demonstrar isso com um teste?”

Pronto.

Você transformou uma resposta em aprendizado.

---

39. Copilot como mestre, não como muleta

Use Copilot para:

EXPLICAR
COMPARAR
SUGERIR
TESTAR
REVISAR
INVESTIGAR

Evite depender dele para:

PENSAR POR VOCÊ
VALIDAR NEGÓCIO POR VOCÊ
DECIDIR PRODUÇÃO POR VOCÊ

Essa distinção será cada vez mais importante.

---

40. O caminho do Padawan

Eu resumiria o treinamento assim:

NÍVEL 1
"Explique."

NÍVEL 2
"Dê exemplo."

NÍVEL 3
"Compare."

NÍVEL 4
"Encontre o erro."

NÍVEL 5
"Sugira uma solução."

NÍVEL 6
"Crie testes."

NÍVEL 7
"Faça a alteração."

NÍVEL 8
"Execute o ciclo."

NÍVEL 9
"Revise o agente."

NÍVEL 10
"Governança."

Não pule do nível 1 para o 8.

---

Epílogo — o Padawan, o Copilot e o velho terminal verde

Imagine um jovem programador sentado diante de um terminal.

À esquerda:

COBOL

À direita:

COPILOT

O iniciante pergunta:

“Você pode fazer isso por mim?”

O velho mestre no fundo do CPD responde:

“Pode.”

O Padawan sorri.

Então o mestre completa:

“Mas primeiro descubra por que ele fez.”

Essa é a diferença entre alguém que usa IA e alguém que aprende engenharia usando IA.

O Copilot pode completar uma linha.

Pode explicar um programa.

Pode sugerir uma função.

Pode criar testes.

Pode encontrar erros.

Pode, cada vez mais, alterar projetos inteiros.

Mas há uma habilidade que continua sendo sua:

entender o sistema pelo qual você é responsável.

No mundo COBOL, onde uma linha aparentemente inocente pode tocar folha de pagamento, cobrança, estoque, seguro, cartão, governo ou conta bancária, isso não é filosofia.

É requisito operacional.

Então use o Copilot.

Use muito.

Pergunte.

Experimente.

Quebre código de laboratório.

Compile.

Teste.

Discorde dele.

Peça explicações.

E quando ele disser:

“A alteração está pronta.”

faça como qualquer Jedi do mainframe faria.

Olhe para o código.

Olhe para os testes.

Olhe para o retorno.

Tome um gole de café.

E pergunte:

“Pronto segundo quem?”

☕⚔️💻

 

Bellacosa Mainframe testando software

☕ Um Café no Bellacosa Mainframe

O Mestre Persa Algoritm Entra no CPD — A Noite em que COBOL Descobriu que “Funcionou Aqui” Não Era Plano de Testes

Ou: como Black Box, White Box, Regression, Selenium, APIs, CI/CD, Db2, CICS, MQ, performance, bugs, usuários furiosos e um velho sábio persa ensinaram a um programador COBOL que qualidade não é provar que o sistema funciona — é descobrir todas as maneiras pelas quais ele pode falhar antes das três da manhã

Há uma velha história, provavelmente inventada por algum operador de mainframe durante um plantão de madrugada, sobre um mestre persa chamado Algoritm.

Alguns dizem que ele veio de Bagdá.

Outros juram que apareceu pela primeira vez em Samarcanda carregando pergaminhos cheios de fórmulas.

Um analista mais desconfiado afirmou que seu verdadeiro nome deveria ser alguma corruptela de Al-Khwarizmi, mas ninguém teve coragem de abrir uma change request para corrigir o cadastro.

O fato é que, numa noite qualquer, o Mestre Persa Algoritm atravessou a porta do CPD.

Olhou para os racks.

Observou as luzes piscando.

Passou pela console do z/OS.

Viu um programador COBOL iniciante comemorando diante da tela.

— Funcionou!

Algoritm parou.

— O que funcionou?

— Meu programa.

— Quantas vezes?

— Uma.

O persa acariciou a barba.

— Então você não sabe se funciona.

— Como assim?

— Você sabe apenas que não falhou daquela maneira específica, naquele instante específico, usando aqueles dados específicos.

O programador ficou em silêncio.

Algoritm puxou uma cadeira.

— Prepare o café. Esta noite falaremos sobre testes.

E é aqui que começa nossa viagem.

---

1. Testar software não é procurar botão quebrado

Quando alguém está começando em programação, especialmente vindo de uma mentalidade muito orientada ao código, é fácil imaginar teste assim:

executei
↓
não deu abend
↓
está certo

No mainframe existe até uma versão clássica:

JOB ENDED - MAXCC=0000

E imediatamente surge a tentação:

“Pronto. Funcionou.”

Não necessariamente.

MAXCC=0000 significa que aquele job terminou sem retornar uma condição de erro significativa naquele processamento.

Não significa:

dados corretos
regras corretas
performance correta
segurança correta
concorrência correta
integração correta

Pode existir um sistema absolutamente errado terminando com RC=0.

Essa é uma das primeiras lições do Mestre Algoritm:

Software Testing é uma investigação sobre comportamento e risco.

O teste tenta responder:

O que deveria acontecer?
        ↓
O que aconteceu?
        ↓
Existe diferença?
        ↓
Por quê?
        ↓
Qual o impacto?

Portanto, o objetivo do teste não é somente encontrar bugs.

Ele também serve para:

• aumentar confiança no sistema;

• reduzir risco;

• verificar requisitos;

• ajudar decisões de release;

• encontrar comportamentos inesperados;

• descobrir problemas antes que o cliente descubra.

Porque existe algo pior do que um tester descobrir um bug.

É o cliente descobrir.

---

2. O primeiro paradoxo: testes nunca provam ausência de bugs

Algoritm pega uma xícara.

— Quantos testes você precisa executar para provar que seu programa não possui erros?

O programador pensa.

— Mil?

— Não.

— Um milhão?

— Não.

— Todos?

Algoritm sorri.

— Agora começou a entender.

Um dos princípios fundamentais dos testes diz:

Testing shows the presence of defects, not their absence.

Ou seja:

se encontramos erro, sabemos que existe erro.

Se não encontramos, apenas não encontramos ainda.

Essa distinção parece filosófica, mas é profundamente prática.

Imagine:

IF WS-SALDO >= WS-SAQUE
    SUBTRACT WS-SAQUE FROM WS-SALDO
ELSE
    MOVE 'SALDO INSUFICIENTE'
      TO WS-MENSAGEM
END-IF

Testamos:

saldo = 1000
saque = 100

Resultado perfeito.

Mas faltam:

saldo = 100
saque = 100

saldo = 99
saque = 100

saque = 0

saque negativo

saque enorme

saldo inválido

conta bloqueada

duas requisições simultâneas

Aquele primeiro teste apenas mostrou que:

1000 - 100 = 900

Não mostrou que o sistema bancário está pronto para produção.

---

3. Teste exaustivo é impossível

Agora Algoritm desenha numa folha:

LOGIN

Temos usuário e senha.

Parece simples.

Mas considere:

usuário correto
usuário errado
senha correta
senha errada
conta bloqueada
conta expirada
senha expirada
campo vazio
espaço
Unicode
caracteres especiais
string gigantesca
tentativas repetidas
sessão existente
rede instável
banco indisponível

E cada uma dessas condições pode combinar-se com outras.

A explosão combinatória acontece rapidamente.

Portanto:

Exhaustive testing is impossible.

É impossível testar cada combinação possível de entrada, estado, ambiente e sequência.

Por isso precisamos de inteligência.

Não testamos tudo.

Testamos aquilo que oferece melhor cobertura de risco.

Esse é o momento em que testes deixam de parecer uma checklist e começam a parecer engenharia.

---

4. SDLC e STLC — construir e testar não deveriam viver separados

A abordagem tradicional do desenvolvimento frequentemente parecia uma procissão burocrática:

Analista
  ↓
Desenvolvedor
  ↓
Tester
  ↓
Produção

O tester recebia o sistema praticamente pronto.

Encontrava 47 problemas.

O desenvolvedor dizia:

“Mas agora vai atrasar o projeto!”

O tester respondia:

“Eu não criei os 47 bugs.”

E começava uma guerra civil.

O SDLC — Software Development Life Cycle cobre o ciclo do software:

requisitos
↓
análise
↓
design
↓
desenvolvimento
↓
testes
↓
deploy
↓
manutenção

Já o STLC — Software Testing Life Cycle trata especificamente das atividades de teste:

análise de requisitos
↓
planejamento
↓
desenho dos testes
↓
preparação do ambiente
↓
execução
↓
encerramento

Mas numa organização madura esses ciclos se cruzam.

Testing não deveria começar quando a programação termina.

O tester precisa participar antes.

Isso é o famoso Shift Left.

---

5. Shift Left — encontrar bugs antes que eles virem código

Algoritm pergunta:

— Qual é o bug mais barato?

O programador responde:

— O que é rápido de corrigir?

— Não. O que ainda não virou código.

Considere um requisito:

“O cliente poderá transferir valores entre contas.”

Parece perfeito.

Até alguém perguntar:

qual limite?
pode enviar para a própria conta?
conta bloqueada pode transferir?
o que ocorre no limite exato?
o que ocorre se o débito acontecer e o crédito falhar?
como evitar transferência duplicada?
há timeout?

Essas perguntas podem revelar problemas ainda durante os requisitos.

Nenhuma linha COBOL foi compilada.

Nenhum JCL foi submetido.

Nenhum DBA foi acordado.

Esse é um dos maiores ganhos de testes modernos:

testar ideias antes de testar programas.

---

6. Os níveis de teste — do parafuso ao avião inteiro

O material apresenta níveis clássicos:

Unit
↓
Integration
↓
System
↓
Acceptance

Podemos pensar numa fábrica de aviões.

Você testa:

parafuso
motor
asa
avião completo
voo

Não basta verificar o parafuso.

Também não faz sentido esperar o avião completo para descobrir que o parafuso estava errado.

---

7. Unit Testing — teste perto do código

Unit Test testa uma pequena unidade isoladamente.

Imagine:

COMPUTE WS-JUROS =
    WS-SALDO * WS-TAXA

Queremos testar:

saldo positivo
saldo zero
saldo negativo
taxa zero
decimais
arredondamento
overflow

Unit Tests são normalmente:

rápidos
repetíveis
isolados
baratos

Eles ajudam a encontrar o problema perto de onde ele nasceu.

No ecossistema COBOL moderno há inclusive ferramentas e frameworks voltados a unit testing, e isso destrói a velha lenda:

“COBOL não combina com testes modernos.”

Combina perfeitamente.

O código não sabe que nasceu em 1959.

---

8. Integration Testing — o sistema quebra quando começa a conversar

Aqui temos um fenômeno clássico.

Todos os módulos funcionam.

Juntos, não.

Imagine:

Aplicativo
 ↓
API Gateway
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL
 ↓
Db2

Separadamente:

API OK
CICS OK
COBOL OK
Db2 OK

Mas integração pode falhar porque:

JSON ≠ copybook
UTF-8 ≠ EBCDIC
decimal ≠ COMP-3
timestamp ≠ formato esperado
campo obrigatório desapareceu

Integration Testing verifica os contratos entre os componentes.

É aí que aparecem erros que ninguém tinha quando estava sozinho.

Quase como reunião de família.

---

9. System Testing — teste aquilo que o usuário realmente percebe

O usuário não pensa:

“Estou invocando um microsserviço de estoque.”

Ele pensa:

“Estou comprando um notebook.”

Logo, System Testing examina o fluxo completo.

login
↓
busca
↓
produto
↓
carrinho
↓
checkout
↓
pagamento
↓
estoque
↓
pedido
↓
confirmação

Pode haver vinte componentes internos.

Para o cliente existe apenas uma pergunta:

“Minha compra funcionou?”

Essa diferença é essencial.

---

10. Functional Testing versus Non-Functional Testing

Aqui está uma das divisões mais elegantes.

Functional Testing pergunta:

O que o sistema faz?

Non-Functional Testing pergunta:

Quão bem ele faz?

Imagine transferência bancária.

Funcionalmente:

debita origem
credita destino
gera comprovante

Perfeito.

Mas leva 45 segundos.

Tecnicamente funciona.

Praticamente é um desastre.

Ou funciona rapidamente, mas:

qualquer cliente consulta a conta de outro cliente

Funcionalmente responde.

Em segurança, falhou monstruosamente.

Por isso software de qualidade precisa dos dois lados.

---

11. Black Box Testing — teste o sistema sem olhar dentro

Black Box é como testar uma máquina fechada.

Você conhece:

entrada
resultado esperado

Não precisa saber como o programa foi implementado.

Exemplo:

idade aceita: 18 até 65

Não testamos todos os números do universo.

Usamos técnicas.

---

12. Equivalence Partitioning — dividir o universo

Podemos criar partições:

idade < 18      inválida
18–65           válida
idade > 65      inválida

Selecionamos representantes:

17
30
66

Isso reduz bastante o número de testes mantendo boa cobertura.

Mestre Algoritm comenta:

— Um bom tester não testa muito. Testa inteligentemente.

---

13. Boundary Value Analysis — o perigo mora na fronteira

Programadores são criaturas especialmente vulneráveis aos limites.

Se a regra é:

1 até 100

testes interessantes:

0
1
2
99
100
101

Porque bugs surgem em diferenças como:

<
<=
>
>=

Em COBOL pense imediatamente em:

PIC
OCCURS
subscripts
COMP-3
tamanho de registro
campo numérico

A fronteira é um habitat natural de bugs.

---

14. Decision Table — excelente para regra de negócio

Imagine autorização de crédito:

cliente ativo?
saldo suficiente?
limite disponível?
conta regular?

Cada condição possui combinações.

Uma Decision Table deixa explícito:

Ativo	Saldo	Limite	Resultado
Sim	Sim	Sim	Aprova
Não	Sim	Sim	Rejeita
Sim	Não	Sim	Rejeita
Sim	Sim	Não	Rejeita

É particularmente valiosa em sistemas financeiros cheios de regras condicionais.

E sistemas COBOL adoram regras condicionais.

Às vezes até demais.

---

15. State Transition Testing — o passado importa

Alguns comportamentos dependem do estado.

Considere login:

ACTIVE
 ↓ erro
ACTIVE
 ↓ erro
ACTIVE
 ↓ erro
LOCKED

O terceiro erro produz algo diferente do primeiro.

Portanto:

estado atual
+
evento
=
novo estado

Isso aparece em:

login
pagamentos
pedidos
CICS
workflow
mensageria

Testing de estado verifica justamente essas transições.

---

16. White Box Testing — agora abrimos o programa

No White Box conhecemos a estrutura interna.

Imagine:

IF A > B
    PERFORM ROTINA-A
ELSE
    PERFORM ROTINA-B
END-IF

Precisamos exercitar:

True
False

E podemos medir:

Statement Coverage
Branch Coverage
Condition Coverage
Path Coverage
Loop Coverage

Mas atenção ao Easter Egg escondido no templo persa:

100% coverage não significa 100% correto.

Podemos executar todas as linhas de um programa errado.

Coverage mede execução.

Não mede sabedoria.

---

17. Regression versus Retesting — duas perguntas diferentes

Bug:

senha contendo @ falha

Corrigimos.

Retesting

Pergunta:

A correção funcionou?

Testamos novamente a senha.

Regression

Pergunta:

A correção quebrou outra coisa?

Testamos:

login
logout
reset password
MFA
sessão
bloqueio

Resumo Bellacosa:

RETEST:
"Consertou o vazamento?"

REGRESSION:
"Consertando o vazamento, estourou o encanamento da cozinha?"

Essa é a diferença.

---

18. Defect Life Cycle — o bug também tem carreira

Um bug costuma viajar:

New
 ↓
Assigned
 ↓
Open
 ↓
In Progress
 ↓
Fixed
 ↓
Retest
 ↓
Verified
 ↓
Closed

Mas no mundo real encontramos parentes:

Reopened
Rejected
Duplicate
Deferred
Cannot Reproduce
Won't Fix
Blocked

O mais famoso é:

Cannot Reproduce.

O tester jura que aconteceu.

O developer jura que não.

Produção entra na reunião e diz:

Aconteceu comigo também.

Silêncio.

Um bom bug report precisa conter:

versão
ambiente
pré-condições
passos
dados
resultado esperado
resultado observado
timestamp
logs
evidências

“Não funciona” não é bug report.

É pedido de ajuda.

---

19. Severity e Priority — gravidade não é urgência

Severity:

Quanto dói?

Priority:

Quão rápido precisamos tratar?

Imagine erro ortográfico na tela principal durante uma demonstração internacional.

Severity:

Low

Priority:

P1

Agora imagine crash crítico numa função administrativa usada uma vez ao ano.

Severity:

Critical

Priority pode não ser P1.

Portanto:

SEVERITY != PRIORITY

Severity está relacionada ao impacto do defeito.

Priority envolve necessidade de negócio.

---

20. Manual Testing — humanos ainda são surpreendentemente úteis

Chegamos a uma moda perigosa:

“IA e automação vão eliminar teste manual.”

Não.

Teste manual é particularmente útil em:

exploratory testing
usability
interface
novas features
comportamentos inesperados
investigação

O ser humano percebe coisas que um script não foi instruído a perceber.

Um script pode validar:

botão existe

Um humano percebe:

“Ninguém vai entender para que serve esse botão.”

São problemas diferentes.

---

21. Test Automation — automatize repetição, não pensamento

Automação faz sentido quando testes são:

repetitivos
estáveis
frequentes
determinísticos
caros manualmente

Regression Testing é candidato clássico.

Mas automatizar tudo gera outra doença:

10.000 scripts
+
interface alterada
=
10.000 problemas de manutenção

Automação tem ROI.

Existe:

custo inicial
infraestrutura
manutenção
dados
execução
investigação

Por isso:

Automatize o teste certo, não simplesmente tudo que possui botão.

---

22. A pirâmide dos testes

A pirâmide clássica:

        UI
       /--\
      API
     /----\
    UNIT
   /______\

A base contém muitos Unit Tests.

Depois APIs e integração.

No topo poucos E2E/UI.

Por quê?

Unit Tests são rápidos.

UI Tests são relativamente lentos e frágeis.

Se toda regra de negócio for validada por Selenium abrindo browser, clicando em menus e esperando telas, prepare café.

Muito café.

---

23. Selenium — o mensageiro do navegador

Selenium automatiza navegadores.

Fluxo:

test script
 ↓
WebDriver
 ↓
browser
 ↓
application

Podemos:

abrir URL
localizar elementos
clicar
preencher
capturar texto
validar resultado

O Selenium é poderoso.

Mas não deve testar tudo.

Se uma regra pode ser verificada diretamente na API, normalmente o teste será:

mais rápido
mais estável
mais simples

---

24. O clássico sleep(5) — a oração do programador cansado

Considere:

Thread.sleep(5000);

Tradução:

“Ó sistema, por favor tenha terminado dentro de cinco segundos.”

Se termina em 100 ms:

perdemos tempo.

Se termina em 5,01 segundos:

falha.

Melhor é esperar uma condição:

botão clicável
elemento visível
resposta concluída

Esses são os Explicit Waits.

Eles ajudam a reduzir testes flakey.

Flaky Test é aquele teste adorável que:

passa
falha
passa
falha

sem mudança no programa.

O Mestre Algoritm certamente jogaria esse teste no deserto.

---

25. API Testing — HTTP 200 não é certificado de perfeição

API Testing verifica:

endpoint
method
headers
authentication
request
response
schema
status
performance
security

Imagine:

POST /transfer

Recebemos:

HTTP 200

Excelente?

Talvez.

Precisamos verificar:

o dinheiro saiu?
chegou?
duplicou?
foi persistido?
auditado?

Uma resposta HTTP tecnicamente válida pode carregar comportamento de negócio errado.

Esse é um conceito extremamente importante.

---

26. Performance Testing — o sistema pode funcionar e ainda assim morrer

Performance Testing não significa apenas medir velocidade.

Temos:

Load Testing

Carga esperada.

Stress Testing

Carga além do esperado.

Spike Testing

Aumento repentino.

Soak Testing

Carga prolongada.

Volume Testing

Grandes volumes de dados.

Scalability Testing

Capacidade de crescer.

Uma aplicação pode sobreviver cinco minutos perfeitamente.

Depois de seis horas:

memory leak
pool esgotado
fila crescente
storage acabando

O Soak Test revela esses monstros.

---

27. Métricas — média é uma mentirosa educada

Imagine:

Average Response Time = 200 ms

Fantástico.

Mas:

P50 = 100 ms
P95 = 2 s
P99 = 12 s

A maioria está feliz.

Uma parcela está sofrendo profundamente.

Por isso usamos percentis.

Também observamos:

TPS
throughput
latency
error rate
CPU
memory
disk
network

Uma métrica isolada conta metade da história.

---

28. Agile Testing — testing deixa de ser departamento

Agile Testing traz uma mudança fundamental:

qualidade é responsabilidade do time.

Não:

DEV fez
↓
QA testa

Mas:

PO
↕
Developer
↕
Tester
↕
Operations

Testing acontece continuamente.

O QA deixa de ser “polícia do bug”.

Torna-se parceiro da engenharia.

---

29. CI/CD — a esteira que não aceita promessa

No CI/CD:

commit
↓
build
↓
unit test
↓
static analysis
↓
integration
↓
API test
↓
security
↓
deploy
↓
monitor

Se um quality gate falha:

STOP

No mainframe isso pode envolver:

Git
↓
DBB
↓
COBOL Compile
↓
Link Edit
↓
Unit Tests
↓
Integration
↓
Deploy

Sim.

COBOL pode viver dentro de pipeline moderno.

Ele não precisa continuar esperando fita magnética e formulário de mudança datilografado.

---

30. “Works in DEV, fails in PROD”

Existe uma inscrição secreta na parede de todo datacenter:

Funciona no meu ambiente.

Em produção encontramos diferenças:

configuração
dados
versões
RACF
certificados
network
Db2
CICS
feature flags
capacity

Código igual não garante ambiente igual.

Portanto:

ambiente também faz parte do sistema.

Essa ideia é frequentemente esquecida.

---

31. O cenário assustador: usuário vendo dados de outro usuário

Imagine:

Cliente A
 ↓
consulta conta
 ↓
dados do Cliente B

O sistema pode responder:

HTTP 200
tempo = 70 ms
JSON válido

Performance maravilhosa.

Funcionalidade respondendo.

Segurança devastada.

Aqui entram:

authentication
authorization
session
access control
data isolation

Essa é a prova definitiva de que qualidade é multidimensional.

---

32. “Dados às vezes não são salvos”

Algoritm fica sério.

— Qual palavra mais perigosa num bug report?

O programador responde:

— Abend?

— Não.

— Corrupção?

— Não.

— Qual?

— Às vezes.

“Às vezes não salva.”

Pode indicar:

race condition
lock
timeout
rollback
commit
deadlock
concorrência
network failure

Problemas intermitentes são particularmente difíceis porque dependem de timing e estado.

Exemplo:

DEBIT
↓
serviço externo
↓
timeout
↓
CREDIT?

Esse tipo de teste começa a entrar em resiliência.

---

33. Observabilidade — a página que deveria existir

Eu acrescentaria ao material:

Testing + Observability

Não basta saber:

FAILED

Precisamos saber:

WHY?

Logs.

Metrics.

Traces.

No mainframe:

SQLCODE
CICS RESP
MQ Reason Code
SMF
return codes
Abend codes

Em sistemas distribuídos, um correlation ID permite acompanhar:

Mobile
↓
API
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2

Sem observabilidade, debugging moderno vira arqueologia.

---

34. Resilience Testing — provoque o desastre antes que o desastre aconteça

Outra evolução interessante:

E se Db2 cair?
E se MQ parar?
E se a rede ficar lenta?
E se o serviço externo devolver lixo?
E se o certificado expirar?

Resilience Testing não pergunta apenas:

o sistema quebra?

Pergunta:

como o sistema quebra?

Existe enorme diferença entre:

mensagem de indisponibilidade

e:

dados financeiros inconsistentes

Sistemas críticos precisam falhar com segurança.

---

35. E finalmente: como pensa um tester de verdade?

Voltamos ao Mestre Algoritm.

O iniciante pergunta:

— Mestre, então qual é a principal ferramenta de um tester?

Algoritm aponta para a cabeça.

Não Selenium.

Não Postman.

Não JMeter.

Não Jenkins.

Não alguma ferramenta de IA.

A principal ferramenta é:

curiosidade estruturada.

O desenvolvedor pergunta:

Como faço isso funcionar?

O tester pergunta:

Como faço isso falhar?

O engenheiro de qualidade pergunta:

Qual falha importa mais?

O engenheiro de resiliência pergunta:

Quando isso inevitavelmente falhar,
como impedimos que o desastre se espalhe?

Isso representa uma progressão extremamente interessante:

JÚNIOR
"Funciona?"

↓


PLENO
"Quando falha?"

↓


SÊNIOR
"Onde pode falhar?"

↓


TEST ENGINEER
"Como mensuramos o risco?"

↓


QUALITY ENGINEER
"Como prevenimos e detectamos?"

↓


SRE / RESILIENCE
"Como sobrevivemos à falha?"

---

☕ Epílogo — o Mestre Persa desliga o terminal

O relógio marcava 03:17.

O café havia acabado.

O programador COBOL olhou novamente para seu job.

Na tela continuava:

MAXCC=0000

Antes ele teria comemorado.

Agora começou a perguntar:

E se o arquivo estiver vazio?

E se chegar duplicado?

E se o Db2 retornar -911?

E se o CICS der timeout?

E se dois usuários fizerem isso juntos?

E se MQ não responder?

E se a regra mudar?

E se o sistema estiver lento?

E se um usuário acessar dados de outro?

E se funcionar hoje e quebrar amanhã?

Algoritm sorriu.

— Agora você está testando.

Pegou seu velho pergaminho.

Saiu pelo corredor.

No verso havia uma última frase escrita em tinta desbotada:

“O bom programador escreve caminhos pelos quais o software pode funcionar. O bom tester procura caminhos pelos quais ele pode falhar. O grande engenheiro entende que ambos estão desenhando o mesmo sistema.”

Na manhã seguinte ninguém encontrou o Mestre Algoritm.

Mas sobre a mesa do programador havia uma pequena folha contendo apenas:

IDENTIFY
    RISK

DESIGN
    TEST

EXECUTE
    EVIDENCE

LEARN
    REPEAT

E, escondido no canto inferior, quase como um Easter Egg:

IF PROGRAM-WORKS
    CONTINUE
ELSE
    CALL 'MESTRE-ALGORITM'
END-IF.

O compilador reclamou que MESTRE-ALGORITM não existia.

Naturalmente.

O primeiro teste da manhã havia acabado de encontrar um bug.

O que é J.A.D. - Joint Application Design?

Salve jovem padawan, inspirado no artigo anterior sobre como organizar uma boa reunião. Resolvi aproveitar o gancho e falar sobre uma técnica desenvolvida pelos engenheiros da IBM, nos idos anos 70, que vem passando por inúmeras melhorias ao longo dos anos, sempre visando atender as necessidades que a evoluções tecnológicas apresenta. Leia na Integra

O Mainframe Ainda é o Mesmo? : O Paradoxo do Navio de Teseu e o Computador que Nunca Parou de Evoluir

 

Bellacosa Mainframe apresenta o paradoxo do navio de Teseu e o mainframe

☕ Um Café no Bellacosa Mainframe

O Mainframe Ainda é o Mesmo?

O Paradoxo do Navio de Teseu e o Computador que Nunca Parou de Evoluir

"Se você substituir todas as peças de uma máquina, em algum momento ela deixa de ser a mesma máquina?"

Essa pergunta parece saída de um episódio de Star Trek, de um mangá filosófico ou de Houseki no Kuni. Mas ela nasceu há mais de dois mil anos.

E, curiosamente...

Ela descreve perfeitamente o mundo do IBM Mainframe.

---

Uma velha história grega

Imagine que o lendário herói Teseu, depois de derrotar o Minotauro, retorna para Atenas em seu navio.

Os atenienses, orgulhosos daquele símbolo, decidem preservá-lo para sempre.

O problema?

Madeira apodrece.

Então trocam uma tábua.

Anos depois outra.

Depois o mastro.

Depois as velas.

Depois o leme.

Século após século...

Até que nenhuma peça original permanece.

Então surge a pergunta:

Ainda é o navio de Teseu?

---

Agora vem a parte interessante.

Suponha que alguém tenha guardado todas as tábuas antigas.

Décadas depois ele monta outro navio usando exatamente todas as peças originais.

Agora existem dois navios.

Qual deles é o verdadeiro?

O continuamente preservado?

Ou o reconstruído com todas as peças originais?

Bem-vindo ao paradoxo.

---

O paradoxo não fala de navios

Na verdade ele fala sobre identidade.

O que faz alguma coisa continuar sendo ela mesma?

Sua matéria?

Sua história?

Sua função?

Sua memória?

Sua continuidade?

Ou apenas o nome?

Filósofos discutem isso há mais de vinte séculos.

E até hoje ninguém possui uma resposta definitiva.

---

Agora entre comigo no CPD...

Imagine um IBM System/360 de 1964.

Ele possuía:

• memória de poucos KB

• cartões perfurados

• fitas magnéticas

• discos enormes

• CPU extremamente simples

• COBOL

• FORTRAN

• Assembler

Hoje temos um IBM z17.

Nada é igual.

CPU diferente.

Arquitetura diferente.

Circuitos diferentes.

Memórias diferentes.

Caches.

Criptografia.

IA.

Linux.

Containers.

Cloud.

OpenShift.

zCX.

APIs REST.

GPUs integradas para IA.

Nem um único transistor daquela máquina continua aqui.

Então...

Ainda é o mesmo Mainframe?

---

A IBM diria:

Sim.

Porque existe algo chamado compatibilidade contínua.

---

O verdadeiro navio do mainframe

Desde 1964 a IBM fez algo quase impossível.

Ela trocou praticamente tudo.

Centenas de vezes.

Processadores.

Barramentos.

Canal de I/O.

Microcódigo.

Memória.

Discos.

Controladoras.

Sistemas operacionais.

Virtualização.

Entretanto...

um programa COBOL escrito há quarenta anos frequentemente ainda compila.

Alguns até executam praticamente sem alterações.

Isso significa que existe uma continuidade.

Não física.

Mas lógica.

---

O hardware mudou.

A arquitetura evoluiu.

Mas a identidade permaneceu.

---

COBOL também é um Navio de Teseu

Pense no COBOL.

COBOL-60.

COBOL-68.

COBOL-74.

COBOL-85.

Enterprise COBOL.

COBOL 6.5.

COBOL AI.

JSON.

XML.

UTF-8.

Objetos.

APIs REST.

Novas instruções.

Novos compiladores.

Novas otimizações.

Nenhuma implementação interna é igual.

Mesmo assim...

Continuamos chamando tudo de COBOL.

---

E o z/OS?

O mesmo acontece.

OS/360.

MVT.

SVS.

MVS.

MVS/XA.

ESA.

OS/390.

z/OS.

Mudou tudo.

Scheduler.

Memória.

Paging.

Segurança.

JES.

Virtualização.

Mas existe uma linha contínua.

É como assistir a uma pessoa envelhecendo.

Cada célula do corpo muda.

Mesmo assim...

Você continua dizendo:

"É a mesma pessoa."

---

O VSAM sobreviveu

Outro exemplo curioso.

O VSAM nasceu na década de 1970.

Hoje continua presente.

Claro.

Recebeu melhorias.

Novos recursos.

Novas integrações.

Mas sua essência permanece.

Assim como o paradoxo.

---

O banco DB2 também

DB2 Version 1.

Depois Version 2.

...

Cada versão substituiu milhares de linhas de código.

Milhões.

Talvez centenas de milhões.

Ainda assim ninguém diz:

"Este é outro banco."

Continuamos dizendo:

DB2.

---

Houseki no Kuni já respondeu isso

É aqui que aquele anime extraordinário entra.

Phosphophyllite perde partes do corpo.

Perde braços.

Perde pernas.

Perde cabeça.

Recebe ouro.

Recebe platina.

Recebe novas memórias.

Cada transformação muda sua personalidade.

Em determinado momento quase nada do Phos original existe.

Então surge exatamente a pergunta do Navio de Teseu:

Ainda é Phos?

Ou tornou-se outra pessoa?

Esse é um dos motivos pelos quais Houseki no Kuni é tão filosófico. Ele não trata apenas de batalhas; trata da continuidade da identidade quando corpo, memória e experiência mudam radicalmente.

---

Blade Runner também

"Memórias fazem quem somos?"

Se você substituir todas as lembranças...

Continua sendo você?

---

Ghost in the Shell

Se trocar todos os órgãos.

Depois o cérebro.

Depois copiar a consciência.

Quem é o verdadeiro?

---

Star Trek

O teletransporte desmonta seu corpo.

Depois monta outro.

Você morreu?

Ou apenas foi copiado?

---

O Mainframe resolve o paradoxo de uma maneira elegante

Os filósofos perguntam:

"O que define identidade?"

Os engenheiros responderam:

Compatibilidade.

Enquanto existir continuidade operacional...

Enquanto programas antigos continuarem funcionando...

Enquanto os dados permanecerem íntegros...

Enquanto clientes não perceberem a troca...

Para o mundo dos negócios...

É o mesmo sistema.

Essa talvez seja uma das maiores vitórias da engenharia de software.

---

A analogia perfeita

Imagine um banco.

Em 1978 foi criado um sistema COBOL.

Desde então:

• trocou cinco vezes de hardware;

• mudou de processador dezenas de vezes;

• atualizou o z/OS inúmeras vezes;

• migrou discos;

• modernizou o DB2;

• substituiu compiladores;

• adicionou CICS, MQ, APIs REST, OpenShift e IA;

• virtualizou servidores;

• integrou cloud híbrida.

O cliente continua consultando o saldo.

Nunca percebeu nada.

O banco continua dizendo:

"É o mesmo sistema."

Na prática...

É o Navio de Teseu funcionando todos os dias.

---

A visão Bellacosa

Sempre achei curioso quando alguém diz:

"Mainframe é tecnologia antiga."

Antiga?

Nenhum componente físico daquela máquina de 1964 ainda existe.

Cada geração foi substituindo a anterior.

Cada processador nasceu mais poderoso.

Cada compilador ficou mais inteligente.

Cada versão do z/OS reinventou partes profundas do sistema.

O que sobreviveu não foi o ferro.

Foi uma ideia.

A ideia de que compatibilidade não é um peso; é um compromisso com a continuidade.

Enquanto muitos sistemas precisaram ser reescritos do zero a cada década, o mainframe atravessou mais de sessenta anos preservando aplicações que movimentam bancos, companhias aéreas, seguradoras e governos. Não porque parou no tempo, mas porque conseguiu mudar sem romper sua identidade.

Talvez o maior segredo do mainframe nunca tenha sido a velocidade, a confiabilidade ou a escalabilidade.

Talvez seu verdadeiro segredo tenha sido resolver, na prática, uma pergunta que filósofos discutem desde a Grécia Antiga:

Como continuar sendo o mesmo... mesmo quando tudo mudou?

E, como acontece com o Navio de Teseu, talvez a resposta não esteja nas peças substituídas, mas na história contínua que elas carregam. No fim das contas, um sistema, um navio ou até uma pessoa são mais do que a soma de seus componentes: são a trajetória que permanece navegando, mesmo quando cada tábua já foi trocada muitas vezes.