✨ 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 Goblin Slayer Parte IV
☕ Um Café no Bellacosa Mainframe
Goblin Slayer — Parte IV O Arquiteto Invisível de Goblin Slayer
Quando um Programador COBOL Descobre que Alguns dos Melhores Arquitetos Também Preferem Permanecer Atrás do Terminal
"Existem autores que aparecem mais do que suas obras. Existem outros que desaparecem completamente... para que apenas a história continue falando por eles."
Quem é Kumo Kagyu?
Essa talvez seja uma das perguntas mais curiosas de toda a indústria dos mangás e light novels.
Quem procura informações sobre Eiichiro Oda, encontra centenas de entrevistas.
Quem pesquisa Akira Toriyama, encontra documentários inteiros.
Quem procura Naoki Urasawa, descobre palestras, eventos e inúmeras fotografias.
Mas quando digitamos Kumo Kagyu...
O resultado é quase um vazio.
E curiosamente...
Esse vazio faz todo sentido.
O homem que preferiu desaparecer
Vivemos uma época onde autores transformaram-se em celebridades.
Existem redes sociais.
Lives.
Entrevistas.
Conferências.
Eventos.
Streams.
Podcasts.
Marketing pessoal.
Kumo Kagyu seguiu exatamente o caminho contrário.
Ele quase nunca aparece.
Pouquíssimas fotografias são conhecidas.
Entrevistas são raras.
Sua vida pessoal permanece praticamente desconhecida.
Para alguns isso parece estranho.
Para quem trabalha com tecnologia...
Nem tanto.
O velho programador do CPD
Imagine um grande banco.
Existe um profissional que conhece absolutamente tudo.
Ele sabe onde está cada JCL.
Conhece cada COPYBOOK.
Cada VSAM.
Cada catálogo.
Cada rotina.
Todo mundo o procura quando algo quebra.
Mas quase ninguém sabe seu aniversário.
Nem onde mora.
Nem sequer existe fotografia dele no mural da empresa.
Porque algumas pessoas preferem deixar que o trabalho fale por elas.
Kumo Kagyu parece pertencer exatamente a essa categoria.
Um pseudônimo cheio de significado
"Kumo Kagyu" não é seu nome civil.
É um nome artístico.
Como acontece com inúmeros autores japoneses.
"Kumo" (蜘蛛) significa aranha.
"Kagyū" (蝸牛) significa caracol.
Pense nessa combinação.
Uma aranha.
Um caracol.
Dois animais discretos.
Silenciosos.
Paciente.
Nenhum deles vence pela força.
Ambos vencem pela estratégia.
Parece familiar?
Goblin Slayer também.
A geração dos RPGs
Embora sua biografia permaneça discreta, algumas entrevistas permitem reconstruir parte de sua formação cultural.
Kumo Kagyu pertence à geração japonesa que cresceu durante a explosão dos RPGs de mesa nos anos 1980 e 1990.
Enquanto muitas crianças brincavam com videogames...
Outra pequena parcela passava horas reunida em mesas.
Rolando dados.
Criando campanhas.
Inventando personagens.
Discutindo regras.
Improvisando histórias.
Ali nasceu uma maneira completamente diferente de enxergar fantasia.
Antes do videogame...
Hoje muitos jovens imaginam que RPG nasceu no computador.
Na verdade...
O computador veio muito depois.
Durante décadas bastavam:
papel
lápis
borracha
dados
imaginação
Nada mais.
Todo o resto acontecia dentro da cabeça dos jogadores.
A influência de Dungeons & Dragons
É impossível compreender Goblin Slayer sem compreender Dungeons & Dragons, lançado em 1974.
Praticamente toda a estrutura da obra nasce dali.
As classes.
As guildas.
As quests.
Os níveis.
As masmorras.
Os monstros.
As recompensas.
Até mesmo a ideia de que os deuses "lançam dados" é uma homenagem direta ao Mestre de Jogo.
Sword World RPG
Existe outra influência gigantesca.
Talvez até maior para leitores japoneses.
Sword World RPG, lançado em 1989.
Enquanto D&D dominava o Ocidente...
Sword World tornou-se um fenômeno no Japão.
Muitas aventuras lembram diretamente esse sistema.
O estilo das cidades.
Os aventureiros.
As guildas.
As tavernas.
As caravanas.
Tudo respira RPG clássico japonês.
A influência da Sword & Sorcery
Outra característica marcante.
Kumo Kagyu demonstra enorme admiração pela literatura de Sword & Sorcery.
Especialmente por autores como:
Robert E. Howard
Michael Moorcock
Fritz Leiber
Nesses mundos...
O protagonista não salva necessariamente o planeta.
Ele tenta sobreviver.
Essa diferença muda completamente a narrativa.
Conan está em toda parte
Muitos enxergam apenas Berserk.
Mas Conan talvez esteja ainda mais presente.
Observe Goblin Slayer.
Equipamentos simples.
Pouca magia.
Violência direta.
Ambientes hostis.
Sobrevivência constante.
Missões pequenas.
Tudo isso lembra muito mais Conan do que a fantasia moderna.
O escritor que joga RPG enquanto escreve
Existe uma frase frequentemente atribuída a Kumo Kagyu.
Ele afirma que escreve imaginando uma campanha acontecendo diante dele.
Isso explica vários detalhes curiosos.
Por exemplo.
Por que Priestess erra tanto no início?
Porque jogadores iniciantes também erram.
Por que Goblin Slayer prepara tudo?
Porque veteranos fazem exatamente isso.
Por que algumas batalhas parecem improvisadas?
Porque campanhas de RPG raramente seguem exatamente o plano inicial.
A construção dos personagens
Outro detalhe brilhante.
Quase ninguém possui nome.
Isso intriga muitos espectadores.
Na realidade...
É exatamente como funciona em inúmeras mesas de RPG.
O Mestre não pergunta:
"Qual o nome do personagem?"
Pergunta:
"O Guerreiro faz o quê?"
"A Sacerdotisa lança qual magia?"
"O Anão usa qual habilidade?"
As classes tornam-se a identidade.
Goblin Slayer preserva essa tradição.
O nascimento da obra
Tudo começou como uma Web Novel, por volta de 2013, publicada em plataformas digitais voltadas para escritores independentes.
Na época, esse era um ambiente extremamente competitivo.
Centenas de autores publicavam histórias diariamente.
Pouquíssimos conseguiam chamar atenção.
Goblin Slayer foi um deles.
2016 — O primeiro grande salto
Em 15 de fevereiro de 2016, a editora SB Creative, por meio do selo GA Bunko, publica oficialmente o primeiro volume da Light Novel.
As ilustrações ficam a cargo de Noboru Kannatsuki.
Essa parceria torna-se um enorme sucesso.
O texto de Kumo Kagyu e a arte de Kannatsuki passam a ser praticamente inseparáveis.
O mangá
Poucos meses depois...
25 de maio de 2016.
Começa a adaptação para mangá desenhada por Kōsuke Kurose.
Era um desafio enorme.
Como transformar em imagens uma obra tão pesada?
O resultado surpreendeu.
O mangá conquistou rapidamente novos leitores.
O anime
Em 7 de outubro de 2018, chega o anime produzido pelo estúdio White Fox.
Foi nesse momento que Goblin Slayer deixou de ser uma obra conhecida apenas entre leitores de Light Novel.
Passou a ser um fenômeno mundial.
Um sucesso construído lentamente
Curiosamente...
Goblin Slayer nunca foi uma explosão instantânea.
Seu crescimento lembra muito mais um projeto de software corporativo.
Primeiro conquista um pequeno grupo.
Depois outro.
Depois outro.
Até que, anos mais tarde...
Todos percebem que ele está em toda parte.
As outras obras de Kumo Kagyu
Embora Goblin Slayer seja sua criação mais famosa, Kumo Kagyu também trabalhou em outros projetos relacionados ao universo da fantasia.
Entre eles:
Goblin Slayer: Year One (prelúdio oficial)
Goblin Slayer Side Story II: Dai Katana
Participação e supervisão de diversos materiais derivados da franquia.
Colaboração em suplementos e conteúdos ligados ao universo expandido.
Até hoje, porém, sua carreira permanece profundamente associada a Goblin Slayer, que continua sendo sua obra de maior alcance e reconhecimento internacional.
O autor que prefere o mundo à fama
Existe algo admirável nisso.
Em vez de transformar sua personalidade em produto...
Kumo Kagyu deixa que o universo fale.
Os personagens ocupam o centro.
Não o autor.
Isso lembra muito alguns grandes escritores do século XX.
A obra vem primeiro.
O ego fica por último.
O que um programador COBOL aprende com Kumo Kagyu?
Mais do que parece.
Porque escrever Goblin Slayer exigiu exatamente o mesmo tipo de disciplina necessária para manter um sistema crítico.
Conhecer profundamente o domínio.
Respeitar regras.
Construir consistência.
Pensar nas consequências.
Evitar soluções mágicas.
Planejar antes de agir.
Tudo isso faz parte tanto de uma boa campanha de RPG quanto de um bom sistema corporativo.
A filosofia do arquiteto invisível
Talvez a maior contribuição de Kumo Kagyu não tenha sido criar um personagem.
Foi recuperar uma ideia que a fantasia vinha esquecendo.
Heróis não precisam ser escolhidos pelos deuses.
Não precisam carregar espadas lendárias.
Não precisam derrotar entidades cósmicas.
Às vezes basta alguém levantar cedo.
Vestir a armadura.
Entrar novamente na caverna.
E fazer, pela milésima vez, o trabalho que ninguém quer fazer.
Conclusão — O Homem Atrás do Capacete... e o Homem Atrás da Máquina
Existe uma ironia elegante na história de Kumo Kagyu.
Ele criou um protagonista que quase nunca mostra o rosto.
Ao mesmo tempo, tornou-se um autor que também prefere permanecer fora dos holofotes.
É como se criador e criatura compartilhassem a mesma filosofia.
O importante nunca foi quem está por trás da armadura.
O importante é que alguém continue protegendo a aldeia.
No universo do Bellacosa Mainframe, essa metáfora soa familiar. Quantos profissionais dedicaram décadas a manter sistemas que movimentam bancos, hospitais, governos e companhias aéreas sem jamais aparecer em uma reportagem? Quantos sysprogs, operadores e programadores COBOL passaram noites inteiras garantindo que tudo funcionasse para que, na manhã seguinte, ninguém percebesse que havia existido um problema?
Kumo Kagyu parece compreender profundamente esse tipo de heroísmo silencioso.
Talvez por isso Goblin Slayer tenha conquistado tantos leitores maduros.
Porque, no fim das contas, não é apenas a história de um homem que caça goblins.
É a história de todos aqueles que descobriram que a maior forma de coragem não está em fazer o impossível uma única vez.
Está em continuar fazendo o necessário.
Todos os dias.
Sem esperar aplausos.
☕Um Café no Bellacosa Mainframe
ARQUIVOS DA GUILDA • CLASSIFICAÇÃO: DARK FANTASY
Goblin Slayer sem Mistérios
O Guia Definitivo da Série Completa
Uma jornada por cronologia, psicologia, biologia, estratégia,
engenharia militar, referências culturais, simbolismos e os
segredos escondidos de Goblin Slayer.
“Quando um Programador COBOL Descobre que Grandes Obras Também
Precisam de um Mapa para Não se Perder na Dungeon.”
Goblin Slayer sem Mistérios é uma coleção especial
do Bellacosa Mainframe dedicada à análise profunda da obra criada por
Kumo Kagyu. Cada capítulo investiga uma camada diferente da franquia,
relacionando fantasia sombria, RPG de mesa, estratégia, trauma,
sobrevivência, engenharia militar e arquitetura de sistemas.
A coleção foi organizada em ordem cronológica para facilitar a leitura.
Você pode começar pela Parte I, seguir capítulo após capítulo ou utilizar
os filtros para selecionar assuntos como psicologia, goblins, táticas,
história da franquia e cultura otaku.
Todos os títulos abaixo são links HTML reais e permanecem acessíveis
mesmo quando o JavaScript estiver desativado. Isso facilita a navegação
dos leitores e a descoberta das páginas por mecanismos de busca.
⌕
Progresso da campanha0 de 14 missões visitadas
14 capítulos encontrados
I
Introdução
Goblin Slayer sem Mistérios — Parte I
O ponto de entrada da campanha. Uma análise sobre o herói invisível
que não salva o mundo em uma única batalha, mas impede silenciosamente
que ele desmorone todos os dias.
O verdadeiro poder não está na espada, mas na constância de levantar,
preparar os equipamentos e executar diariamente o trabalho que quase
ninguém deseja assumir.
Uma reflexão sobre profissionais que projetam soluções, previnem
desastres e permanecem atrás do terminal enquanto o restante do
mundo apenas percebe que tudo continua funcionando.
Parte V — A Evolução Cronológica Completa da Franquia
Da publicação original às light novels, mangás, adaptações,
spin-offs, filme e temporadas do anime: a evolução de uma história
que cresceu release após release.
Anatomia, comportamento, adaptação, hierarquia e ecologia dos
goblins analisados como uma espécie invasora capaz de explorar
brechas e evoluir rapidamente.
Parte VII — As Referências Escondidas de Goblin Slayer
Conan, Berserk, Tolkien, Dungeons & Dragons, Sword World RPG,
literatura fantástica, mitologia e cultura pop escondidos entre
as linhas da obra de Kumo Kagyu.
Parte VIII — A Psicologia Profunda de Goblin Slayer
Trauma, hipervigilância, isolamento, necessidade de controle,
resiliência e reconstrução emocional por meio das relações que
lentamente devolvem humanidade ao protagonista.
Uma análise sobre informação, iniciativa, especialização,
probabilidades, redundância e a capacidade de pensar diversos
movimentos à frente do adversário.
Cem detalhes sobre personagens, mundo, goblins, equipamentos,
narrativa, simbolismos, RPG, produção, psicologia e estratégia
que podem passar despercebidos até pelos fãs.
O mapa da campanha: introdução, sequência recomendada, resumo dos
capítulos e orientação para explorar todas as camadas da coleção
sem se perder na dungeon.
Por Que Goblin Slayer É uma das Melhores Obras de Dark Fantasy
A conclusão da jornada, reunindo cronologia, psicologia, estratégia,
engenharia militar, simbolismos, referências culturais, construção
de mundo e impacto na cultura otaku.
A Composição do Exército Goblin em The Fate of an Adventurer
Rei Goblin, estado-maior, Champions, Shamans, arqueiros, infantaria,
Riders, logística e cadeia de comando analisados como componentes
de uma força militar organizada.
Comece pelas três primeiras partes para compreender a proposta da
série. Depois visite o Arquiteto Invisível, conheça a evolução da
franquia e aprofunde-se em biologia, referências, psicologia,
engenharia militar e estratégia.
01 Fundamentos do herói invisível
02 História e evolução da franquia
03 Biologia e organização dos goblins
04 Psicologia e simbolismos
05 Engenharia militar e estratégia
06 Segredos, guia completo e síntese final
LEITOR DA GUILDA
Visualização do capítulo
⚠
Caso o Blogspot impeça a exibição dentro do iframe, utilize o botão
Abrir artigo em nova aba.
💖😂 Como o Humor Romântico Mudou do Anos 90 Até Hoje
Do exagero clássico ao nonsense moderno: a evolução da comédia nos animes de romance
Se você acha que shoujos e comédias românticas sempre foram fofos e previsíveis, prepare-se: o humor romântico mudou MUITO desde os anos 90. Vamos explorar essa evolução e entender por que rimos de forma diferente hoje.
🕹️ 1) Anos 90: exagero físico e timing teatral
Exemplos:Sailor Moon, Ranma ½, Maison Ikkoku
Características:
Quedas, tropeços, objetos voando
Blush exagerado e olhares de choque
Beijos acidentais como punchline clássica
Por que funcionava: O humor era visual e universal, fácil de entender mesmo sem contexto cultural.
Resumindo: se tropeçou, beijou ou explodiu de vergonha → era piada.
💌 2) Anos 2000: timing verbal e situações constrangedoras
Exemplos:Lovely★Complex, Ouran High School Host Club
Características:
Mal-entendidos complexos
Diálogos rápidos com sarcasmo e ironia
Rivais e amigos atrapalhando o romance
Mudança principal: O humor deixou de ser apenas físico → passou a depender do contexto e da personalidade dos personagens.
Piadas não só aconteciam com objetos voando… mas também com quem dizia o quê.
🌸 3) 2010–2015: metalinguagem e referências culturais
Exemplos:Nisekoi, Toradora!, Kaichou wa Maid-sama!
Características:
Paródias internas e autoironia
Personagens comentando clichês do próprio gênero
Mistura de drama + comédia, às vezes em um mesmo quadro
Impacto: Os fãs começaram a entender e rir das convenções do shoujo, não apenas das situações.
🎮 4) Hoje: nonsense, memes e humor global
Exemplos:Kaguya-sama: Love is War, Tonikawa, Rent-A-Girlfriend
Características:
Piadas absurdas e exageradas ao extremo
Referências de internet e cultura pop
Quebra constante de expectativa e de 4º muro
O que mudou: O humor romântico agora é meta e globalizado, feito para fãs que consomem anime online e memes simultaneamente.
Se antes o riso vinha do tropeço, hoje vem do absurdo planejado e da sátira consciente.
Personagens ganharam mais personalidade e timing cômico próprio
A interação entre fãs e mídia influencia diretamente a piada
O exagero continua sendo rei, mas agora com camadas de inteligência e referência
🎤 Conclusão do narrador
O humor romântico nos animes não apenas acompanhou o tempo, ele se adaptou ao público.
Do tropeço clássico à piada meta, a fórmula é clara: quanto mais exagero, mais identificação, mais risadas.
Anos 90 ou 2025, rir do amor continua sendo a parte mais divertida da experiência otaku 💖😂
Bellacosa Mainframe e os primeiros passos para um programador cobol
☕ Um Café no Bellacosa Mainframe
De Volta para o Mainframe — Quando o Dr. Brown Abriu o ISPF, Encontrou um Programa COBOL de 15 Anos e Descobriu que o Futuro Usava Jira
Ou: o jovem padawan achava que desenvolver COBOL era passar o dia digitando MOVE, mas bastaram 1,21 gigawatts, um job noturno e uma especificação ambígua para quase alterar o saldo de dois milhões de clientes
Prólogo — Estradas? Para onde vamos não precisamos de estradas, mas precisamos do JCL
Itatiba, 8h07 da manhã.
Igor, nosso jovem padawan COBOL, chegou para seu primeiro dia numa instituição financeira. Na mochila havia um caderno novo, três canetas, um curso de COBOL concluído com 98% de aproveitamento e a certeza de que passaria o dia escrevendo programas numa tela preta com letras verdes.
Ele imaginava uma sala escura.
Imaginava veteranos silenciosos digitando comandos secretos diante de terminais antigos.
Imaginava pilhas de manuais IBM, fitas magnéticas girando e um operador gritando:
— O banco de dados está entrando em colapso!
Quando abriu a porta, encontrou algo muito mais desconcertante: pessoas usando Teams, Jira, Confluence, planilhas, dashboards, Git, e-mail e uma cafeteira que aparentemente possuía prioridade maior que produção.
No centro da sala estava um homem de cabelos brancos, jaleco e olhos arregalados, tentando conectar um cabo amarelo à lateral de um terminal 3270.
— Grande Scott! — gritou o Dr. Emmett Brown. — Este computador não possui porta USB!
— Doutor, isso é um emulador TN3270 — explicou Bellacosa. — E tire esse cabo daí antes que o RACF registre uma tentativa de acesso intertemporal.
Marty McFly observou a tela.
— Doc, estamos em 1985?
— Não, Marty. Estamos no presente. Eles usam Scrum, Jira e Confluence, mas o sistema central executa COBOL.
Marty franziu a testa:
— Isso é possível?
Bellacosa serviu o café.
— No mainframe, garoto, duas coisas aparentemente contraditórias podem ser verdadeiras ao mesmo tempo. O código pode ter 15 anos e a tarefa pode ter chegado há cinco minutos pelo Jira.
Naquela manhã, Igor descobriria que o trabalho de um desenvolvedor COBOL não consiste apenas em escrever código.
Consiste em compreender o negócio, investigar o passado, proteger o presente e impedir que uma regra ambígua seja enviada para o futuro em escala industrial.
1. A sala escura que só existe no cinema
Existe uma caricatura bastante popular do desenvolvedor COBOL: um profissional envelhecido, isolado numa sala subterrânea e diante de uma tela verde, mantendo programas incompreensíveis criados quando a internet ainda usava fraldas.
A tela verde existe.
O ISPF continua sendo utilizado. O acesso por TN3270 continua presente em muitas empresas. Existem programas com 10, 20, 30 ou mais anos de existência.
Porém, ferramentas antigas não significam necessariamente práticas antigas.
Uma equipe COBOL moderna pode utilizar:
Scrum ou Kanban;
Jira para gerenciar tarefas;
Confluence para documentação;
Git para versionamento;
pipelines de integração e entrega;
revisão de código;
testes automatizados;
análise estática;
observabilidade;
APIs;
mensageria;
práticas DevOps;
IDEs como IBM Developer for z/OS;
Visual Studio Code com extensões para IBM Z.
O código pode executar no z/OS enquanto a equipe participa de uma reunião pelo Teams.
Um programa batch pode ler um arquivo sequencial durante a madrugada e depois disponibilizar seus resultados para uma API consumida por um aplicativo móvel.
O cliente toca numa interface criada ontem. A solicitação atravessa várias camadas modernas e termina num programa COBOL criado antes do nascimento de parte da equipe.
A experiência visual é nova. O compromisso financeiro continua no sistema central.
O primeiro ensinamento do Dr. Brown é, portanto:
Não confunda a idade da interface com a capacidade da plataforma.
Um sistema não se torna moderno apenas porque possui botões coloridos. Da mesma forma, não se torna obsoleto apenas porque utiliza uma tela preta.
Um microsserviço criado há seis meses pode ter arquitetura caótica, documentação inexistente e nenhuma observabilidade. Um programa COBOL criado há 20 anos pode ser estável, eficiente, bem monitorado e processar milhões de operações todos os dias.
A idade é uma informação. Não é um diagnóstico.
2. O dia começa olhando o passado recente
Antes de abrir o Jira, responder ao e-mail ou participar da reunião diária, muitos desenvolvedores verificam o que aconteceu durante a noite.
O Dr. Brown gostou imediatamente dessa ideia.
— Finalmente uma profissão que compreende a importância de analisar o passado!
Em ambientes financeiros, o sistema não encerra o expediente quando os funcionários deixam o escritório. Durante a madrugada, começa uma enorme movimentação batch.
Podem ser executados:
fechamento contábil;
cálculo de juros;
processamento de parcelas;
atualização de saldos;
consolidação de movimentos;
geração de extratos;
aplicação de tarifas;
conciliações;
processamento de cartões;
liquidação de operações;
recebimento e envio de arquivos;
backups;
reorganizações;
relatórios gerenciais e regulatórios.
Enquanto a cidade dorme, o mainframe trabalha.
Por isso, uma verificação rápida pode procurar:
jobs que terminaram com código de retorno inesperado;
ABENDs;
arquivos ausentes;
etapas não executadas;
registros rejeitados;
SQLCODEs negativos;
filas MQ acumuladas;
transações CICS com erro;
aumento anormal no tempo de execução;
inconsistências em totais de controle;
alertas abertos pela monitoração;
chamados criados pelo plantão.
Na maioria dos dias, nada grave aconteceu.
E essa é exatamente a finalidade da disciplina operacional: descobrir rapidamente quando o dia não é igual à maioria.
RC=0000 não é certificado de perfeição
Igor olhou o painel e comemorou:
— Todos os jobs terminaram com RC=0000. Está tudo certo!
O Dr. Brown levantou o dedo.
— Grande Scott! Você acaba de confundir “o programa terminou” com “o programa fez a coisa certa”.
Um retorno igual a zero geralmente indica que o processamento terminou sem uma falha técnica detectada. Isso não garante que a regra de negócio esteja correta.
Mas a especificação talvez determinasse que a tarifa fosse aplicada somente quando o saldo médio mensal fosse superior a 1.000, e não quando o saldo atual ultrapassasse esse valor.
A máquina executou exatamente o que recebeu.
O erro nasceu antes da execução: nasceu na interpretação da regra.
Essa é uma das verdades mais importantes para quem começa no mainframe:
O computador pode executar com perfeição uma decisão completamente errada.
Um S0C7 é barulhento. O job para, o monitoramento alerta e alguém investiga.
Um erro lógico pode ser silencioso. Ele continua processando milhares ou milhões de registros e termina educadamente com RC=0000.
O ABEND assusta. O erro silencioso sorri.
3. Plantão, recuperação e o ritual do job ressuscitado
Sistemas críticos costumam possuir uma escala de plantão para incidentes fora do horário comercial.
Quando algo falha, o profissional responsável precisa:
receber ou identificar o alerta;
medir o impacto;
consultar logs e procedimentos;
determinar a etapa afetada;
executar uma recuperação segura;
acionar especialistas quando necessário;
comunicar o andamento;
preservar evidências;
registrar o ocorrido.
Mas existe uma diferença importante entre recuperar o serviço e solucionar o problema.
Imagine que um job falhe toda terça-feira e alguém simplesmente o reinicie.
Isso pode manter o processamento funcionando, mas não constitui uma correção definitiva.
Reiniciar é recuperação.
Corrigir a causa é manutenção.
Impedir a recorrência é engenharia.
Se o mesmo job precisa ser ressuscitado semanalmente, a empresa não possui uma solução. Possui um ritual religioso documentado no Confluence.
E talvez nem esteja bem documentado.
Não abra o editor antes de entender o incidente
Um chamado pode dizer:
“O arquivo de pagamentos não foi processado.”
Igor imediatamente procuraria o programa COBOL responsável.
O Dr. Brown perguntaria primeiro:
O arquivo chegou?
Chegou no horário?
Chegou vazio?
O nome estava correto?
O dataset foi catalogado?
O job foi submetido?
A etapa anterior terminou?
Houve falha de autorização?
O programa começou a executar?
Existem registros parcialmente processados?
A retomada pode duplicar movimentos?
O sistema de origem enviou o arquivo correto?
A causa pode estar no programa. Mas também pode estar no JCL, no scheduler, na comunicação, no RACF, no sistema anterior ou no próprio arquivo.
Alterar código antes de reconstruir o acontecimento seria como o Dr. Brown desmontar o DeLorean porque Marty esqueceu de abastecer o gerador.
4. Scrum no mainframe: o futuro chegou e dura 15 minutos
Depois da verificação matinal, chega a reunião diária.
Ela costuma responder a três perguntas:
O que foi concluído?
O que será feito?
Existe algum bloqueio?
A reunião não precisa conter nenhuma peculiaridade COBOL.
Um desenvolvedor pode dizer:
Ontem concluí a análise de impacto do programa de tarifas. Hoje vou implementar o tratamento da nova modalidade. Estou bloqueado porque a especificação não informa como tratar contratos retroativos.
Esse bloqueio não é sinal de fraqueza.
Em sistemas financeiros, reconhecer uma ambiguidade é uma atitude de segurança. O perigoso seria inventar uma resposta e codificá-la.
Jira não é uma máquina de requisitos
O Jira ajuda a controlar tarefas, responsáveis, estados, prioridades e critérios de aceitação. Mas colocar uma frase vaga dentro dele não a transforma numa especificação completa.
Uma tarefa como:
“Alterar cálculo de juros para clientes especiais.”
ainda exige respostas:
Quem é cliente especial?
Onde essa classificação está armazenada?
Qual taxa deve ser aplicada?
A partir de qual data?
Vale para contratos existentes?
O cálculo é retroativo?
Como tratar estornos?
Qual regra de arredondamento?
Quais produtos estão incluídos?
Quais devem ser excluídos?
O Jira organiza a incerteza. Ele não a elimina.
Confluence não é o Livro do Destino
O Confluence pode armazenar:
regras de negócio;
diagramas;
contratos de interface;
decisões técnicas;
procedimentos operacionais;
evidências de testes;
planos de implantação;
instruções de recuperação.
Mas uma página desatualizada não se torna verdadeira porque possui um cabeçalho bonito e o logotipo da empresa.
A documentação precisa ser comparada com:
o código atual;
o comportamento de produção;
tickets antigos;
decisões funcionais;
regras regulatórias;
conhecimento dos usuários experientes.
A modernização não está no nome da ferramenta. Está na qualidade do conhecimento que passa por ela.
5. O verdadeiro trabalho começa antes do IDENTIFICATION DIVISION
O iniciante normalmente acredita que sua atividade principal será escrever COBOL.
A parte mais difícil, porém, é descobrir o que deve ser escrito.
A sintaxe básica é relativamente legível:
IF CLIENTE-ATIVO
PERFORM CALCULAR-TARIFA
ELSE
PERFORM REGISTRAR-ISENCAO
END-IF
O problema não está necessariamente no IF.
O problema é descobrir o significado de CLIENTE-ATIVO.
Uma conta bloqueada pertence a um cliente ativo?
Cliente falecido continua ativo até o encerramento formal?
Um contrato suspenso é ativo?
A condição é verificada na data atual ou na data de processamento?
Em reprocessamentos, utiliza-se o estado atual ou o estado histórico?
Uma conta sem movimentação há dois anos permanece ativa?
Quando uma expressão de negócio vira uma condição binária, o desenvolvedor precisa transformar uma realidade cheia de tons de cinza em uma decisão executável.
Essa transformação é o coração do trabalho.
6. A especificação simples que quase alterou o futuro
A área de produtos envia a seguinte regra:
“Clientes com saldo superior a R$ 10.000 receberão bonificação de 1%.”
O Dr. Brown pega um marcador e começa a escrever perguntas no quadro.
Qual saldo?
Pode ser:
saldo contábil;
saldo disponível;
saldo atual;
saldo médio;
saldo no encerramento do mês;
saldo sem considerar limite;
saldo consolidado entre contas.
“Superior” inclui exatamente R$ 10.000?
Tecnicamente, “superior” sugere:
IF WS-SALDO > 10000
Mas talvez a área de negócio tenha pretendido “a partir de R$ 10.000”:
IF WS-SALDO >= 10000
Um único caractere muda quem recebe o benefício.
O bônus incide sobre qual valor?
Sobre o saldo inteiro?
Ou somente sobre a parcela superior a R$ 10.000?
Quando o valor deve ser calculado?
diariamente;
no último dia útil;
no fechamento do mês;
no aniversário da conta;
durante a consulta;
quando o arquivo é processado.
Quem deve ser excluído?
contas bloqueadas;
inadimplentes;
funcionários;
contas judiciais;
produtos encerrados;
clientes com pendência documental.
O código pode ser pequeno. A regra não é.
Marty observa o quadro cheio de perguntas:
— Doc, nós precisamos voltar no tempo para perguntar o que eles queriam dizer?
— Não, Marty. Precisamos de critérios de aceitação.
7. Edge cases: onde Igor encontra o Biff Tannen
O caminho feliz é o cenário em que tudo acontece como esperado.
Uma transferência comum pode seguir:
receber a solicitação;
verificar o saldo;
verificar o limite;
debitar a origem;
creditar o destino;
confirmar a operação.
Mas sistemas reais não vivem apenas no caminho feliz.
Existem:
valores negativos;
valor igual ao limite;
contas bloqueadas;
conta de destino inexistente;
moedas diferentes;
transferências agendadas;
duas operações simultâneas;
timeout durante o processamento;
reenvio da mesma mensagem;
falha depois do débito;
feriado;
mudança de limite durante a operação;
conta conjunta;
reprocessamento de movimento antigo.
O edge case é o Biff Tannen da especificação: aparece quando todos acreditavam que a aventura estava resolvida e muda o destino da família inteira.
Uma regra bem descrita deve ser convertida em cenários testáveis:
DADO um cliente ativo
E um limite diário de R$ 5.000
E transferências anteriores no total de R$ 4.000
QUANDO solicitar uma nova transferência de R$ 1.000
ENTÃO a operação deverá ser permitida
QUANDO solicitar uma transferência de R$ 1.000,01
ENTÃO a operação deverá ser rejeitada
E nenhuma movimentação deverá ser gravada
Agora existe uma fronteira clara.
O desenvolvedor sabe o que implementar. O testador sabe o que validar. A área de negócio pode confirmar se a interpretação está correta.
8. Centavos viajam no tempo e voltam como duzentos mil reais
Um erro de R$ 0,01 parece pequeno.
Mas sistemas financeiros operam em escala.
Se a diferença ocorrer em 20 milhões de transações:
Além do valor, podem surgir:
divergências contábeis;
reclamações;
ressarcimentos;
auditoria;
retrabalho;
reprocessamento;
investigação regulatória;
dano reputacional.
Por isso, temas aparentemente modestos recebem atenção especial:
A fórmula pode ser válida para um produto e incorreta para outro que utiliza uma base de 365 dias.
O programa não produzirá obrigatoriamente um ABEND. Ele continuará executando a fórmula errada com excelente desempenho.
O mainframe não transforma uma regra incorreta em correta.
Ele apenas permite executá-la muito rapidamente.
9. Antes de alterar o programa, descubra em que linha do tempo ele vive
Depois de compreender a solicitação, o desenvolvedor precisa mapear o sistema.
Uma alteração pode envolver:
programas COBOL;
copybooks;
JCLs;
PROCs;
arquivos sequenciais;
VSAM;
tabelas Db2;
mapas BMS;
transações CICS;
filas MQ;
APIs;
rotinas chamadas;
schedulers;
programas anteriores e posteriores.
Uma tarefa chamada “alterar o cálculo” talvez afete um fluxo inteiro:
flowchart TD
A["Arquivo recebido"] --> B["Validação"]
B --> C["Cálculo COBOL"]
C --> D["Atualização Db2"]
C --> E["Arquivo contábil"]
D --> F["Consulta on-line"]
E --> G["Conciliação"]
Se o cálculo mudar no batch, mas a consulta on-line continuar utilizando a regra anterior, o cliente verá um valor enquanto a contabilidade registra outro.
Esse é o tipo de universo paralelo que nem o Dr. Brown deseja visitar.
O copybook compartilhado e o paradoxo dos quatro bytes
Se um consumidor continuar esperando o layout antigo, poderá interpretar quatro caracteres do nome como parte do identificador e ler o status na posição errada.
No mainframe, quatro bytes podem alterar o futuro.
10. Programas antigos não são fósseis; são cidades construídas em camadas
Igor recebe a tarefa de modificar um programa executado há 15 anos.
Ao abrir o fonte, encontra:
IF WS-TIPO-CONTA = 47
MOVE 'N' TO WS-COBRA-TARIFA
END-IF
Não há comentário explicando a razão.
Igor pensa:
— Isso parece desnecessário. Vou remover.
O Dr. Brown quase derruba o café.
— Nunca apague uma regra misteriosa antes de descobrir qual desastre ela impediu!
O código pode representar:
uma determinação judicial;
uma regra regulatória;
uma isenção contratual;
um produto incorporado de outro banco;
uma correção aplicada após um incidente;
compatibilidade com dados antigos;
uma condição temporária que se tornou permanente.
Código antigo é uma forma de documentação executável. Ele mostra o que o sistema faz, mas nem sempre explica por que faz.
Por outro lado, o fato de uma regra estar no código não prova que continua correta.
Podemos encontrar quatro situações:
Documentação
Código
Diagnóstico
correta
correto
cenário ideal
correta
incorreto
defeito de implementação
desatualizada
correto
falha de documentação
desatualizada
incorreto
investigação profunda
Existe ainda o cenário clássico do mainframe:
Ninguém sabe, mas sempre funcionou assim.
Nesse momento, é necessário consultar:
histórico de mudanças;
chamados antigos;
usuários experientes;
analistas de negócio;
evidências de testes;
relatórios;
legislação;
contratos;
sistemas consumidores.
O desenvolvedor torna-se arqueólogo corporativo — mas um arqueólogo que precisa manter a cidade funcionando enquanto escava.
11. TN3270: a tela verde não é o mainframe inteiro
O acesso por TN3270 continua sendo realidade em algumas equipes.
Por meio dele, o profissional pode acessar:
TSO;
ISPF;
editor;
SDSF;
datasets;
utilitários;
compiladores;
ferramentas de comparação;
produtos de gerenciamento de fontes.
Para o iniciante, a interface pode parecer hostil. Para o veterano, ela se torna memória muscular.
Comandos de linha, teclas de função, edição em bloco, pesquisa, repetição, exclusão e submissão de jobs permitem trabalhar com grande velocidade.
A existência de uma interface antiga não significa que a plataforma seja incapaz. Mas pode haver limitações para práticas contemporâneas:
navegação visual por dependências;
integração com Git;
análise durante a edição;
refatoração assistida;
depuração visual;
testes automatizados;
integração com pipelines;
onboarding;
produtividade de novos profissionais.
Por isso, algumas organizações adotam IBM Developer for z/OS, Visual Studio Code, Zowe Explorer e outras ferramentas.
Trocar o editor não basta
Modernizar a experiência exige também resolver:
gerenciamento de dependências;
copybooks;
build;
versionamento;
testes;
promoção entre ambientes;
segurança;
licenciamento;
treinamento;
governança.
Caso contrário, a empresa coloca um painel futurista no DeLorean, mas continua empurrando o carro porque esqueceu o combustível.
12. O JCL é a estrada por onde o programa chega aos dados
O programa COBOL contém a lógica. Mas, num processamento batch, o JCL informa como o programa será executado.
Um programa correto com JCL incorreto pode processar o arquivo errado.
Um JCL correto com programa incorreto pode executar perfeitamente uma regra errada.
Ambos precisam ser testados.
Também é necessário compreender o fluxo das etapas. Se o STEP02 depende do arquivo produzido pelo STEP01, não basta analisar cada etapa isoladamente.
O batch é uma viagem. Cada job, step, programa e dataset representa parte da rota.
13. COMMIT, ROLLBACK e a viagem que talvez já tenha acontecido
Suponha que uma transferência realize:
débito na conta de origem;
crédito na conta de destino;
gravação do histórico;
envio da confirmação.
Se o sistema falhar entre o débito e o crédito, o cliente pode perder dinheiro sem que o destino o receba.
Por isso, alterações relacionadas devem fazer parte de uma unidade de trabalho controlada.
Uma representação simplificada:
EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - :WS-VALOR
WHERE CONTA_ID = :WS-ORIGEM
END-EXEC
IF SQLCODE = 0
EXEC SQL
UPDATE CONTA
SET SALDO = SALDO + :WS-VALOR
WHERE CONTA_ID = :WS-DESTINO
END-EXEC
END-IF
IF SQLCODE = 0
EXEC SQL
COMMIT
END-EXEC
ELSE
EXEC SQL
ROLLBACK
END-EXEC
END-IF
Mas até esse exemplo abre novas perguntas:
O que acontece se a origem não tiver saldo?
E se o destino não existir?
As atualizações podem ocorrer simultaneamente?
O histórico faz parte da mesma unidade de trabalho?
E se o timeout acontecer depois do COMMIT, mas antes da resposta?
O cliente tentará novamente?
Como impedir débito duplicado?
A operação possui um identificador único?
Este último cenário é especialmente perigoso.
O cliente envia uma transferência. O sistema confirma o COMMIT, mas a resposta se perde. O aplicativo acredita que houve falha e reenvia a solicitação.
A primeira viagem aconteceu, mas Marty não recebeu a fotografia.
Sem idempotência ou controle de duplicidade, o débito poderá ocorrer duas vezes.
14. Compilar não significa testar
Quando a compilação termina sem erros, Igor comemora:
— Funcionou!
Bellacosa aponta para a tela:
— Compilou.
Existe uma diferença enorme.
A compilação demonstra que o código está formalmente aceitável para o compilador. Não demonstra que:
a regra está correta;
o arquivo certo foi utilizado;
os limites foram tratados;
o arredondamento está correto;
o programa suporta o volume esperado;
o processamento pode ser reiniciado;
o rollback funciona;
não haverá duplicidade;
outros sistemas continuam compatíveis.
Um teste adequado deve cobrir:
Caminho feliz
O cenário normal, com dados válidos e resultado esperado.
Limites
Valores exatamente iguais, imediatamente inferiores e imediatamente superiores às fronteiras.
Dados inválidos
Campos ausentes, caracteres onde deveriam existir números, datas impossíveis e códigos desconhecidos.
Falhas técnicas
Arquivo ausente, SQLCODE inesperado, indisponibilidade de serviço, fila bloqueada.
Reprocessamento
O que acontece se o mesmo arquivo, mensagem ou movimento for enviado novamente?
Volume
O processamento termina dentro da janela disponível?
Efeitos laterais
Além da saída principal, o sistema atualizou corretamente histórico, contabilidade, mensagens e auditoria?
O teste mais perigoso é aquele preparado apenas para confirmar a hipótese do próprio desenvolvedor.
15. A equipe precisa de aprendizes porque o conhecimento precisa viajar
Uma equipe saudável mistura:
profissionais juniores;
profissionais plenos;
profissionais seniores.
Isso não serve apenas para distribuir tarefas por dificuldade. Serve para transportar conhecimento entre gerações.
Existem pelo menos três tipos de conhecimento.
Conhecimento técnico
COBOL;
JCL;
CICS;
Db2;
VSAM;
MQ;
TSO/ISPF;
ferramentas de diagnóstico.
Conhecimento da aplicação
quais programas participam do fluxo;
quais dados são consumidos;
onde estão as dependências;
como testar;
como reiniciar;
quais resultados validar.
Conhecimento do negócio
por que a regra existe;
quais produtos são exceções;
quais áreas utilizam a informação;
quais controles são obrigatórios;
quais incidentes já aconteceram.
O conhecimento técnico pode ser adquirido em cursos e laboratórios.
O conhecimento da aplicação surge com experiência prática.
O conhecimento do negócio frequentemente vive na memória das pessoas.
Por isso, transferência de conhecimento não acontece entregando 500 fontes COBOL ao júnior e dizendo:
Estude. Depois conversamos.
Ela acontece por meio de:
programação em pares;
revisão de código;
análise conjunta;
participação em incidentes;
acompanhamento de implantações;
documentação;
rotação de responsabilidades;
explicação das decisões;
exercícios controlados.
O sênior não deve ser o único dono do capacitor de fluxo
Se apenas uma pessoa sabe recuperar determinado processo, a organização possui um risco.
Se toda madrugada alguém liga para “o Geraldo do fechamento”, porque somente ele conhece a sequência correta, Geraldo pode ser excelente — mas o sistema é frágil.
O profissional experiente aumenta seu valor quando transforma conhecimento pessoal em capacidade coletiva.
Um verdadeiro sênior não ensina apenas sintaxe. Ensina consequências.
O júnior pergunta:
— Como faço um READ?
O sênior acrescenta:
— O que acontecerá se o arquivo estiver vazio? Você verificou o FILE STATUS? O programa pode ser reiniciado depois de ler metade dos registros? Como evitar duplicidade?
O júnior vê uma instrução.
O sênior vê a madrugada que essa instrução pode produzir.
16. Passo a passo do jovem padawan COBOL
Ao receber uma nova tarefa, Igor deveria seguir este roteiro.
Passo 1 — Leia tudo antes de editar
Não abra imediatamente o programa. Leia a descrição, os critérios de aceitação e os documentos relacionados.
Passo 2 — Marque os termos ambíguos
Palavras perigosas incluem:
ajustar;
corrigir;
excluir;
cancelar;
automaticamente;
retroativo;
cliente ativo;
apenas;
normalmente.
“É apenas uma pequena alteração” costuma ser o trovão que atinge a torre do relógio.
Passo 3 — Converta frases em exemplos
Se a regra diz “acima do limite”, escreva casos com valor abaixo, igual e acima.
Passo 4 — Descubra onde a regra está implementada
Procure programas, copybooks, tabelas, arquivos, transações e consumidores.
Passo 5 — Faça a análise de impacto
Pergunte o que lê, chama, grava ou depende do componente alterado.
Passo 6 — Entenda o comportamento atual
Antes de mudar, consiga explicar o que o programa faz hoje.
Passo 7 — Investigue trechos misteriosos
Não remova exceções sem descobrir sua origem.
Passo 8 — Prepare os testes antes ou durante a implementação
Inclua caminho feliz, limites, erros, duplicidade e reprocessamento.
Passo 9 — Implemente a menor mudança segura
Evite misturar uma mudança funcional com uma grande refatoração desnecessária.
Passo 10 — Compile e leia as mensagens
Não ignore warnings apenas porque o módulo foi criado.
Passo 11 — Teste os resultados e os efeitos laterais
Confira arquivos, tabelas, históricos, totais e mensagens.
Passo 12 — Solicite revisão
Outro profissional pode perceber uma suposição que ficou invisível para quem escreveu.
Passo 13 — Atualize a documentação
Registre o que mudou, por que mudou e como validar.
Passo 14 — Planeje implantação e retorno
Defina como instalar, monitorar e desfazer a mudança com segurança.
Passo 15 — Verifique produção
Uma implantação não termina quando o componente chega à produção. Termina quando existem evidências de que o comportamento esperado ocorreu.
17. Curiosidades escondidas no DeLorean
Um programa antigo pode usar um compilador atual
A idade do código-fonte, do módulo executável e do hardware não precisa ser a mesma. Um programa criado décadas atrás pode ser recompilado com Enterprise COBOL moderno e executar num IBM Z recente.
COBOL não é automaticamente confiável
A plataforma oferece recursos poderosos de disponibilidade, processamento e recuperação. Entretanto, um programa mal projetado continua sendo um programa mal projetado.
A tela verde é uma interface, não uma arquitetura
Atrás do TN3270 podem existir APIs, pipelines, testes, mensageria, monitoração e integrações contemporâneas.
O conhecimento mais raro talvez não seja a linguagem
É possível ensinar COBOL. Mais difícil é encontrar quem compreenda simultaneamente o código, a aplicação, o fluxo operacional e as regras financeiras acumuladas durante anos.
“Legado” não significa inútil
Legado é aquilo que foi herdado. Pode ser valioso ou problemático. O diagnóstico depende de manutenção, risco, documentação, custo e capacidade de evolução.
Reescrever pode apagar regras invisíveis
Uma reescrita precisa reproduzir não apenas as funcionalidades documentadas, mas também comportamentos e exceções que foram acumulados no sistema atual.
O número 1,21 não serve apenas para gigawatts
Se Igor calcular juros de 1,21% utilizando uma escala decimal incorreta, o DeLorean talvez não viaje no tempo, mas a conciliação certamente desaparecerá no espaço.
18. Modernização não significa jogar o passado no lixo
Quando alguém diz “modernizar COBOL”, pode estar falando de muitas coisas diferentes:
Dimensão
Possível modernização
Editor
IDz ou Visual Studio Code
Fontes
Git e revisão por pull request
Build
automação com DBB ou pipelines
Testes
testes unitários e regressivos
Integração
APIs, eventos e mensageria
Operação
observabilidade e automação
Código
refatoração e modularização
Conhecimento
documentação e capacitação
Plataforma
atualização de compilador e middleware
Uma reescrita completa é apenas uma das possibilidades — e frequentemente a mais arriscada.
Antes de substituir um sistema, a organização precisa responder:
Onde estão todas as regras que ele executa?
Se parte da resposta for “no código” e outra parte for “na cabeça do Geraldo”, o projeto de reescrita já possui dois grandes riscos.
Modernização inteligente preserva o que funciona, reduz os pontos frágeis e aumenta a capacidade de mudança.
Não se trata de permanecer em 1985.
Trata-se de trazer para o futuro aquilo que continua gerando valor, sem transportar os mesmos problemas escondidos no porta-malas.
19. O trabalho consequencial
No final do dia, o desenvolvedor talvez tenha escrito apenas cinquenta linhas de COBOL.
Mas, antes disso, ele:
verificou produção;
participou do Scrum;
leu a especificação;
questionou uma ambiguidade;
consultou a área de negócio;
investigou programas antigos;
analisou dependências;
preparou dados;
executou testes;
revisou resultados;
ajudou um júnior;
atualizou a documentação;
acompanhou a implantação.
As cinquenta linhas são a parte visível.
O trabalho principal foi reduzir a incerteza.
Em sistemas financeiros, decisões do desenvolvedor podem determinar:
se um salário será creditado;
se um cartão será autorizado;
se uma apólice será renovada;
se os juros estarão corretos;
se uma transferência será duplicada;
se a contabilidade fechará;
se o relatório regulatório será consistente.
Na maioria dos dias, nada cinematográfico acontece.
Os jobs terminam. As transações respondem. Os totais fecham. O dinheiro chega ao destino correto.
Essa normalidade não significa que o trabalho seja pouco importante.
A normalidade é justamente o produto do trabalho.
Epílogo — Para onde vamos, ainda precisamos de logs
Eram 18h42 quando o Dr. Brown finalmente se levantou.
O programa havia sido alterado, revisado e testado. O caso do valor exatamente igual ao limite fora esclarecido. Os contratos retroativos receberam uma regra específica. A conciliação fechou.
Igor olhou orgulhoso para o fonte.
— Então é isso que faz um desenvolvedor COBOL?
Bellacosa respondeu:
— Isso é parte do que ele faz.
— Mas escrevemos tão pouco código!
O Dr. Brown apontou para a tela.
— Meu jovem, qualquer máquina pode executar instruções. O difícil é decidir quais instruções devem atravessar o tempo.
Marty entrou no DeLorean e perguntou:
— Doc, para onde vamos agora?
Brown verificou o relógio.
— Para amanhã, 8h07. Quero descobrir se o job terminou corretamente.
— Mas nós já testamos!
— Exatamente. Agora precisamos descobrir o que aconteceu com dados reais.
O capacitor de fluxo acendeu. O DeLorean acelerou pelo corredor e desapareceu num clarão, deixando duas marcas de pneu ao lado da cafeteira.
No monitor, uma mensagem apareceu:
JOB CALCBON ENDED - RC=0000
Igor sorriu.
Depois lembrou-se da primeira lição, abriu o relatório de conciliação e conferiu os totais.
Porque o desenvolvedor COBOL maduro sabe que RC=0000 significa apenas que a máquina terminou sua viagem.
Ainda cabe ao ser humano verificar se ela chegou ao futuro correto.
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
