☕ Um Café no Bellacosa Mainframe
O Herói, o Mainframe e a Misteriosa Pasta CD 17
Uma aventura isekai para programadores COBOL iniciantes, administradores de sistemas e aventureiros que jamais deixariam a mãe abrir a pasta Downloads
Imagine a seguinte situação.
Você passou a noite inteira estudando COBOL, corrigindo um programa que insistia em encerrar com código de retorno 12 e tentando entender por que uma simples leitura de arquivo sequencial conseguia produzir mais suspense que uma temporada inteira de anime.
O relógio marcava 3h17 da manhã.
Ao lado do teclado, havia uma xícara de café já fria, um manual de JCL aberto na página errada e uma janela do navegador exibindo uma pesquisa extremamente profissional:
“Por que meu programa COBOL entra em loop infinito mesmo quando eu tenho certeza de que coloquei o fim do arquivo?”
Foi então que você decidiu sair de casa para comprar mais café.
Cinco minutos depois, apareceu o inevitável.
Não era um dragão.
Não era um demônio.
Não era um gerente de projetos perguntando se seria possível colocar mais uma pequena alteração em produção antes do almoço.
Era ele.
Caminhão-kun.
Depois de um encontro inesperado com a engenharia automotiva japonesa, você acordou diante de uma deusa de cabelos azuis, cercada por nuvens, colunas douradas e uma interface estranhamente parecida com um painel do ISPF.
Ela sorriu.
— Parabéns! Você terá a oportunidade de recomeçar sua vida em outro mundo!
Você olhou para a deusa.
Olhou para o portal mágico.
Olhou para a lista de habilidades especiais disponíveis.
E fez a única pergunta realmente importante:
— Alguém pode apagar meu HD?
A deusa piscou.
— Você não quer saber em qual mundo renascerá?
— Depois.
— Não quer escolher uma habilidade lendária?
— Mais tarde.
— Não quer se despedir de sua família?
— Claro que quero. Mas antes alguém precisa localizar a pasta CD 17.
A deusa consultou uma espécie de terminal celestial.
— O que existe nessa pasta?
Você se levantou assustado.
— Não execute um LISTCAT nisso!
E assim começa nossa jornada.
1. O último desejo da era digital
Nas histórias antigas, os heróis preocupavam-se com honra, legado, família e destino.
O guerreiro medieval pedia que sua espada fosse entregue ao filho.
O capitão solicitava que sua última carta chegasse à esposa.
O mago queria que seus grimórios fossem protegidos.
O protagonista moderno de isekai, entretanto, possui uma preocupação mais urgente:
“Destruam meu computador antes que alguém descubra quem eu realmente era.”
Essa piada aparece em inúmeras variações na cultura de anime, mangá, light novels, fóruns e memes:
apagar o histórico do navegador;
formatar o disco;
jogar o computador na banheira;
incinerar o equipamento;
destruir fisicamente o HD;
impedir que a mãe abra determinada pasta;
telefonar para um amigo de confiança;
pedir que ninguém examine a coleção de arquivos.
A força da piada está no fato de que o conteúdo jamais precisa ser revelado.
Cada espectador preenche o espaço em branco com suas próprias suspeitas.
Pode ser uma coleção de imagens constrangedoras.
Pode ser um arquivo com fanfictions.
Pode ser um conjunto de animes baixados em resolução duvidosa.
Pode ser uma pasta contendo centenas de fotografias, programas antigos, jogos, emuladores, documentos, projetos abandonados e arquivos chamados:
VERSAO_FINAL
VERSAO_FINAL_2
VERSAO_FINAL_AGORA_VAI
VERSAO_FINAL_DEFINITIVA
VERSAO_FINAL_DEFINITIVA_CORRIGIDA
VERSAO_FINAL_DEFINITIVA_CORRIGIDA_NOVA
Ou pode ser simplesmente a lendária:
CD 17
O nome perfeito.
Discreto.
Inocente.
Burocrático.
Tão genérico que não desperta suspeitas.
Ou, justamente por isso, desperta todas.
2. A arqueologia da pasta CD 17
Para quem nasceu na época do armazenamento em nuvem, um nome como CD 17 talvez pareça irrelevante.
Para quem viveu a era dos CD-R, CD-RW, gravadores de 2x, discos riscados e estojos empilhados, o nome carrega toda uma história tecnológica.
Antes de termos terabytes disponíveis em pequenos dispositivos, o armazenamento era escasso.
Um CD-ROM comum armazenava aproximadamente 650 ou 700 megabytes. Na época, isso parecia bastante espaço. Era possível gravar programas, fotografias, documentos, músicas, backups e coleções inteiras de arquivos.
Quando o conteúdo ultrapassava a capacidade de um disco, surgia uma sequência:
CD 01
CD 02
CD 03
CD 04
...
CD 17
O problema começava quando ninguém lembrava mais o que havia em cada mídia.
A pessoa então criava pastas temporárias no HD para preparar as gravações:
C:\GRAVAR\CD_15
C:\GRAVAR\CD_16
C:\GRAVAR\CD_17
O CD era gravado.
A pasta, entretanto, permanecia.
Depois recebia novos arquivos.
Cópias eram feitas.
Anos se passavam.
A origem do nome era esquecida.
A pasta transformava-se em um sítio arqueológico digital.
Dentro dela poderiam existir arquivos de 1998, 2001, 2007 e 2014 convivendo em perfeita desordem cronológica.
É como abrir uma biblioteca em que os livros foram guardados por um duende bêbado.
No mundo mainframe, porém, essa desorganização produziria imediatamente uma reunião de governança.
Alguém perguntaria:
— Quem é o proprietário do dataset?
Outro responderia:
— Não sabemos.
— Qual é a política de retenção?
— Também não sabemos.
— Há backup?
— Provavelmente.
— Onde?
— Talvez no CD 18.
3. O que a pasta CD 17 ensina sobre organização de dados
Por trás da piada existe uma lição séria para o programador COBOL iniciante.
Computadores não compreendem contexto emocional.
Eles não sabem que:
CD17
significa “arquivos importantes que eu não queria perder em 2002”.
Também não sabem que:
FINAL2
é mais recente que:
FINAL_NOVO
Os sistemas precisam de organização explícita.
No mainframe, essa preocupação aparece nos nomes de datasets, nas convenções da empresa, no catálogo, nas gerações de arquivos, nos layouts, nas descrições e nas políticas de retenção.
Um dataset pode possuir um nome como:
BELLACOS.CURSO.COBOL.ALUNOS
Esse nome já comunica uma hierarquia:
BELLACOS pode identificar o usuário, projeto ou aplicação;
CURSO representa uma área;
COBOL indica o contexto;
ALUNOS descreve o conteúdo.
Compare com:
BELLACOS.CD17
Tecnicamente válido em muitas convenções internas, talvez.
Explicativo, não.
Seguro para auditoria, definitivamente não.
Uma boa nomenclatura reduz dúvidas.
Exemplo:
BELLACOS.CURSO.COBOL.FONTE
BELLACOS.CURSO.COBOL.JCL
BELLACOS.CURSO.COBOL.COPY
BELLACOS.CURSO.COBOL.DADOS
BELLACOS.CURSO.COBOL.RELATORIO
O nome deve ajudar o próximo profissional.
Inclusive quando o próximo profissional for você mesmo, seis meses depois, olhando para o sistema como se tivesse sido desenvolvido por um feiticeiro irresponsável.
4. A deusa pergunta: “O que é COBOL?”
De volta ao mundo celestial, a deusa continuava tentando entender por que você estava tão preocupado.
— Afinal, o que você fazia naquele computador?
— Programava em COBOL.
Ela arregalou os olhos.
— Uma magia ancestral?
— Quase isso.
COBOL é uma linguagem criada com o objetivo de facilitar o desenvolvimento de aplicações voltadas ao processamento de dados comerciais.
Seu nome vem de:
COmmon Business-Oriented Language
Ou seja:
Linguagem Comum Orientada a Negócios
COBOL foi projetado para trabalhar com informações como:
clientes;
contas;
pagamentos;
folhas salariais;
seguros;
estoques;
transações;
registros financeiros;
arquivos corporativos;
relatórios;
processamento em lote.
Apesar de sua idade, COBOL continua relevante porque muitos sistemas críticos foram construídos ao longo de décadas e permanecem executando milhões ou bilhões de operações.
Uma aplicação COBOL não é necessariamente um programa isolado.
Ela pode participar de um ecossistema com:
Em outras palavras, aprender COBOL não significa apenas memorizar comandos.
Significa compreender como os dados entram, são processados, validados, transformados, armazenados e entregues.
É quase uma guilda de aventureiros.
Só que cada integrante da equipe possui uma função.
O COBOL realiza a lógica de negócio.
O JCL prepara o ambiente para a execução.
O Db2 armazena dados relacionais.
O VSAM organiza arquivos de acesso eficiente.
O CICS coordena transações online.
O RACF verifica quem tem permissão para invocar a magia.
E o operador observa tudo, silenciosamente, até alguém produzir um abend às três da manhã.
5. Primeiro programa: protegendo a CD 17
Vamos transformar nossa piada em um pequeno programa COBOL.
O objetivo será pedir ao usuário o nome de uma pasta e verificar se ela corresponde à área proibida.
IDENTIFICATION DIVISION.
PROGRAM-ID. CD17CHK.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NOME-PASTA PIC X(30).
01 WS-CD-SECRETO PIC X(30)
VALUE 'CD 17'.
PROCEDURE DIVISION.
INICIO.
DISPLAY 'INFORME O NOME DA PASTA:'
ACCEPT WS-NOME-PASTA
IF WS-NOME-PASTA = WS-CD-SECRETO
DISPLAY 'ACESSO NEGADO.'
DISPLAY 'NAO EXECUTE LISTCAT.'
DISPLAY 'CHAME O AMIGO DE CONFIANCA.'
ELSE
DISPLAY 'PASTA LIBERADA PARA CONSULTA.'
END-IF
STOP RUN.
Para quem está começando, vamos analisar o programa.
IDENTIFICATION DIVISION
Aqui identificamos o programa:
PROGRAM-ID. CD17CHK.
É como registrar o nome do aventureiro na guilda.
DATA DIVISION
Nesta divisão descrevemos os dados usados pelo programa.
01 WS-NOME-PASTA PIC X(30).
Essa variável pode armazenar até 30 caracteres.
O prefixo WS costuma indicar que o item está na WORKING-STORAGE SECTION.
Não é uma obrigação da linguagem, mas uma convenção útil.
Depois definimos:
01 WS-CD-SECRETO PIC X(30)
VALUE 'CD 17'.
Essa variável já começa com o valor CD 17.
PROCEDURE DIVISION
Aqui está a lógica executável.
DISPLAY
mostra uma mensagem.
ACCEPT
recebe uma informação.
IF
testa uma condição.
STOP RUN
encerra o programa.
Simples, direto e muito mais seguro que confiar a tarefa a um personagem secundário de moral duvidosa.
6. O perigo de comparar textos em COBOL
Agora entra uma curiosidade importante.
Campos alfanuméricos possuem tamanho fixo.
Quando declaramos:
01 WS-NOME-PASTA PIC X(30).
o campo ocupa 30 posições.
Se o usuário digitar:
CD 17
o valor interno poderá ser entendido como:
CD 17
seguido por espaços até completar 30 posições.
Por isso, comparações entre campos de tamanhos diferentes exigem atenção.
Uma alternativa mais clara seria usar uma condição de nível 88:
01 WS-NOME-PASTA PIC X(30).
88 PASTA-SECRETA
VALUE 'CD 17'.
Então poderíamos escrever:
IF PASTA-SECRETA
DISPLAY 'PROTOCOLO DE DESTRUICAO INICIADO.'
END-IF
O nível 88 não cria um novo espaço de armazenamento.
Ele cria um nome de condição associado a determinados valores.
Isso torna o código mais legível.
Compare:
IF WS-NOME-PASTA = 'CD 17'
com:
IF PASTA-SECRETA
A segunda forma parece quase uma frase.
Essa legibilidade é uma das características marcantes do COBOL.
7. O amigo caridoso e o processamento em lote
Na piada do isekai, o protagonista depende de uma alma caridosa para destruir o HD.
No mainframe, jamais deveríamos depender apenas de boa vontade.
Precisamos de processos.
Imagine um arquivo contendo uma lista de pastas a serem avaliadas:
DOCUMENTOS
FOTOS
PROJETOS
CD 17
BACKUP
ANIMES
Um programa batch poderia ler cada registro e produzir um relatório.
O fluxo seria:
INÍCIO
|
ABRIR ARQUIVO
|
LER REGISTRO
|
FIM DO ARQUIVO?
| \
NÃO SIM
| |
VERIFICAR NOME FECHAR ARQUIVO
| |
GERAR ALERTA ENCERRAR
|
LER PRÓXIMO
Em COBOL, a leitura clássica poderia ser estruturada assim:
PERFORM ABRIR-ARQUIVOS
PERFORM LER-PASTA
PERFORM UNTIL FIM-DO-ARQUIVO
PERFORM PROCESSAR-PASTA
PERFORM LER-PASTA
END-PERFORM
PERFORM FECHAR-ARQUIVOS
Esse padrão é fundamental para quem começa em processamento batch.
Primeiro lemos um registro.
Depois repetimos o processamento até que o fim do arquivo seja encontrado.
Uma condição nível 88 pode representar o fim:
01 WS-FIM-ARQUIVO PIC X VALUE 'N'.
88 FIM-DO-ARQUIVO
VALUE 'S'.
88 NAO-FIM-ARQUIVO
VALUE 'N'.
Durante a leitura:
READ ARQ-PASTAS
AT END
SET FIM-DO-ARQUIVO TO TRUE
END-READ
Esse pequeno trecho contém uma das ideias mais importantes do COBOL: o programa trabalha continuamente com estados claros.
Fim ou não fim.
Registro válido ou inválido.
Transação aceita ou rejeitada.
Pasta comum ou CD 17.
8. JCL: convocando o programa para a aventura
Um programa COBOL compilado em ambiente mainframe normalmente precisa ser executado por meio de um job.
Exemplo simplificado:
//CD17JOB JOB (ACCT),'BELLACOSA',
// CLASS=A,
// MSGCLASS=X,
// NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=CD17CHK
//STEPLIB DD DSN=BELLACOS.CURSO.LOAD,DISP=SHR
//SYSOUT DD SYSOUT=*
//PASTAS DD DSN=BELLACOS.CURSO.CD17.DADOS,DISP=SHR
Vamos traduzir.
//CD17JOB JOB
define o job.
//STEP01 EXEC PGM=CD17CHK
solicita a execução do programa.
//STEPLIB DD
indica onde o sistema pode localizar o módulo executável.
//SYSOUT DD SYSOUT=*
direciona mensagens para a saída do job.
//PASTAS DD
associa um nome lógico usado pelo programa a um dataset real.
Esse mecanismo é poderoso.
O programa COBOL não precisa necessariamente conhecer o nome físico completo do arquivo.
Ele pode trabalhar com um nome lógico definido no SELECT.
O JCL informa qual dataset será usado naquela execução.
É como entregar ao aventureiro um mapa diferente para cada missão, sem alterar a espada.
9. Segurança: por que “apagar o histórico” não é suficiente
Agora precisamos interromper a comédia por alguns minutos.
Destruir arquivos, formatar discos ou apagar históricos não garante necessariamente que os dados tenham desaparecido de forma irrecuperável.
Em ambientes profissionais, a eliminação de informações deve seguir políticas específicas.
Podem existir:
No mainframe, segurança e governança são assuntos centrais.
O acesso pode ser controlado por produtos como RACF, ACF2 ou Top Secret.
A pergunta correta não é apenas:
“Onde está o arquivo?”
Também precisamos perguntar:
“Quem pode acessá-lo?”
“Quem acessou?”
“Por quanto tempo ele deve existir?”
“Existe obrigação legal de preservá-lo?”
“Quem autorizou sua exclusão?”
Portanto, no mundo corporativo, o amigo caridoso que recebe o pedido “apague tudo” deveria responder:
— Existe uma requisição de mudança aprovada?
O protagonista, já diante da deusa, perceberia então que nem a morte consegue vencer o processo de governança.
10. Backup: a bênção e a maldição
A ironia máxima da pasta CD 17 é que ela provavelmente existe porque alguém tentou fazer backup.
Backup é essencial.
Mas um backup sem organização pode transformar-se em um labirinto.
Uma estratégia útil costuma considerar múltiplas cópias, mídias diferentes e pelo menos uma cópia armazenada fora do equipamento principal.
Também é importante testar a restauração.
Um backup que nunca foi restaurado é apenas uma promessa otimista.
No mainframe, cópias podem ser realizadas por diversos mecanismos, dependendo do tipo de dado e da infraestrutura.
Para datasets, bancos e arquivos, podem existir processos específicos de:
cópia;
dump;
restore;
image copy;
archive;
migração;
recuperação.
O ponto principal é simples:
O objetivo do backup não é criar cópias.
O objetivo do backup é permitir recuperação.
Se o conteúdo da CD 17 for importante, deve existir uma estratégia de restauração.
Se for constrangedor, talvez seja melhor perguntar por que ele foi replicado em nove mídias, dois HDs externos e um pendrive chamado DRAGON_BACKUP_FINAL.
11. Easter eggs para os iniciados
Como toda aventura digna do Bellacosa Mainframe, precisamos esconder algumas referências.
Easter egg 1: retorno 17
Em sistemas reais, códigos de retorno devem ser definidos e documentados.
Mas, em nossa aventura, o programa secreto poderia terminar assim:
MOVE 17 TO RETURN-CODE
Quem visse o resultado no job perguntaria:
— O que significa RC=17?
A resposta oficial seria:
— Condição não documentada.
A resposta verdadeira:
— Alguém encontrou a pasta.
Easter egg 2: dataset geracional
A CD 17 poderia evoluir para um GDG:
BELLACOS.SECRET.CD17.G0001V00
BELLACOS.SECRET.CD17.G0002V00
BELLACOS.SECRET.CD17.G0003V00
Assim, cada atualização criaria uma nova geração.
Porque nada demonstra arrependimento verdadeiro como manter várias versões históricas do material que você jurou apagar.
Easter egg 3: comentário suspeito
Todo código antigo possui um comentário semelhante a:
* ALTERADO EM 1999 - NAO REMOVER
Ninguém sabe quem alterou.
Ninguém sabe por quê.
Ninguém remove.
A rotina permanece em produção até o ano de 2026.
Easter egg 4: o abend definitivo
Caso alguém tente abrir a pasta sem autorização:
S0C7
O famoso erro de dados inválidos.
Na narrativa, porém, ele significaria:
SECRET OCCULT CONTENT 7
Não procure essa definição em nenhum manual IBM.
12. Passo a passo para o COBOL iniciante não criar sua própria CD 17
Vamos encerrar com um pequeno guia prático.
Passo 1: use nomes compreensíveis
Evite:
01 A PIC X.
01 B PIC 9(05).
01 C PIC X(100).
Prefira:
01 WS-FIM-ARQUIVO PIC X.
01 WS-TOTAL-REGISTROS PIC 9(05).
01 WS-MENSAGEM-ERRO PIC X(100).
Passo 2: documente a finalidade
Um comentário útil explica a intenção.
* CONTROLA O ENCERRAMENTO DA LEITURA DO ARQUIVO.
Um comentário inútil apenas repete o comando.
* MOVE ZERO PARA O TOTAL
MOVE ZERO TO WS-TOTAL.
Passo 3: divida o processamento
Use parágrafos com responsabilidades claras:
1000-INICIALIZAR.
2000-LER-ARQUIVO.
3000-PROCESSAR-REGISTRO.
4000-GERAR-SAIDA.
9000-FINALIZAR.
Passo 4: trate erros
Não presuma que tudo funcionará.
Verifique:
status de arquivo;
códigos SQL;
condições de fim;
dados inválidos;
parâmetros ausentes;
resultados inesperados.
Passo 5: não esconda regras
Uma regra importante não deve estar enterrada em centenas de linhas.
Se CD 17 é proibida, declare isso claramente.
88 PASTA-PROIBIDA VALUE 'CD 17'.
Passo 6: pense no próximo mantenedor
O código será lido muitas vezes.
Às vezes, será lido por alguém que não conhece o sistema.
Às vezes, será lido por você mesmo após esquecer completamente o motivo de cada decisão.
Escreva como se o próximo programador fosse um aventureiro iniciante enviado para uma dungeon sem mapa.
Porque provavelmente será.
13. A verdadeira moral do isekai
No final, o herói foi enviado ao novo mundo.
Recebeu como habilidade especial a capacidade de compreender qualquer linguagem de programação antiga.
Infelizmente, a habilidade não incluía compreender requisitos mal escritos.
Ao chegar à primeira cidade, formou uma equipe composta por:
uma maga explosiva que compilava apenas uma vez por dia;
uma sacerdotisa com altíssima disponibilidade, mas nenhuma capacidade de recuperação;
uma cavaleira que aceitava todos os ataques e chamava isso de teste de carga;
uma deusa responsável pelo suporte técnico, mas que fechava os chamados como “erro do usuário”.
A primeira missão do grupo foi modernizar o sistema financeiro do reino.
O herói abriu o programa principal.
Encontrou 48 mil linhas de COBOL.
Nenhuma documentação.
Centenas de GO TO.
Arquivos com nomes incompreensíveis.
E um comentário no topo:
* SISTEMA PROVISORIO - SUBSTITUIR NO PROXIMO ANO
* CRIADO EM 1987
Ele respirou fundo.
Tomou um gole de café.
E disse:
— Talvez eu tenha sido atropelado por sorte.
Naquela noite, antes de dormir, perguntou à deusa se alguém havia cumprido seu último pedido no mundo anterior.
Ela abriu o painel celestial.
— Tenho boas e más notícias.
— Comece pelas boas.
— Seu amigo encontrou seu computador.
— E as más?
— Ele não apagou a pasta CD 17.
O herói empalideceu.
— Por quê?
— Porque encontrou dentro dela seus fontes COBOL, apostilas, fotografias de mainframes, wallpapers de anime, manuais antigos, scripts REXX, imagens do Johnny Castaway e um projeto chamado VERSAO_FINAL_AGORA_VAI.
O herói ficou em silêncio.
A deusa sorriu.
— Ele disse que aquilo não era uma pasta vergonhosa.
— Não?
— Era um museu.
E talvez essa seja a maior piada de todas.
Passamos décadas acumulando arquivos que parecem aleatórios, antigos ou embaraçosos. Porém, quando observados com distância, eles contam nossa história.
A pasta CD 17 não guarda apenas dados.
Ela guarda fases da vida.
Tecnologias que aprendemos.
Projetos que abandonamos.
Amizades.
Curiosidades.
Erros.
Descobertas.
Madrugadas diante do computador.
Versões antigas de quem fomos.
No mundo do mainframe, chamamos isso de legado.
Alguns usam a palavra como crítica.
Outros entendem que legado é aquilo que continuou funcionando tempo suficiente para se tornar importante.
Um sistema legado não é apenas velho.
Ele sobreviveu.
Foi alterado.
Corrigido.
Migrado.
Protegido.
Executado milhares de vezes.
Talvez a CD 17 seja exatamente isso:
Um pequeno sistema legado pessoal, sem documentação, com nomenclatura duvidosa, retenção indefinida e importância emocional impossível de calcular.
Portanto, antes de pedir que alguém incinere seu HD ao ser convocado para outro mundo, faça pelo menos três coisas:
Organize seus arquivos.
Documente o que importa.
E escolha muito bem a alma caridosa responsável pelo procedimento.
Porque, caso ela seja programadora COBOL, provavelmente não apagará nada.
Ela criará um backup.
Depois um GDG.
Depois uma cópia externa.
E finalmente um job diário chamado:
CD17BKP
Com DISP=SHR, NOTIFY=&SYSUID e retorno zero.
Afinal, neste mundo ou no próximo, todo verdadeiro profissional de mainframe sabe:
Dados importantes não desaparecem.
Eles apenas mudam de volume.
E o conteúdo da pasta CD 17?
Bem...
Essa informação está protegida por RACF.
ICH408I — ACESSO NEGADO.
Fim do job.
Ou talvez apenas o começo de uma nova aventura.
