✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe apresenta logica de programacao em mainframe
☕ Um Café no Bellacosa Mainframe
Lógica de Programação no Mainframe
O Guia Definitivo para um Programador Padawan Entender Como Pensar em COBOL Antes Mesmo de Escrever uma Linha de Código
"A diferença entre um programador júnior e um programador experiente raramente está na linguagem. Está na forma como ele pensa antes de começar a programar."
Introdução
Existe um mito que acompanha praticamente todo iniciante em Mainframe.
Muitos acreditam que aprender COBOL significa decorar comandos como MOVE, IF, PERFORM, READ, WRITE e COMPUTE.
Não.
Isso é parecido com decorar palavras de um idioma sem aprender a formar frases.
Programar não é escrever código.
Programar é resolver problemas.
O computador apenas executa a solução que você imaginou.
Quanto melhor for sua lógica, menor será seu código.
Quanto pior for sua lógica, maior será o desastre.
Curiosamente, essa afirmação vale ainda mais no mundo Mainframe.
Em um sistema bancário, um erro lógico pode movimentar milhões de reais para a conta errada.
Um erro de apenas um operador relacional pode impedir milhares de aposentadorias de serem pagas.
A máquina faz exatamente aquilo que você pediu.
Nunca aquilo que você queria.
Afinal, o que é lógica de programação?
Lógica é a capacidade de organizar pensamentos em uma sequência de passos capazes de resolver um problema.
Em outras palavras:
Entrada → Processamento → Saída
Todo programa do planeta funciona assim.
Sempre.
Sem exceções.
Imagine fazer café.
Entrada:
água
café
filtro
Processamento:
aquecer água
passar pelo pó
Saída:
café pronto
Um programa COBOL faz exatamente isso.
Entrada:
Arquivo de clientes
↓
Processamento
↓
Arquivo atualizado
Nada muda.
Apenas o problema é diferente.
O computador é extremamente inteligente...
...para fazer exatamente o que você mandar.
E extremamente burro para adivinhar.
Se você esquecer um caso específico...
Ele esquecerá também.
Exemplo
Você deseja aprovar clientes maiores de idade.
Errado:
SE IDADE > 18
O cliente com exatamente 18 anos será recusado.
O correto seria
IDADE >= 18
Esse pequeno detalhe pode causar milhares de erros.
A lógica mora justamente nesses detalhes.
O primeiro segredo dos grandes programadores
Eles passam muito mais tempo pensando do que digitando.
Um programador experiente pode gastar:
70%
pensando
20%
planejando
10%
escrevendo
Já o iniciante faz exatamente o contrário.
Antes do COBOL existe o algoritmo
Todo programa começa com uma receita.
Exemplo.
Problema:
Calcular média de um aluno.
Passos.
Receber nota 1
↓
Receber nota 2
↓
Somar
↓
Dividir por 2
↓
Mostrar resultado
Isso é um algoritmo.
COBOL vem depois.
Aprenda primeiro estas estruturas
Toda programação procedural é formada por apenas três estruturas.
SE saldo > 0
então saque permitido
senão
saque negado
No COBOL isso aparece como
IF
ELSE
END-IF
A vida inteira você fará isso.
3 — Repetição
Enquanto existir trabalho...
Continue trabalhando.
PERFORM UNTIL
PERFORM VARYING
São os famosos loops.
Curiosidade
Os três pilares da programação estruturada foram formalizados por Edsger W. Dijkstra, Ole-Johan Dahl e C. A. R. Hoare na década de 1960. A ideia revolucionária era simples: qualquer programa poderia ser construído usando apenas sequência, seleção e repetição, reduzindo drasticamente o uso de GOTO e tornando o software mais confiável.
Hoje, muitos times preferem programas menores e menos dependentes de SECTION, mas você encontrará ambos os estilos no mercado.
PERFORM é seu melhor amigo
Nunca copie código.
Faça um parágrafo.
Execute quando necessário.
PERFORM VALIDAR-CLIENTE
Muito melhor que repetir cinquenta linhas.
Variáveis
Uma variável representa um espaço reservado para armazenar informações.
Exemplo
Nome
Saldo
CPF
Data
Valor
Cada variável deve representar apenas uma ideia.
Não misture responsabilidades.
Um bom nome vale ouro
Ruim
A
X
TEMP
VAR1
Bom
WS-CLIENTE-SALDO
WS-VALOR-TOTAL
WS-DATA-PAGAMENTO
Você agradecerá daqui a dez anos.
E quem der manutenção também.
Expressões
Expressões representam cálculos.
A + B
SALDO - SAQUE
JUROS * TAXA
VALOR / PARCELAS
No COBOL moderno, COMPUTE simplifica expressões complexas, tornando o código mais legível.
Expressões booleanas
São perguntas.
IDADE >= 18
SALDO > 0
CPF = CPF-INFORMADO
Resultado?
VERDADEIRO
ou
FALSO
Toda programação gira em torno dessas respostas.
Operadores importantes
Igual
Maior
Menor
Maior ou igual
Menor ou igual
Diferente
AND
OR
NOT
Eles parecem simples.
Mas definem todo o comportamento do programa.
Fluxo de execução
Imagine uma estrada.
O programa começa.
Segue em frente.
Em alguns momentos:
vira
repete
retorna
encerra
Esse caminho é chamado fluxo.
Um fluxo claro é um programa fácil de manter.
O perigo do GO TO
Nos anos 70 era comum.
Hoje deve ser evitado.
Por quê?
Porque destrói o fluxo natural.
Cria o famoso:
"espaguete"
Linhas indo para todos os lados.
Difícil testar.
Difícil entender.
Difícil manter.
Por isso:
PERFORM
END-IF
EVALUATE
substituem praticamente todos os antigos GO TO.
EVALUATE
É o "switch" do COBOL.
Muito mais elegante que dezenas de IF aninhados.
Exemplo conceitual:
Cliente Ouro
↓
desconto
Cliente Prata
↓
desconto menor
Cliente Bronze
↓
sem desconto
Código mais limpo.
Mais fácil de ler.
Loops
No Mainframe você processará arquivos enormes.
Milhares.
Milhões.
Bilhões de registros.
Você não faz:
READ
READ
READ
READ
Você faz
PERFORM UNTIL EOF
Até chegar ao fim do arquivo.
EOF
Uma das primeiras variáveis que todo programador COBOL aprende.
WS-FIM-ARQUIVO
88 EOF VALUE "S"
Quando ela muda...
O loop termina.
Quase todo processamento batch funciona assim.
Subprogramas
Grandes bancos dividem responsabilidades.
Programa principal
↓
Chama
Subprograma
↓
Retorna resultado
Assim nasce software reutilizável.
Em COBOL isso ocorre com CALL.
O conceito de responsabilidade única
Cada parágrafo.
Cada rotina.
Cada subprograma.
Deve fazer apenas uma coisa.
Muito bem feita.
Esse conceito, hoje conhecido como Single Responsibility Principle, já aparecia naturalmente em muitos sistemas COBOL décadas antes de se popularizar na orientação a objetos.
Como pensar antes de programar
Faça estas perguntas.
Qual é o problema?
Quais dados entram?
Quais dados saem?
Quais regras existem?
Existem exceções?
O que acontece se faltar informação?
O arquivo pode estar vazio?
Pode existir duplicidade?
O valor pode ser negativo?
Quanto mais perguntas...
Menos bugs.
A diferença entre programar e desenvolver
Programar é escrever código.
Desenvolver é resolver problemas.
Um excelente desenvolvedor pode escrever poucas linhas.
Mas resolver um problema enorme.
O Mainframe muda sua forma de pensar
Aqui você aprende que:
dados são patrimônio;
performance importa;
I/O custa caro;
cada acesso a disco deve ser pensado;
processar um milhão de registros é rotina;
estabilidade vale mais que criatividade.
Essa mentalidade acompanha você por toda a carreira, mesmo trabalhando depois com Java, Python, Go ou JavaScript.
A disciplina do COBOL
COBOL obriga você a ser organizado.
Divisões bem definidas.
Dados separados da lógica.
Nomes claros.
Fluxo explícito.
Isso forma excelentes engenheiros de software.
Não por acaso, muitos arquitetos de grandes bancos começaram suas carreiras escrevendo COBOL.
Os erros mais comuns dos iniciantes
Programar antes de entender o problema.
Criar variáveis com nomes sem significado.
Misturar validação, cálculo e gravação na mesma rotina.
Usar GO TO sem necessidade.
Ignorar casos de erro e exceções.
Esquecer o tratamento de fim de arquivo.
Repetir código em vez de criar parágrafos reutilizáveis.
Não documentar regras de negócio complexas.
Alterar programas sem compreender seu fluxo completo.
Testar apenas o "caminho feliz", esquecendo entradas inválidas e situações de borda.
Trilha de estudos para um Padawan Mainframe
Uma sequência eficiente de aprendizado é:
Lógica de programação.
Algoritmos e fluxogramas.
Tipos de dados e variáveis.
Operadores e expressões.
Estruturas de decisão (IF e EVALUATE).
Estruturas de repetição (PERFORM, UNTIL e VARYING).
Modularização com parágrafos, SECTION e subprogramas.
Arquivos sequenciais e VSAM.
JCL e execução batch.
CICS, Db2, APIs e integração com o mundo moderno.
Easter Egg ☕
Existe uma velha brincadeira entre programadores veteranos.
Perguntaram a um desenvolvedor COBOL:
— Quantas linguagens você conhece?
Ele respondeu:
— Muitas.
— Então por que continua usando COBOL?
O veterano sorriu:
— Porque o banco prefere que o dinheiro continue chegando na conta certa.
A piada resume uma grande verdade: linguagens vêm e vão, mas a lógica permanece. Quem domina lógica aprende qualquer linguagem com muito mais facilidade.
Curiosidade histórica
Grace Hopper, uma das pioneiras da computação e uma das maiores influências para o COBOL, costumava dizer:
"A frase mais perigosa da linguagem é: 'Sempre fizemos assim'."
Embora COBOL seja uma linguagem com mais de seis décadas, ela continua evoluindo. Hoje suporta recursos modernos como JSON, XML, UTF-8, integração com APIs REST, chamadas a serviços, tratamento avançado de dados e otimizações para arquiteturas IBM Z. O que permanece imutável não é a sintaxe, mas a lógica por trás da solução.
Conclusão
Todo programador COBOL experiente conhece centenas de comandos.
Mas isso nunca foi o diferencial.
O diferencial sempre foi saber pensar.
A lógica de programação é a verdadeira linguagem universal da computação. Ela atravessa décadas, plataformas e paradigmas. O profissional que domina sequência, seleção, repetição, modularização, fluxo de execução e organização do pensamento será capaz de trabalhar não apenas com COBOL, mas também com Java, Python, C#, JavaScript, Go ou qualquer tecnologia que surgir no futuro.
No Mainframe, essa disciplina ganha um valor ainda maior. Cada programa processa informações críticas para bancos, seguradoras, hospitais, governos e empresas que movimentam bilhões de transações diariamente. Não há espaço para improvisação: clareza, simplicidade e previsibilidade são virtudes.
Lembre-se sempre desta máxima do Bellacosa Mainframe:
"O computador não premia quem escreve mais código. Ele recompensa quem pensa melhor. Antes de aprender COBOL, aprenda a organizar suas ideias. Depois disso, a linguagem será apenas uma ferramenta nas mãos de um verdadeiro engenheiro de software."
Bellacosa Mainframe do visual basic ao cobol no zos
☕ Um Café no Bellacosa Mainframe
Do Visual Basic ao COBOL no IBM Z
Você Não Está Abandonando o Desenvolvimento Desktop. Está Descobrindo Onde Muitos Sistemas Críticos Nunca Pararam de Evoluir.
"Quem programa em Visual Basic já aprendeu uma das lições mais importantes da engenharia de software: transformar regras de negócio em aplicações que resolvem problemas reais. Aprender COBOL no IBM Z não significa voltar ao passado. Significa compreender por que os maiores bancos, seguradoras, empresas aéreas e governos do mundo continuam confiando em uma plataforma que processa bilhões de transações diariamente."
Existe um mito bastante difundido na comunidade de tecnologia.
Ele diz que quem vem do Visual Basic encontrará um ambiente completamente diferente ao entrar no universo do Mainframe.
Na prática, isso não é verdade.
A tecnologia muda.
A plataforma muda.
A arquitetura muda.
Mas o pensamento de engenharia continua exatamente o mesmo.
Você continua recebendo requisitos.
Continua modelando dados.
Continua tratando exceções.
Continua escrevendo lógica de negócio.
Continua produzindo software para pessoas.
A diferença é que agora seu programa poderá executar em um computador capaz de atender milhares de empresas simultaneamente, com disponibilidade próxima de 100%, segurança extremamente rigorosa e décadas de evolução contínua.
Bem-vindo ao IBM Z.
Antes de comparar linguagens, compare mentalidades
Quem desenvolve em Visual Basic normalmente pensa em aplicações desktop, sistemas administrativos, ERPs internos, automações comerciais ou integração com bancos de dados.
O foco costuma ser:
interface gráfica;
formulários;
eventos;
botões;
menus;
relatórios;
banco de dados.
No Mainframe o foco muda.
A pergunta deixa de ser:
"Como o usuário clica no botão?"
e passa a ser:
"Como garantir que um milhão de operações financeiras sejam processadas corretamente?"
É outra escala.
Outra responsabilidade.
Outra arquitetura.
Bellacosa Mainframe vb versus cobol no zos
O que um programador VB já sabe (e talvez não perceba)
Muitos imaginam que começar COBOL significa começar programação do zero.
Na verdade, quem domina Visual Basic já possui diversas habilidades importantes.
Você descreve exatamente como os dados serão armazenados.
Essa preocupação é uma das razões pelas quais aplicações COBOL permanecem rápidas e confiáveis décadas depois.
Estruturas IF
Visual Basic
If Salario > 5000 Then
Bonus = 1000
End If
COBOL
IF WS-SALARIO > 5000
MOVE 1000 TO WS-BONUS
END-IF
Praticamente o mesmo raciocínio.
Estruturas de repetição
Visual Basic
For I = 1 To 10
COBOL
PERFORM VARYING I FROM 1 BY 1
UNTIL I > 10
O conceito continua sendo um loop.
Procedimentos
Visual Basic
Sub Calcular()
COBOL
CALCULAR.
Os dois organizam o código em pequenas unidades reutilizáveis.
A maior diferença: Interface
Visual Basic nasceu para interfaces gráficas.
COBOL nasceu para processamento de dados.
Enquanto VB pergunta:
"Qual botão foi clicado?"
COBOL pergunta:
"Qual registro deve ser atualizado?"
É uma mudança importante de perspectiva.
Banco de dados continua sendo banco de dados
Quem trabalha com Visual Basic geralmente conhece SQL Server, Oracle, PostgreSQL ou MySQL.
No Mainframe você encontrará principalmente:
Db2 for z/OS
IMS
VSAM
A boa notícia?
SQL continua sendo SQL.
Exemplo:
SELECT
NOME,
SALARIO
FROM FUNCIONARIO
O conhecimento continua válido.
Você apenas aprende algumas características específicas do Db2 para IBM Z.
Arquivos existem dos dois lados
Visual Basic pode trabalhar com:
TXT
CSV
XML
JSON
COBOL trabalha com:
Sequential Files
VSAM
GDG
datasets
Ambos processam informações.
A diferença está na infraestrutura.
O pensamento empresarial é parecido
Grande parte dos programas VB resolve regras de negócio.
Grande parte dos programas COBOL também.
Por exemplo:
calcular impostos;
calcular folha;
emitir boletos;
validar documentos;
gerar extratos;
processar pagamentos.
Não existe "programação antiga".
Existe lógica empresarial.
O que realmente muda
Agora começam as novidades.
Você precisará aprender o ambiente IBM Z
Quem vem do Visual Basic normalmente conhece Windows.
Talvez Linux.
No Mainframe você conhecerá:
z/OS
TSO
ISPF
SDSF
JES2
RACF
Esses nomes parecem assustadores.
Depois de algumas semanas passam a ser ferramentas do dia a dia.
Aprenda primeiro o sistema operacional
Muitos iniciantes querem aprender COBOL imediatamente.
É um erro.
Primeiro aprenda onde o programa vive.
Entenda:
datasets;
catálogo;
usuários;
jobs;
spool;
compilação.
Depois o COBOL fará muito mais sentido.
Aprenda JCL cedo
Quem vem do Visual Basic costuma estranhar o JCL.
Mas pense nele como um script de automação.
Em vez de clicar:
Compilar
Executar
Gerar relatório
você descreve tudo em um Job.
O computador faz o restante.
JCL é muito menos complicado do que parece.
O Terminal não é um inimigo
O terminal 3270 assusta muita gente.
Até o primeiro dia.
Depois ele se torna uma das interfaces mais produtivas já criadas.
Sem distrações.
Sem dezenas de janelas.
Sem milhares de ícones.
Somente trabalho.
COBOL é extremamente legível
Visual Basic sempre foi conhecido pela clareza.
COBOL também.
Veja:
ADD VALOR TO TOTAL
SUBTRACT DESCONTO FROM TOTAL
MULTIPLY QUANTIDADE BY PRECO
É praticamente inglês.
Essa legibilidade foi planejada desde sua criação.
O que estudar primeiro
Minha sugestão para quem vem do Visual Basic é seguir uma ordem diferente da maioria.
Etapa 1
Aprenda:
arquitetura IBM Z;
o que é Mainframe;
Batch;
Online;
CICS;
Db2.
Sem escrever uma linha de código.
Etapa 2
Aprenda:
TSO;
ISPF;
datasets;
membros;
PF Keys;
edição.
Domine o ambiente.
Etapa 3
Aprenda JCL.
Compilar.
Executar.
Ler mensagens.
Interpretar erros.
Etapa 4
Agora sim.
COBOL.
Primeiro:
DATA DIVISION
WORKING-STORAGE
PROCEDURE DIVISION
Depois:
IF
PERFORM
EVALUATE
SEARCH
OCCURS
COPYBOOKS
Etapa 5
Arquivos
Aprenda:
Sequential
VSAM
Sort
Merge
Etapa 6
Db2
Depois:
Embedded SQL
Cursor
Commit
Rollback
Etapa 7
CICS
Aprenda:
COMMAREA
MAPS
BMS
EXEC CICS
O que treinar diariamente
Não basta assistir aulas.
É necessário escrever código.
Todos os dias.
Exercícios interessantes:
cadastro de clientes;
folha de pagamento;
controle de estoque;
extrato bancário;
cálculo de impostos;
geração de arquivos;
leitura de VSAM;
consultas Db2.
O que esquecer durante a transição
Alguns hábitos do desenvolvimento desktop precisam ser adaptados.
Não pense primeiro na interface.
Pense primeiro nos dados.
Não pense em formulários.
Pense em registros.
Não pense em telas bonitas.
Pense em consistência.
No Mainframe, um programa elegante é aquele que processa milhões de registros corretamente.
O que aprender além do COBOL
Hoje um desenvolvedor Mainframe moderno normalmente conhece:
COBOL
SQL
Db2
JCL
CICS
REXX
z/OS
Git
VS Code
Zowe
APIs REST
JSON
XML
DevOps
OpenTelemetry
CI/CD
Perceba que o Mainframe atual conversa naturalmente com tecnologias modernas.
Você não está entrando em um mundo isolado.
Está entrando em um ecossistema conectado à nuvem, microsserviços, APIs e aplicações distribuídas.
A vantagem de quem vem do Visual Basic
Há algo que costuma surpreender.
Desenvolvedores Visual Basic frequentemente possuem forte conhecimento de processos empresariais.
Eles já trabalharam com:
faturamento;
estoque;
financeiro;
RH;
contabilidade;
logística.
Esses conhecimentos são extremamente valorizados no Mainframe.
Muitas vezes, entender a regra de negócio é mais importante do que conhecer toda a sintaxe da linguagem.
Ensinar COBOL leva semanas.
Ensinar décadas de experiência em processos empresariais leva muito mais tempo.
Os erros mais comuns
Os iniciantes costumam:
querer aprender tudo ao mesmo tempo;
ignorar JCL;
ignorar o z/OS;
decorar comandos;
copiar programas sem entender.
Faça diferente.
Entenda primeiro a arquitetura.
Depois escreva código.
Uma trilha de 24 semanas
Semanas 1–2: Fundamentos do IBM Z, arquitetura, Batch × Online, datasets e conceitos de z/OS.
Semanas 3–4: TSO/ISPF, edição, organização de bibliotecas, navegação e produtividade.
Semanas 5–6: JCL, catálogo, utilitários, compilação, execução e análise de mensagens no SDSF.
Semanas 7–10: COBOL básico: divisões, tipos de dados, operações, IF, EVALUATE, PERFORM, tabelas e modularização.
Semanas 11–12: Arquivos sequenciais, SORT, MERGE, VSAM KSDS e processamento de registros.
Semanas 13–16: Db2 para z/OS, SQL embarcado, cursores, tratamento de SQLCODE e boas práticas.
Semanas 17–20: CICS, BMS, COMMAREA, transações e programação online.
Semanas 21–22: REXX, utilitários, automação e produtividade no ambiente z/OS.
Semanas 23–24: Git, Zowe, VS Code, APIs REST, JSON, integração com aplicações modernas e práticas de DevOps para IBM Z.
Ao final desse percurso, você terá uma visão sólida do ciclo completo de desenvolvimento em Mainframe, desde a edição de código até a execução de aplicações críticas.
O Mainframe de Hoje
Existe outra ideia equivocada: a de que aprender Mainframe é aprender uma tecnologia "presa no passado".
Na realidade, o IBM Z evoluiu continuamente. Hoje ele executa cargas com Linux, Java, Python, Node.js, Go, APIs REST, containers, OpenTelemetry, criptografia avançada, autenticação moderna e integração com ambientes de nuvem. O COBOL continua sendo essencial porque representa décadas de regras de negócio consolidadas, mas ele convive diariamente com tecnologias contemporâneas.
Aprender COBOL não limita sua carreira. Amplia seu repertório e permite atuar em um dos ambientes de computação mais robustos do planeta.
Conclusão
Quem vem do Visual Basic não está recomeçando a carreira.
Está adicionando uma nova dimensão àquilo que já sabe fazer.
Você continuará escrevendo algoritmos.
Continuará resolvendo problemas.
Continuará construindo software.
A diferença é que agora seus programas poderão participar da infraestrutura que movimenta cartões de crédito, transferências bancárias, seguros, companhias aéreas, sistemas governamentais e grandes empresas em todo o mundo.
No Bellacosa Mainframe costumamos dizer que linguagens são ferramentas, mas engenharia de software é uma forma de pensar.
Se você aprendeu a desenvolver em Visual Basic, já possui a base mais importante: transformar necessidades do negócio em soluções confiáveis.
O IBM Z apenas leva essa engenharia a outro patamar — onde desempenho, disponibilidade, segurança e décadas de evolução caminham lado a lado.
Talvez a maior descoberta nessa jornada seja perceber que o Mainframe não é um museu da computação. É um dos lugares onde a engenharia de software mais madura continua sendo escrita, executada e aperfeiçoada todos os dias.
Quando um Programador COBOL Descobre que o Job Mais Importante do Sistema é Impedir que Novos Usuários Executem o Programa
Se existe um anime que destrói completamente as expectativas do gênero isekai logo no primeiro episódio, esse anime é Shokei Shoujo no Virgin Road, conhecido internacionalmente como The Executioner and Her Way of Life. Em vez de contar a história do tradicional protagonista transportado para outro mundo e destinado a se tornar um herói, a obra mostra justamente o outro lado: quem precisa impedir que esses "heróis" destruam o mundo.
Dados da obra
Título original: 処刑少女の生きる道〈バージンロード〉 (Shokei Shoujo no Virgin Road)
Título em inglês: The Executioner and Her Way of Life
Autor: Mato Sato
Ilustrações: Nilitsu
Estúdio: J.C.STAFF
Diretor: Yoshiki Kawasaki
Anime: abril a junho de 2022
Episódios: 12
Origem: Light Novel
Gênero:
Isekai Reverso
Dark Fantasy
Ação
Aventura
Yuri
Drama
Mistério
Seinen
Classificação: +16 anos (violência, temas psicológicos e mortes).
Sinopse
Durante séculos pessoas do Japão aparecem misteriosamente naquele mundo.
Esses visitantes recebem poderes chamados Pure Concepts (Conceitos Puros).
O problema?
Esses poderes crescem sem limite.
Mais cedo ou mais tarde seus usuários enlouquecem.
E quando isso acontece...
...catástrofes continentais acontecem.
Por isso existe uma organização secreta.
As Executioners (Carrascas).
Sua missão é eliminar os japoneses antes que se tornem uma ameaça.
Nossa protagonista é justamente uma delas.
Resumo da história
Menou aparenta ser uma jovem sacerdotisa.
Na verdade ela é uma assassina profissional treinada pela Igreja.
Quando Akari Tokitou chega daquele mundo, Menou tenta executá-la imediatamente.
Mas surge um enorme problema.
Akari simplesmente...
não consegue morrer.
Seu poder manipula o tempo.
Toda tentativa de assassinato reinicia automaticamente sua própria morte.
A partir daí começa uma longa jornada onde Menou procura uma maneira definitiva de matar Akari, enquanto as duas acabam criando uma relação cada vez mais profunda.
Principais personagens
Menou
A protagonista.
Calma.
Extremamente competente.
Foi treinada desde pequena para eliminar Lost Ones.
É provavelmente uma das protagonistas mais diferentes do gênero isekai.
Akari Tokitou
A garota japonesa invocada.
Gentil.
Ingênua.
Muito poderosa.
Seu Pure Concept controla o tempo.
Momo
Assistente de Menou.
Extremamente forte.
Possui enorme admiração (quase obsessiva) por Menou.
Grande parte do humor da série vem dela.
Ashuna
Princesa guerreira.
Carismática.
Adora lutar.
Rouba praticamente todas as cenas onde aparece.
Flare
Mestra de Menou.
Uma verdadeira lenda entre as Executioners.
O que torna esse anime diferente?
Quase tudo.
Enquanto a maioria dos isekais diz:
"Os japoneses salvarão o mundo."
Virgin Road diz:
"Os japoneses são exatamente o maior perigo do mundo."
É praticamente um anti-isekai.
O protagonista normalmente é o convocado.
Aqui a protagonista é quem precisa matá-lo.
Essa inversão de perspectiva foi um dos grandes diferenciais da obra.
Temáticas
consequências do poder absoluto
responsabilidade
livre-arbítrio
destino
fanatismo religioso
culpa
sacrifício
memória
identidade
amor impossível
As aventuras
Durante a viagem conhecemos:
cidades sagradas
desertos mágicos
fortalezas religiosas
monstros
antigos experimentos
civilizações destruídas pelos Lost Ones
Cada arco revela um pedaço da história daquele mundo.
E principalmente...
dos quatro grandes desastres provocados por japoneses do passado.
Mensagens ocultas
O herói pode ser o vilão
A obra questiona a ideia clássica do "escolhido".
Nem todo protagonista merece sobreviver.
Poder infinito é uma maldição
Quanto maior o Pure Concept...
mais próxima está a destruição.
A Igreja não é totalmente boa
Ela protege o mundo.
Mas faz isso através de assassinatos.
Existe um enorme conflito moral.
O tempo prende tanto quanto liberta
Akari representa alguém incapaz de seguir em frente.
Seu poder simboliza justamente a impossibilidade de aceitar perdas.
Impacto cultural
Embora não tenha alcançado a popularidade de grandes isekais, Virgin Road foi bastante comentado por subverter o gênero logo em seu episódio de estreia. Também recebeu atenção por colocar duas protagonistas femininas no centro da narrativa e desenvolver um relacionamento yuri integrado à história, em vez de apenas fanservice.
Censura
Não possui censura significativa.
As cenas violentas são moderadas.
O foco está muito mais:
no suspense
nas decisões morais
nos diálogos
nos conflitos psicológicos
do que em violência gráfica.
Light Novel
Início: 12 de julho de 2019
Autor: Mato Sato
Ilustrações: Nilitsu
Publicação: GA Bunko / SB Creative
Encerrada em março de 2025 com 11 volumes.
Mangá
Início: 5 de junho de 2020
Arte: Ryō Mitsuya
Revista: Young Gangan
Publicado pela Square Enix, com 7 volumes.
Games
Até o momento, a franquia não recebeu um jogo próprio para consoles ou PC. Ela permanece concentrada na light novel, mangá e anime.
Curiosidades
O anime é produzido pelo estúdio J.C.STAFF, responsável por obras como Toradora!, DanMachi e A Certain Magical Index.
O primeiro episódio ficou famoso por surpreender quem esperava um isekai tradicional, graças a uma grande reviravolta logo no início.
O título "Virgin Road" faz referência simbólica a um "caminho ainda não percorrido", reforçando o tema de romper com os clichês do gênero.
Bellacosa Mainframe ☕
Imagine um ambiente z/OS onde todo programa vindo de fora possui autoridade UID(0), acesso APF e permissão para alterar o núcleo do sistema.
O administrador experiente não perguntaria:
"Como faço esse programa funcionar?"
Ele perguntaria:
"Como impedir que ele derrube o CPD inteiro?"
Menou é exatamente essa administradora.
Enquanto todo mundo celebra a chegada de um novo "usuário especial", ela já sabe, pela experiência, que cada nova execução pode ser o próximo ABEND capaz de destruir toda a produção.
É um dos isekais mais inteligentes da década justamente porque troca o sonho do poder absoluto pela responsabilidade de impedir uma catástrofe antes que ela aconteça.
Bellacosa Mainframe apresenta o idcams para o vsam
☕ Um Café no Bellacosa Mainframe
Melvin Udall Entra no IDCAMS — O Homem que Não Aceitava Arquivo Fora de Ordem, Índice Sem BLDINDEX nem RC=8 Sem Explicação
Ou: como o VSAM deixou de ser “aquele arquivo do COBOL” e revelou uma cidade inteira de CIs, CAs, catálogos, índices alternativos, backups, reorganizações e pequenos desastres esperando alguém escrever DELETE ... PURGE no dataset errado
Há pessoas que olham para um arquivo VSAM e dizem: “é só um arquivo”.
Melvin Udall, o escritor rabugento de Melhor Impossível, olharia para essa frase, ajustaria as luvas, evitaria encostar no terminal compartilhado e responderia algo como:
“Não. ‘Só um arquivo’ é o que você diz cinco minutos antes de apagar a produção.”
E, desta vez, Melvin estaria certo.
Para o programador COBOL iniciante, VSAM parece inicialmente uma sigla misteriosa usada por veteranos quando querem tornar uma reunião mais silenciosa. Você vê algo assim no programa:
SELECT ARQ-CLIENTE
ASSIGN TO VSAM-CLIENTE
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS CLI-CPF.
E pensa: “Pronto. Tenho um arquivo indexado. O COBOL abre, lê, grava e fecha.”
Sim. Mas isso é como ver a porta de um banco e concluir que compreendeu tesouraria, segurança, auditoria, cofre, sistema antifraude, ar-condicionado do datacenter e o senhor que aparece às três da manhã perguntando por que o batch não fechou.
O programa COBOL usa o VSAM. Mas alguém precisou criar esse VSAM. Alguém precisa verificar se o arquivo existe, descobrir sua chave, conferir o espaço disponível, copiar seus registros, refazer índices, investigar mensagens estranhas e reorganizá-lo quando ele envelhece mal.
Esse alguém — ao menos na maior parte dos ambientes z/OS — conversa com o IDCAMS.
E, se Melvin Udall fosse o responsável pelo VSAM, ele não permitiria uma única chave fora de posição, um único índice alternativo esquecido ou um único RC=8 sendo tratado com a clássica frase corporativa: “mas o job terminou”.
Prólogo — O arquivo que não era apenas um arquivo
VSAM significa Virtual Storage Access Method. É uma tecnologia criada pela IBM para organizar e acessar dados no ambiente de mainframe com eficiência, previsibilidade e capacidade de sobreviver ao tipo de volume que faz uma planilha do Excel pedir aposentadoria.
Sua origem está na evolução dos sistemas IBM da família OS/VS. Antes do VSAM, havia modelos de arquivos mais separados e especializados, como sequenciais tradicionais e ISAM. Cada qual tinha seu estilo, suas limitações e seu conjunto de utilitários.
O VSAM trouxe uma visão mais integrada.
Em vez de tratar o armazenamento como uma sequência de registros soltos, ele introduziu uma organização formada por:
Estruturas lógicas;
Componentes de dados;
Componentes de índice;
Catálogos;
Unidades internas de leitura e gravação;
Controle de espaço;
Possibilidade de acesso direto por chave;
Estruturas alternativas de busca.
O VSAM não nasceu para ser “bonito” no sentido moderno da palavra. Ele nasceu para ser confiável, eficiente e administrável em ambientes nos quais perder ou duplicar uma transação não era um bug simpático: era um problema bancário, fiscal, logístico ou governamental.
E aqui começa a primeira lição Melvin Udall para o jovem padawan COBOL:
“Você pode não querer entender como o arquivo foi criado. O arquivo não tem a mesma obrigação em relação a você.”
1. IDCAMS: o administrador do condomínio VSAM
IDCAMS significa Integrated Data Cluster Access Method Services.
Pense nele como o administrador rigoroso do condomínio VSAM. Ele não processa a folha de pagamento nem calcula juros. Ele prepara o prédio onde esses dados irão morar, consulta as plantas, verifica rachaduras, copia apartamentos, troca placas, recria portarias e avisa quando alguém tentou estacionar um caminhão dentro da sala.
Podem indicar arquivos de entrada, saída, backup ou carga
O SYSIN é onde vivem comandos como:
DEFINE
DELETE
LISTCAT
REPRO
PRINT
VERIFY
EXAMINE
EXPORT
IMPORT
BLDINDEX
ALTER
SET
Um conselho de sobrevivência: nunca trate SYSPRINT como decoração. É ali que o IDCAMS explica o que fez, o que não fez e por que decidiu que seu plano era uma má ideia.
O RC do job indica a gravidade geral. As mensagens explicam a causa.
Melvin colocaria isso em uma moldura:
“Código de retorno não é diagnóstico. É apenas a campainha tocando.”
2. Os quatro moradores principais: KSDS, ESDS, RRDS e LDS
Antes de criar um arquivo, você precisa saber que tipo de VSAM faz sentido.
Tipo
Como organiza
Uso típico
KSDS
Por chave
Clientes, contas, produtos, contratos
ESDS
Ordem de inclusão
Logs, eventos, trilhas de auditoria
RRDS
Número relativo de registro
Tabelas com posições fixas
LDS
Sequência bruta de bytes
Produtos especializados e estruturas próprias
O rei do cotidiano COBOL é o KSDS — Key Sequenced Data Set.
Nele, os registros são organizados pela chave. Se CPF é a chave, o VSAM sabe encontrar o cliente sem precisar ler todos os demais.
Exemplo de dados:
CPF NOME
01234567890 ANA SILVA
12345678901 BRUNO COSTA
98765432100 CARLA MENDES
O KSDS mantém uma estrutura de índice que permite localizar o registro pela chave.
No COBOL, isso aparece em operações como:
MOVE WS-CPF-PROCURADO TO CLI-CPF
READ ARQ-CLIENTE
KEY IS CLI-CPF
INVALID KEY
DISPLAY 'CLIENTE NAO ENCONTRADO'
END-READ
Mas a magia não acontece porque o COBOL “leu rápido”. Ela acontece porque o VSAM foi corretamente definido, carregado e mantido.
3. Cluster, DATA e INDEX: a casa, os móveis e o mapa
O principal objeto VSAM é o cluster.
No caso de um KSDS, há normalmente dois componentes físicos importantes:
DATA component: onde os registros estão;
INDEX component: onde estão chaves e ponteiros para localizar os registros.
O INDEX é o catálogo que diz em qual corredor e estante o livro está.
Se o índice tem problema, o livro pode continuar fisicamente ali, mas encontrá-lo fica muito mais difícil. Se você tem uma chave definida incorretamente, é como organizar livros pelo terceiro caractere do sobrenome do autor e fingir que aquilo faz sentido.
Melvin Udall chamaria isso de “uma arquitetura concebida por alguém que odeia leitores”.
4. Criando um KSDS com DEFINE CLUSTER
Vamos criar um cadastro de clientes cuja chave é um CPF de 11 bytes a partir da posição zero do registro.
Nesse caso, o CPF não começa no byte zero. Você precisa calcular a posição real com precisão. Não é chute, não é sensação, não é “acho que começa ali perto”.
Em mainframe, “quase certo” é apenas uma forma educada de dizer “errado”.
5. CI e CA: onde o VSAM realmente acomoda os registros
Dois conceitos assustam muita gente no início:
CI — Control Interval;
CA — Control Area.
Vamos simplificar sem mentir.
Um CI é como uma página organizada onde o VSAM coloca vários registros. É uma unidade de I/O: quando o VSAM lê ou grava, ele trabalha em torno dessas unidades.
Um CA é um conjunto de CIs.
Assim:
Cluster
└── Control Area
├── Control Interval
│ ├── Registro 1
│ ├── Registro 2
│ └── Espaço livre
├── Control Interval
└── Control Interval
Quando você insere um registro em um KSDS, ele precisa caber em algum CI na posição correta da chave.
Se não há espaço suficiente, o VSAM pode realizar um CI Split. Se a situação envolve uma estrutura maior, pode ocorrer um CA Split.
Isso não significa automaticamente corrupção ou desastre. É o VSAM reorganizando espaço para continuar atendendo inclusões.
Mas muitos splits podem criar fragmentação e aumentar o custo de I/O.
É por isso que existe:
FREESPACE(20 10)
A ideia é reservar espaço para que futuras inserções entre chaves existentes tenham onde ficar.
O primeiro número representa espaço livre dentro dos CIs;
O segundo define uma reserva de CIs livres em cada CA.
Se seu arquivo é carregado uma vez, raramente recebe inclusões e é muito lido, exagerar no FREESPACE desperdiça espaço.
Se ele recebe inserções constantes, principalmente em posições intermediárias da chave, um FREESPACE pequeno pode transformar seu KSDS em uma cidade que cresceu sem plano diretor.
Melvin provavelmente teria uma opinião sobre bairros construídos sem planejamento.
6. REPRO: a mudança de casa dos registros
REPRO é o subcomando usado para copiar dados.
Para fazer uma carga inicial de um arquivo sequencial para um KSDS:
É uma ferramenta excelente para ambientes de teste abandonados por gerações anteriores. Você começa procurando um KSDS e descobre seis versões, três índices alternativos, um PATH sem dono e um dataset chamado TESTE.FINAL.DEFINITIVO.NOVO2.
A arqueologia do mainframe é real.
8. PRINT: quando olhar o dado é melhor do que imaginar o dado
HEX ajuda quando há campos binários, COMP, COMP-3 ou caracteres estranhos;
DUMP é mais técnico e detalhado.
Um registro pode parecer correto em tela, mas possuir bytes inesperados. Um campo COMP-3 gravado com layout errado pode deixar o dado aparentemente normal em parte do processo e explodir em um S0C7 na etapa seguinte.
O hex não mente. Ele apenas não se esforça para ser simpático.
9. DELETE: a palavra que Melvin não deixaria você digitar sem backup
PURGE é um parâmetro que exige cuidado. Não é um tempero para fazer o comando “funcionar melhor”. É uma autorização mais agressiva para remover o objeto sob certas condições.
Antes de executar qualquer exclusão, faça o ritual que Melvin transformaria em lei:
Confira o HLQ;
Confirme ambiente de teste, homologação ou produção;
Faça LISTCAT;
Verifique AIX e PATH associados;
Garanta backup;
Leia o JCL como se ele tivesse sido escrito por seu inimigo;
Só então submeta.
Um DELETE errado pode terminar em segundos. A explicação ao gerente, ao auditor e ao time de recuperação costuma durar muito mais.
10. Backup lógico: EXPORT, IMPORT e a diferença entre guardar dados e preservar uma estrutura
Há duas ideias que muitos iniciantes misturam:
Copiar os registros;
Preservar uma imagem lógica do VSAM.
Com REPRO, você normalmente copia dados. É ótimo para descarregar e recarregar registros.
Com EXPORT, você cria uma exportação lógica que pode ser restaurada por IMPORT.
Em produção, empresas podem usar DFSMShsm, FDR, CA Disk, ferramentas de backup corporativo, storage replication e procedimentos de disaster recovery. O IDCAMS não substitui automaticamente toda essa arquitetura.
Mas ele é importantíssimo para backup lógico, migração, laboratório e recuperação controlada.
A verdade impopular é:
Backup não testado é um arquivo de ficção científica.
Se ninguém executou um IMPORT em ambiente seguro, ninguém sabe com certeza se aquele backup salvará o dia.
11. Alternate Index: encontrar um cliente sem usar a chave principal
Suponha que seu KSDS usa CPF como chave primária. Isso é ótimo quando o usuário tem o CPF.
Mas e se o negócio pede pesquisa por agência, cidade, código do produto ou e-mail?
Você poderia criar outro arquivo inteiro. Mas isso aumenta duplicação, manutenção e risco de inconsistência.
A solução VSAM é o AIX — Alternate Index.
O AIX cria uma segunda porta de busca para o mesmo cluster base.
O VERIFY pode ajudar com informações de fim lógico e condições relacionadas a encerramento impróprio. Mas ele não é um super-herói de capa azul capaz de recuperar tudo.
Ele não substitui:
Diagnóstico;
Backup;
Recuperação corporativa;
Análise de mensagens;
Reparo de aplicação que escreveu dados errados.
Use VERIFY porque há evidência de que ele se aplica, não porque o job apresentou uma mensagem assustadora e alguém sugeriu “rodar um verify para ver se melhora”.
13. EXAMINE: o CSI dentro do Control Interval
Se VERIFY é uma checagem focada em consistência de término, EXAMINE é o investigador forense.
INDEXTEST verifica aspectos do componente de índice;
DATATEST verifica aspectos do componente de dados;
A análise pode revelar inconsistências estruturais, problemas internos e situações que exigem recuperação ou reconstrução.
Quando ouvir “o arquivo está corrompido”, não transforme isso em verdade antes de investigar.
Pode haver:
Falha de I/O;
Problema de catálogo;
Cluster aberto indevidamente;
Compartilhamento mal definido;
AIX desatualizado;
Registro gravado com layout incompatível;
Programa que fez REWRITE de forma incorreta;
Erro de chave;
Erro de concorrência;
Falha após abend;
Estrutura realmente danificada.
A frase “VSAM corrompeu” é frequentemente o equivalente técnico de “alguém mexeu aí”.
E Melvin Udall não aceitaria “alguém” como nome de responsável.
14. Reorganização: o famoso REORG que não é um botão mágico
Você escreveu “rerog”, provavelmente referindo-se a REORG — reorganização.
No VSAM, geralmente não há um único comando universal chamado simplesmente REORG, como existe em outros contextos, por exemplo no Db2. A reorganização de um VSAM costuma ser construída por etapas.
O processo clássico é:
1. Descarregar os dados com REPRO
2. Excluir ou renomear o cluster antigo
3. Criar novamente o cluster com DEFINE
4. Recarregar dados ordenados com REPRO
5. Reconstruir AIX com BLDINDEX
6. Validar e liberar o arquivo
Limpeza de estrutura após processo de recuperação.
Mas reorganizar não é penitência semanal. Se o sistema sempre volta a fragmentar rapidamente, investigue o padrão de inserção, tamanho do CI, chave, espaço livre, volume, concorrência e lógica de carga.
Não adianta trocar o tapete se a máquina continua derramando óleo.
15. ALTER, SET e os pequenos comandos que salvam jobs repetíveis
O ALTER permite modificar alguns atributos catalogados, como renomear objetos em contextos permitidos.
Exemplo conceitual:
ALTER BELLACOSA.COBOL.CLIENTES.KSDS -
NEWNAME(BELLACOSA.COBOL.CLIENTES.KSDS.OLD)
Mas não tente usar ALTER para transformar qualquer atributo estrutural que você decidiu mudar numa terça-feira. Chave, posição da chave e aspectos fundamentais da organização normalmente exigem recriação controlada.
IDCAMS também permite alguma lógica de controle com IF, THEN, ELSE, DO, END e SET.
Por exemplo, em um ambiente de testes, você pode desejar apagar um arquivo e considerar aceitável que ele já não exista:
DELETE BELLACOSA.COBOL.CLIENTES.KSDS CLUSTER
IF LASTCC = 8 THEN -
SET MAXCC = 0
Isso não significa “ignore todos os erros”. Significa tratar conscientemente uma condição esperada.
Leia os retornos com maturidade:
RC
Interpretação inicial
0
Operação concluída
4
Aviso ou condição menor
8
Erro relevante; leia as mensagens
12
Erro sério
16
Falha grave
A maior armadilha do iniciante é olhar somente o MAXCC.
Um RC=0 pode significar que o IDCAMS executou perfeitamente uma instrução que você escreveu errada para o objetivo de negócio.
Um RC=8 pode ser esperado em um DELETE de um dataset inexistente em teste.
O mainframe não premia quem decora números. Ele premia quem lê contexto.
16. Curiosidades escondidas no catálogo
Curiosidade número um: o VSAM não se orienta apenas pelo nome digitado no JCL. Ele depende do catálogo para saber o que aquele nome representa, onde está e quais são seus atributos.
Curiosidade número dois: um KSDS não é “um arquivo ordenado” no sentido ingênuo. É uma estrutura que mantém registros, chaves, índices, intervalos e regras de expansão.
Curiosidade número três: o AIX não precisa carregar uma cópia completa do registro base. Ele funciona como uma rota alternativa de acesso.
Curiosidade número quatro: muitos problemas atribuídos ao COBOL aparecem, na verdade, na fronteira entre definição IDCAMS, layout do registro, política de acesso e operação.
Curiosidade número cinco: a chave do VSAM não é necessariamente a chave de negócio mais “bonita”. Ela é uma decisão arquitetural. CPF pode funcionar para busca individual; data de movimento pode servir para lote; uma chave composta pode representar agência + conta + dígito. O importante é entender o padrão de acesso que o sistema precisa atender.
17. O mapa mental definitivo do jovem programador COBOL
Quando você olha um VSAM, pense nesta sequência:
COBOL
↓
DDNAME / JCL
↓
Cluster VSAM
├── DATA
├── INDEX
├── CI
└── CA
↓
Catálogo
↓
Disco / Storage
Se houver pesquisa alternativa:
Aplicação
↓
PATH
↓
Alternate Index
↓
Cluster Base
↓
Registro
E se houver incidente:
Mensagens no joblog
↓
SYSPRINT do IDCAMS
↓
LISTCAT
↓
VERIFY ou EXAMINE, se aplicável
↓
Backup / REPRO / EXPORT / recuperação
Esse mapa evita a visão limitada de que “VSAM é uma cláusula no SELECT”.
Não é.
VSAM é uma estrutura de dados, uma decisão de armazenamento, um conjunto de controles operacionais e, muitas vezes, uma cápsula do tempo contendo décadas de regras de negócio.
Epílogo — Melvin Udall fecha o job
No fim do dia, Melvin Udall não ficaria impressionado porque você soube escrever:
DEFINE CLUSTER
Ele perguntaria:
Você sabe onde começa sua chave?
Conferiu RECORDSIZE contra o copybook?
Sua carga está ordenada?
Sabe se existe AIX?
Reconstruiu o índice após a reorganização?
Leu o SYSPRINT?
Testou o backup?
Sabe o que fará se o arquivo estiver aberto pelo CICS?
Tem certeza absoluta de que esse DELETE aponta para teste?
E, se você respondesse “acho que sim”, ele provavelmente encerraria a conversa.
Porque em VSAM, como em produção, “acho” é uma palavra perigosa.
A boa notícia é que ninguém precisa nascer sabendo CI, CA, AIX, PATH, REPRO, VERIFY e EXAMINE. Você aprende uma camada por vez. Primeiro cria. Depois carrega. Depois consulta. Depois copia. Depois investiga. Depois entende por que os veteranos ficam muito quietos quando alguém menciona PURGE.
O jovem programador COBOL evolui quando deixa de apenas abrir e fechar arquivos.
Ele evolui quando percebe que, atrás de cada READ, existe uma cidade inteira trabalhando para que o registro correto apareça no instante correto.
E, nesse dia, até Melvin Udall talvez permita um café ao seu lado.
Bellacosa Mainframe apresenta o jenkins para mainframers
☕ Um Café no Bellacosa Mainframe
Jenkins: O JES2 da Era DevOps que Todo Padawan COBOL Precisa Entender
"Se você já submeteu um JOB no JES2 esperando que tudo desse certo, então já conhece metade da filosofia do Jenkins. A diferença é que, no mundo moderno, quem dispara os jobs não é mais apenas um operador. É um robô extremamente paciente que nunca esquece um passo da esteira."
Existe uma pergunta que praticamente todo programador COBOL faz quando começa a conversar com equipes DevOps:
"Mas afinal... o que exatamente é esse tal de Jenkins?"
A resposta mais simples seria:
Jenkins é um servidor de automação.
Mas essa resposta é tão incompleta quanto dizer que o JES2 "serve apenas para executar jobs".
Na prática, Jenkins é muito mais do que isso.
Para quem vem do universo IBM Z, entender Jenkins fica extremamente fácil quando fazemos as analogias corretas.
Hoje vamos tomar mais um café e descobrir que talvez você já trabalhe com algo muito parecido há décadas...
Antes de existir DevOps...
Durante muito tempo o desenvolvimento Mainframe seguia uma sequência bastante conhecida.
O programador fazia alterações.
Compilava.
Testava.
Gerava Load Module.
Alguém promovia.
Outro aprovava.
Outro copiava bibliotecas.
Outro atualizava o pacote.
Outro executava testes.
Outro validava produção.
Era um processo enorme.
Muito humano.
Muito sujeito a erros.
E principalmente...
Muito lento.
Foi justamente daí que nasceu o conceito de automação de pipelines.
Imagine um operador que nunca dorme
Imagine existir um operador que:
nunca esquece um passo
nunca pula uma etapa
nunca executa fora de ordem
nunca chega atrasado
trabalha 24 horas
registra tudo
avisa quando algo falha
envia e-mails
chama APIs
dispara testes
gera documentação
cria containers
publica versões
Esse operador existe.
Seu nome é Jenkins.
A analogia perfeita para um coboleiro
Pense no seguinte fluxo clássico.
Editar COBOL
↓
Compilar
↓
Link Edit
↓
Executar Teste
↓
Validar RC
↓
Gerar pacote
↓
Mover Load
↓
Atualizar ambiente
↓
Notificar equipe
Agora imagine alguém executando tudo isso automaticamente.
Isso é Jenkins.
O Jenkins é um grande Scheduler?
Sim.
Mas com superpoderes.
Ele lembra um pouco:
JES2
Control-M
CA-7
ESP
IZWS
OPC
TWS
Só que em vez de apenas disparar JOBs...
Ele coordena toda a cadeia de desenvolvimento.
O pipeline é o novo JCL
Para quem programa COBOL existe uma analogia maravilhosa.
Uma empresa pode executar milhares de pipelines por dia.
Algumas executam dezenas por minuto.
Há pipelines que duram:
20 segundos.
Outros:
8 horas.
Tudo depende da aplicação.
Curiosidade Mainframe
Muitas empresas possuem aplicações COBOL com mais de:
40 milhões de linhas.
Sem automação seria impossível manter tudo isso.
Curiosidade interessante
Um COPYBOOK alterado pode obrigar centenas de programas a recompilar.
É justamente aí que o DBB faz enorme diferença.
Curiosidade divertida
Muitos programadores COBOL nunca abriram a interface do Jenkins.
Eles apenas fazem:
git push
E alguns minutos depois...
Recebem um e-mail dizendo:
✔ Build Success
O lado psicológico
Uma boa esteira reduz ansiedade.
Você não fica imaginando:
"Será que esqueceram de promover?"
"Será que copiaram o Load?"
"Será que executaram o Bind?"
O Jenkins lembra.
Sempre.
Fraquezas do Jenkins
Embora seja extremamente poderoso, o Jenkins também apresenta desafios que um programador Mainframe precisa conhecer.
A primeira fraqueza é a manutenção. Quanto mais pipelines personalizados uma empresa cria, maior se torna o esforço para mantê-los. Um Jenkins mal administrado acaba se transformando em uma coleção de scripts difíceis de entender, semelhante àquela PROC antiga que apenas um analista aposentado sabia alterar.
Outra limitação é a dependência de plugins. O ecossistema do Jenkins é gigantesco, mas isso significa que plugins podem ficar desatualizados, incompatíveis entre si ou apresentar vulnerabilidades de segurança. É fundamental manter uma política de atualização e testes antes de promover novas versões para ambientes produtivos.
Também existe a questão da escalabilidade. Um único servidor Jenkins executando centenas de builds simultâneos pode tornar-se um gargalo. Por isso, grandes organizações costumam distribuir a carga utilizando Agents, que funcionam como "executores remotos" capazes de processar builds em paralelo.
Vantagens para quem trabalha com IBM Z
Para o universo Mainframe, o Jenkins traz benefícios que vão muito além da simples automação:
Elimina tarefas repetitivas.
Reduz erros humanos durante promoções.
Padroniza o processo de compilação.
Garante que todos utilizem as mesmas ferramentas.
Facilita auditorias e conformidade.
Integra facilmente Git, Zowe, DBB, SonarQube e plataformas de colaboração como Teams e Slack.
Produz histórico completo de todas as alterações realizadas.
Isso significa menos tempo resolvendo problemas operacionais e mais tempo escrevendo código COBOL de qualidade.
O futuro do Padawan COBOL
Há alguns anos era comum imaginar que um programador Mainframe viveria apenas dentro do ISPF.
Hoje a realidade é diferente.
O profissional moderno alterna naturalmente entre:
VS Code
Git
Jenkins
Docker
Zowe CLI
APIs REST
Enterprise COBOL
JCL
CICS
DB2
z/OS
Ele continua sendo um especialista em Mainframe, mas agora também compreende como sua aplicação percorre toda a esteira DevOps até chegar à produção.
Conclusão
Existe uma frase bastante conhecida no mundo DevOps:
"Se um processo precisa ser executado duas vezes, ele provavelmente deveria ser automatizado."
No universo IBM Z essa ideia faz ainda mais sentido. Sistemas críticos processam milhões de transações diariamente e não podem depender da memória de uma pessoa para lembrar cada etapa de compilação, teste e implantação.
O Jenkins não substitui o conhecimento do programador COBOL. Ele não escreve regras de negócio, não resolve um S0C7 e não otimiza um SQL ruim. O que ele faz é garantir que todo o caminho entre o commit e a produção seja repetível, rastreável e confiável.
Para o Padawan COBOL, aprender Jenkins é como aprender JCL décadas atrás: no começo parece apenas mais uma ferramenta, mas logo se percebe que ela se torna parte do trabalho diário. E quanto antes você entender como Git, Docker, Zowe, DBB e Jenkins trabalham em conjunto, mais preparado estará para atuar nos ambientes IBM Z modernos.
No fim das contas, o Jenkins é o JES2 da era DevOps: recebe solicitações, organiza a execução, controla dependências, registra tudo o que aconteceu e garante que cada etapa aconteça na ordem correta. A diferença é que, agora, a esteira começa muito antes do JOB chegar ao z/OS e termina muito depois da compilação do COBOL, conectando desenvolvimento, testes, segurança, observabilidade e entrega contínua em um único fluxo automatizado.
E esse é talvez o maior easter egg de todos: muitos dos conceitos considerados "modernos" no DevOps sempre existiram no Mainframe. Apenas ganharam novas ferramentas, novos nomes e uma interface muito mais amigável. O espírito continua o mesmo: processos confiáveis, automação inteligente e qualidade acima de tudo.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
