✨ 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
O DIO Global faz 5 anos esse mês. E quando a gente olhar para essa data de verdade, o que aparece não é um número. São rostos.
São mais de 50.000 profissionais que foram contratados em empresas de tecnologia através da DIO. Pessoas que estavam em transição de carreira, que buscavam a primeira vaga, que precisavam do inglês certo para competir com qualquer profissional do mundo. Que tinham talento, mas precisavam de um caminho.
Você ajudou a construir esse caminho.
O conteúdo que você produziu chegou a profissionais que mudaram de vida por conta do que aprenderam. Isso é raro. A maioria das pessoas passa anos trabalhando sem saber ao certo o impacto do que faz. Você sabe.
Cinco anos é tempo suficiente para olhar para trás e ter clareza sobre quem construiu isso junto. E o seu nome está nessa lista.
Em anexo você encontra um reconhecimento de gratidão da DIO pelo que você fez pela educação e pela carreira de tanta gente que confiou nesse projeto.
Nosso agradecimento e reconhecimento por você ter impactado milhares de pessoas por meio da educação e empregabilidade.
Alcançar cinco anos de participação na DIO (Digital Innovation One) representa muito mais do que uma marca temporal. É o reconhecimento de uma trajetória construída por meio de aprendizado contínuo, troca de experiências e desenvolvimento profissional dentro de uma das maiores comunidades de tecnologia do Brasil.
Ao longo desse período, milhares de profissionais utilizaram a plataforma para expandir conhecimentos em áreas como programação, computação em nuvem, inteligência artificial, ciência de dados, segurança da informação, DevOps, arquitetura de sistemas e diversas outras especialidades do mercado tecnológico. A DIO tornou-se uma ponte entre conhecimento e oportunidades, aproximando estudantes, profissionais e empresas.
Receber um reconhecimento pelos cinco anos de jornada simboliza dedicação, persistência e compromisso com a evolução constante. Em um setor que se transforma diariamente, manter-se atualizado é um diferencial fundamental para enfrentar novos desafios e acompanhar as mudanças do mercado.
Além dos cursos e certificações, a experiência envolve participação em comunidades, eventos, bootcamps e iniciativas colaborativas que fortalecem o networking e o compartilhamento de conhecimento.
Esse marco também representa uma oportunidade para olhar para trás e perceber o quanto foi conquistado ao longo dos anos. Mais do que um certificado ou homenagem, os cinco anos na DIO refletem uma trajetória de crescimento, aprendizado contínuo e paixão pela tecnologia, valores essenciais para quem constrói uma carreira sólida na área de TI.
Bellacosa Mainframe e a quebra do contrato social parte v
☕ Um Café no Bellacosa Mainframe
O Isekai e o Contrato Social Quebrado – Parte V
Quando um Programador COBOL Descobre que Quase Todo Protagonista de Isekai é um Salaryman... e Isso Está Muito Longe de Ser Coincidência
Depois de escrever os capítulos anteriores, resolvi fazer um pequeno exercício.
Peguei dezenas de isekais.
Comecei a anotar quem eram seus protagonistas antes da reencarnação.
O resultado me surpreendeu.
Na verdade...
Nem tanto.
A maioria absoluta era formada por pessoas completamente comuns.
Funcionários de escritório.
Salarymen.
Programadores.
Estudantes.
Desempregados.
Hikikomori.
NEETs.
Pouquíssimos eram milionários.
Pouquíssimos eram celebridades.
Pouquíssimos eram políticos.
Quase nenhum era um grande empresário.
Foi aí que percebi uma coisa.
O isekai nunca foi escrito para quem está no topo da pirâmide.
Ele foi escrito para quem acorda cedo na segunda-feira.
O Salaryman é o Guerreiro Moderno
No Ocidente, quando pensamos em heróis, imaginamos cavaleiros.
Cowboys.
Super-heróis.
No Japão...
Existe outro personagem.
O salaryman.
Ele veste terno.
Carrega uma pasta.
Pega trem lotado.
Chega cedo.
Sai tarde.
Volta para casa exausto.
Repete tudo no dia seguinte.
Sem espada.
Sem armadura.
Sem magia.
Seu chefe final chama-se:
Meta.
A Armadura Virou Gravata
É curioso perceber como os símbolos mudam.
O cavaleiro medieval carregava escudo.
O trabalhador moderno carrega notebook.
O aventureiro tinha espada.
O analista tem crachá.
O mago possuía grimório.
O desenvolvedor possui documentação.
O arqueiro carregava flechas.
O consultor carrega PowerPoint.
Mudam os equipamentos.
As batalhas continuam existindo.
O Reino Corporativo
Quanto mais observo...
Mais vejo semelhanças.
Existe um rei.
Chamado CEO.
Existem nobres.
Chamados diretores.
Existem lordes.
Chamados gerentes.
Existem cavaleiros.
Chamados coordenadores.
Existem aldeões.
Chamados funcionários.
Existe um castelo.
Chamado escritório.
Existe uma guilda.
Chamada Recursos Humanos.
Existe um imposto.
Chamado desconto em folha.
E existe um dragão.
Chamado prazo.
O NPC do Próprio Sistema
Talvez o maior medo do trabalhador moderno seja outro.
Não é perder o emprego.
É descobrir que virou um NPC da própria vida.
Acorda.
Trabalha.
Paga contas.
Dorme.
Repete.
Os dias deixam de ser lembranças.
Viram apenas datas no calendário.
É exatamente nesse momento que aparece o portal do isekai.
O Herói Nunca Foi Especial
Repare.
Na maioria das histórias.
O protagonista não era extraordinário.
Era justamente o contrário.
Era invisível.
Ninguém prestava atenção.
Ninguém reconhecia seu esforço.
Ninguém o admirava.
Então ele muda de mundo.
Pela primeira vez...
Alguém diz.
"Precisávamos de você."
Essa frase vale mais do que qualquer espada lendária.
O Japão Também Está Cansado
Às vezes imaginamos que o sucesso do isekai aconteceu porque os japoneses gostam de fantasia medieval.
Acho que a explicação é mais profunda.
O Japão conhece muito bem palavras como:
Karōshi.
Morte por excesso de trabalho.
Hikikomori.
Isolamento social.
Kodokushi.
Morte solitária.
Esses fenômenos não surgiram do nada.
Eles refletem tensões reais de uma sociedade altamente exigente.
O isekai talvez seja uma forma de responder emocionalmente a essas pressões.
O Programador Também Sonha
Talvez por isso tantos protagonistas sejam desenvolvedores.
Ou analistas.
Ou profissionais de TI.
Nós entendemos algo muito específico.
Passamos anos resolvendo problemas dos outros.
Corrigindo sistemas.
Otimizando processos.
Automatizando tarefas.
Mas existe uma pergunta que raramente fazemos.
Quem está corrigindo o sistema da nossa própria vida?
O Holerite Nunca Conta a História Completa
Chega o quinto dia útil.
O salário entra.
Antes mesmo de você respirar.
Uma parte já foi embora.
Contribuições.
Impostos.
Descontos.
Financiamentos.
Contas.
Depois vem o supermercado.
Combustível.
Pedágio.
Plano de saúde.
Mensalidades.
IPTU.
IPVA.
Conta de energia.
Conta de água.
Internet.
No fim...
Você percebe que passou mais um mês inteiro trabalhando.
E a sensação de liberdade continua exatamente igual.
Não é uma crítica à existência de impostos em si, que financiam serviços essenciais em qualquer sociedade organizada. A inquietação aparece quando muitos trabalhadores sentem que o retorno percebido não acompanha o esforço exigido para gerar aquela renda.
O Nível Não Sobe
Nos RPGs.
Você trabalha.
Fica mais forte.
No mercado moderno.
Às vezes acontece algo diferente.
Você trabalha.
Aprende.
Estuda.
Faz cursos.
Obtém certificações.
Assume novas responsabilidades.
Mas a percepção é que a qualidade de vida evolui muito menos do que o conhecimento adquirido.
É como jogar durante cinquenta horas...
...e descobrir que seu personagem continua preso no mesmo mapa.
O Sonho Nunca Foi Ser Rico
Existe um equívoco enorme.
As pessoas imaginam que o trabalhador quer riqueza.
Talvez não.
A maioria quer apenas tranquilidade.
Dormir sem ansiedade.
Viajar uma vez por ano.
Comprar um livro sem fazer contas.
Ter tempo para os filhos.
Ter saúde.
Ter algum dinheiro guardado.
Aposentar-se com dignidade.
Curiosamente...
Esses desejos parecem muito mais modestos do que derrotar um dragão.
Bellacosa Mainframe
Depois de tantos anos escrevendo COBOL, percebi que todo sistema precisa obedecer a uma regra fundamental.
A entrada deve produzir uma saída previsível.
Se você alimenta um programa corretamente durante quarenta anos...
Espera um resultado coerente.
Quando isso deixa de acontecer...
Chamamos de erro lógico.
Talvez seja exatamente essa a sensação de muitos trabalhadores.
Eles executaram corretamente o programa que lhes ensinaram.
Estudaram.
Trabalharam.
Pagaram impostos.
Contribuíram para a previdência.
Cumpriram horários.
Aceitaram responsabilidades.
Mesmo assim...
O resultado esperado parece cada vez mais distante.
É nesse instante que o portal mágico começa a fazer sentido.
Não porque exista um dragão esperando do outro lado.
Mas porque, pela primeira vez em muito tempo, alguém olha para aquele trabalhador cansado e diz:
"Você não é apenas mais um número na folha de pagamento."
Talvez essa seja a verdadeira magia do isekai.
Não lançar meteoros.
Não derrotar demônios.
Mas devolver ao protagonista algo que ele perdeu muito antes de atravessar o portal.
A sensação de que sua existência tem valor.
Continua na Parte VI — "O Reino da Fantasia ou a Sociedade Perdida? Por Que o Mundo Medieval dos Isekais Parece Mais Humano do que as Grandes Cidades Modernas".
☕ UM CAFÉ NO BELLACOSA MAINFRAME
O Isekai e o Contrato Social Quebrado
Quando um Programador COBOL Descobre que Talvez Nunca Tenhamos
Querido Fugir para Outro Mundo... Apenas Entender Este.
PRIMEIRA REGRA DO PORÃONENHUM ARTIGO DEVE FICAR ESCONDIDO DOS LEITORES
Entre nesta série sobre trabalho, impostos, burnout, sociedade,
salarymen, guildas, promessas quebradas e o verdadeiro significado
da fuga para mundos paralelos. Escolha um capítulo, abra a prévia
ou leia diretamente no Bellacosa Mainframe.
00
SYSTEM DIAGNOSIS
O Verdadeiro Rei Demônio Talvez Seja o Holerite
Quando um Programador COBOL Descobre que o Isekai Não Vende
Magia... Vende um Mundo Onde o Esforço Ainda Vale Alguma Coisa.
Uma introdução à relação entre o sucesso do gênero isekai,
a exaustão do trabalhador moderno, os descontos no salário,
a perda de propósito e o desejo de recomeçar em outro mundo.
Quando um Programador COBOL Descobre que os Anos 1990 Talvez
Tenham Sido o Grande IPL da Economia Mundial... e Nem Todos
os JOBs Voltaram a Executar.
Globalização, tecnologia, automação, terceirização e
produtividade reinicializaram a economia mundial, mas muitos
trabalhadores ficaram aguardando uma resposta do sistema.
Quando um Programador COBOL Descobre que a Guilda dos
Aventureiros Talvez Tenha um RH Muito Melhor que o Nosso.
Na guilda existem missões claras, riscos conhecidos,
recompensas publicadas e liberdade para escolher o próximo
trabalho. No escritório moderno, nem sempre.
Quando um Programador COBOL Descobre que o Truck-kun Nunca
Foi um Caminhão... Mas um Botão de CANCEL JOB para uma
Geração Inteira.
Truck-kun representa a interrupção brutal de uma vida
repetitiva, exausta e sem perspectiva. Um símbolo sombrio
do desejo de cancelar a rotina e recomeçar.
Quando um Programador COBOL Descobre que Quase Todo
Protagonista de Isekai é um Salaryman... e Isso Está Muito
Longe de Ser Coincidência.
Programadores, funcionários de escritório e trabalhadores
invisíveis protagonizam histórias de recomeço porque
representam milhões de pessoas presas em rotinas semelhantes.
Quando um Programador COBOL Descobre que Talvez o Verdadeiro
Feitiço do Isekai Não Seja a Magia... Mas o Tempo para Viver.
O maior luxo de um mundo fantástico talvez não seja lançar
feitiços, mas ter tempo para conversar, descansar, conviver,
caminhar e participar de uma comunidade.
Quando um Programador COBOL Descobre que Talvez Nunca
Tenhamos Querido Fugir para Outro Mundo... Apenas Recuperar Este.
A conclusão da série propõe que talvez o verdadeiro sonho
nunca tenha sido abandonar o mundo real, mas recuperar
dignidade, propósito, tempo, comunidade e esperança.
Alguns sites podem impedir sua exibição dentro de um iframe
utilizando X-Frame-Options ou Content-Security-Policy. Nesse caso,
utilize o link acima para abrir o artigo diretamente.
Bellacosa Mainframe apresenta engenharia militar parte vi
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Capítulo VI — Inteligência, Reconhecimento e Espionagem: A Guerra é Vencida por Quem Enxerga Primeiro
Quando um Programador COBOL Descobre que o Maior Perigo Não Está no Inimigo... Está nas Decisões Tomadas Sem Informação
A névoa cobria completamente o vale.
Do alto da muralha, o jovem samurai apertava os olhos tentando distinguir algum movimento entre as árvores.
Nada.
Silêncio absoluto.
Mesmo assim, o velho comandante permaneceu imóvel.
Depois de alguns minutos perguntou:
— O que você vê?
— Nada.
— Então ainda não aprendeu a observar.
O rapaz ficou confuso.
— Se não existe ninguém...
...o que devo procurar?
O comandante sorriu.
— Pegadas.
Galhos quebrados.
Fumaça.
Pegadas de cavalos.
Pegadas de carroças.
Marcas de rodas.
Cinzas recentes.
Pássaros levantando voo.
Silêncio onde normalmente existem insetos.
A guerra nunca começa quando vemos o inimigo.
Ela começa muito antes.
Séculos depois...
04h11 da madrugada.
Uma equipe de produção recebia um chamado urgente.
Uma aplicação havia parado.
Todos olhavam para o programa COBOL.
O analista mais experiente, entretanto, fazia outra pergunta.
— O que mudou hoje?
Silêncio.
Ninguém sabia.
Naquele instante, o jovem desenvolvedor descobriu que investigar sistemas críticos parecia muito mais com o trabalho de um detetive do que com o de um programador.
Pegue seu café.
Hoje caminharemos pela parte mais silenciosa da engenharia militar.
Porque toda fortaleza que sobreviveu durante séculos possuía excelentes muralhas.
Mas também possuía excelentes observadores.
1. A inteligência vem antes da batalha
Ao longo da História, inúmeros conflitos foram decididos antes mesmo do primeiro combate.
Por quê?
Porque um dos lados conhecia:
o terreno;
a quantidade de tropas;
os suprimentos;
as rotas;
o clima;
as intenções do adversário.
Conhecimento reduz incerteza.
E reduzir incerteza significa aumentar a qualidade das decisões.
O melhor comandante não é necessariamente aquele que luta melhor.
É aquele que luta apenas quando compreende o cenário.
2. O reconhecimento
Na engenharia militar existe uma atividade essencial.
Reconhecimento.
Antes de mover milhares de soldados é necessário descobrir:
Existe ponte?
Existe rio?
Existe lama?
Existe floresta?
Existe emboscada?
Existe água?
Existe alimento?
Existe rota alternativa?
Essa etapa parece lenta.
Mas economiza vidas.
Na programação ocorre exatamente igual.
Antes de alterar um programa COBOL devemos realizar reconhecimento técnico.
3. O reconhecimento de um programa COBOL
Imagine que você receba uma manutenção.
Antes de escrever qualquer linha, investigue.
Quem chama este programa?
Quem é chamado por ele?
Quais copybooks utiliza?
Quais arquivos lê?
Quais tabelas atualiza?
Existe CICS?
Existe MQ?
Existe Db2?
Existe VSAM?
Existe API?
Existe JCL específico?
Existe scheduler?
Existe documentação?
Existe histórico de incidentes?
Esse levantamento parece burocrático.
Na realidade...
é inteligência operacional.
4. O explorador imprudente
Existe um erro muito comum entre iniciantes.
Abrir o programa.
Encontrar o IF.
Alterar.
Compilar.
Testar.
Implantar.
Sem compreender o restante.
Isso equivale a um explorador entrar em uma floresta desconhecida olhando apenas dois metros à frente.
Talvez consiga atravessar.
Talvez encontre um penhasco.
A diferença está na informação.
5. O mapa vale mais que a espada
Os antigos cartógrafos eram considerados profissionais estratégicos.
Um mapa correto permitia:
economizar dias de viagem;
evitar montanhas;
encontrar água;
transportar suprimentos;
escapar de cercos.
Hoje nossos mapas são diferentes.
Podem ser:
diagramas;
fluxogramas;
inventários;
dependências;
arquiteturas;
linhagem de dados;
catálogos de APIs;
runbooks.
Quanto melhor o mapa...
menor o risco da campanha.
6. O Investigador COBOL
Antes de modificar qualquer rotina, transforme-se em investigador.
Exemplo de roteiro.
Etapa 1
Leia toda a especificação.
Etapa 2
Descubra quando o programa executa.
Etapa 3
Descubra quem depende dele.
Etapa 4
Procure alterações semelhantes.
Etapa 5
Leia comentários antigos.
Etapa 6
Converse com especialistas.
Etapa 7
Somente então altere o código.
Muitas vezes metade do problema desaparece durante essa investigação.
7. O poder das perguntas
Um bom engenheiro não começa respondendo.
Começa perguntando.
Perguntas como:
Por que essa regra existe?
Quando surgiu?
Quem solicitou?
Quem aprovou?
Ela ainda é necessária?
Existe legislação envolvida?
Qual processo de negócio depende disso?
Qual seria o impacto de removê-la?
Essas perguntas frequentemente revelam mais que horas examinando código.
8. A espionagem na História
Espiões existiram em praticamente todas as civilizações.
No Japão feudal encontramos diversas formas de coleta de informação.
Na China antiga, Sun Tzu dedicou um capítulo inteiro ao uso estratégico de agentes.
Na Europa medieval, mercadores frequentemente transportavam notícias entre reinos.
Nem toda informação vinha de soldados.
Quem conhece primeiro...
decide primeiro.
9. Inteligência não é espionagem
Essa diferença é importante.
Espionagem é apenas uma das formas possíveis de obter informação.
Inteligência significa:
coletar;
organizar;
correlacionar;
analisar;
interpretar;
transformar dados em decisão.
No Data Center fazemos isso diariamente.
Logs.
SMF.
RMF.
Estatísticas.
Alertas.
Métricas.
SQL.
Performance.
Tudo isso produz inteligência operacional.
10. O CSI do Mainframe
Durante nossas conversas utilizamos diversas vezes a metáfora da série CSI.
Ela funciona muito bem.
O investigador não pergunta:
"Quem parece culpado?"
Pergunta:
"O que as evidências mostram?"
Da mesma forma, um bom analista não começa culpando:
o COBOL;
o Db2;
o CICS;
o storage.
Primeiro coleta evidências.
Depois formula hipóteses.
Finalmente valida cada hipótese.
É exatamente o método científico.
11. O Log é uma testemunha
Muitos iniciantes enxergam logs apenas como mensagens.
Na verdade eles são testemunhas.
Um log bem construído informa:
quem executou;
quando;
o que ocorreu;
qual registro foi processado;
qual erro apareceu;
qual decisão foi tomada.
Sem logs...
uma investigação transforma-se em adivinhação.
12. O ABEND também conta uma história
Quando um ABEND acontece...
não devemos perguntar apenas:
"Como removê-lo?"
Precisamos perguntar:
"Por que ele apareceu?"
Um ABEND pode revelar:
erro de dados;
erro de integração;
erro operacional;
erro de infraestrutura;
erro humano;
erro arquitetural.
Eliminar o sintoma não elimina necessariamente a causa.
13. Goblin Slayer e o reconhecimento
Goblin Slayer dificilmente invade uma caverna imediatamente.
Primeiro observa.
Conta pegadas.
Calcula entradas.
Analisa vento.
Verifica fumaça.
Escuta sons.
Pergunta aos moradores.
Somente depois define o plano.
Ele nunca confunde coragem com imprudência.
Essa postura deveria inspirar qualquer profissional de TI.
14. Shogun e a informação
Em Shogun, informação vale mais que milhares de soldados.
Quem conhece:
as alianças;
os comerciantes;
os missionários;
os portos;
os rumores;
os interesses políticos;
possui enorme vantagem.
As guerras raramente são decididas apenas pela força.
São decididas pela qualidade das informações disponíveis.
15. Attack on Titan e as hipóteses
Uma das grandes qualidades da obra é mostrar personagens mudando de estratégia quando surgem novos fatos.
Eles revisam hipóteses.
Questionam crenças.
Reavaliam decisões.
Na engenharia acontece igual.
Quando novas evidências aparecem...
precisamos estar dispostos a abandonar explicações antigas.
16. A inteligência dos dados
Hoje falamos muito sobre Inteligência Artificial.
Mas IA depende profundamente da qualidade dos dados.
Existe um antigo princípio.
Garbage In, Garbage Out.
Se os dados estão incorretos...
o modelo produzirá decisões incorretas.
O mesmo vale para programas COBOL.
A lógica pode ser perfeita.
Dados ruins produzem resultados ruins.
17. Curiosidade Histórica
Durante a Segunda Guerra Mundial, a quebra de códigos criptográficos e a análise sistemática de mensagens tiveram impacto estratégico comparável ao de grandes batalhas. Informações obtidas e corretamente interpretadas permitiram antecipar movimentos, proteger comboios e reduzir perdas.
Nos ambientes corporativos modernos, a análise de logs, métricas, eventos de segurança e indicadores operacionais desempenha papel semelhante. A capacidade de transformar dados em decisões rápidas aumenta significativamente a resiliência dos sistemas críticos.
18. Easter Egg — O IF que Nunca Foi Executado
Conta uma antiga história de um banco que existia um trecho de código aparentemente inútil.
IF WS-CONTROLE = 'S'
PERFORM PROCESSAMENTO-ESPECIAL
END-IF
Durante quinze anos...
ninguém viu aquela condição ser verdadeira.
Um novo desenvolvedor decidiu removê-la.
Parecia código morto.
Os testes passaram.
Produção também.
Até chegar o fechamento anual.
Naquele único dia do ano...
um sistema externo enviava exatamente o valor "S".
O processamento especial alimentava relatórios exigidos por um órgão regulador.
O IF nunca estava morto.
Apenas aguardava o momento correto.
Depois do incidente, um comentário foi adicionado:
* EXECUTADO SOMENTE NO FECHAMENTO ANUAL.
* NÃO REMOVER SEM VALIDAR PROCESSO REGULATÓRIO.
O problema não era a condição.
Era a investigação incompleta.
19. Checklist do Investigador COBOL
Antes de modificar qualquer sistema:
✔ Descobri quem chama este programa?
✔ Conheço seus consumidores?
✔ Li os comentários?
✔ Consultei a documentação?
✔ Analisei logs anteriores?
✔ Verifiquei histórico de incidentes?
✔ Entendi o objetivo da regra?
✔ Existe impacto legal?
✔ Existe impacto contábil?
✔ Existem dependências ocultas?
✔ Os testes representam produção?
✔ Registrei minhas descobertas?
Conclusão — O Homem que Aprendeu a Observar
O jovem samurai caminhava ao lado do velho comandante.
Pararam diante da floresta.
O mestre perguntou:
— Ainda não vê ninguém?
O rapaz sorriu.
— Vejo muito mais do que soldados.
Vejo trilhas.
Vejo árvores quebradas.
Vejo fumaça distante.
Vejo que passaram carroças pesadas.
Vejo que alguém alimentou uma fogueira há poucas horas.
Vejo que os pássaros evitam determinada região.
O velho assentiu.
— Agora você começou a enxergar.
Na madrugada do Data Center, o jovem programador recebeu mais um chamado.
Em vez de abrir imediatamente o editor COBOL, fez algo diferente.
Consultou os logs.
Leu o histórico.
Verificou o scheduler.
Comparou os arquivos.
Analisou os SQLCODEs.
Conversou com a operação.
Depois de vinte minutos concluiu:
O programa estava correto.
O problema era um dataset produzido com layout antigo por outro sistema.
Nenhuma linha de COBOL precisou ser alterada.
O veterano aproximou-se e perguntou:
— O que você aprendeu esta noite?
O rapaz respondeu:
— Descobri que programar é importante.
Mas investigar é indispensável.
O comandante sorriu.
No horizonte, a névoa começava a desaparecer.
Não porque o inimigo tivesse ido embora.
Mas porque alguém finalmente aprendera a enxergar através dela.
E aquele era o primeiro passo para tornar-se não apenas um programador COBOL...
...mas um verdadeiro engenheiro de sistemas críticos.
Este capítulo encerra o primeiro ciclo da série mostrando que estratégia, logística, segurança e arquitetura dependem de inteligência e observação.
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Uma campanha completa sobre estratégia, logística, inteligência,
segurança, liderança, continuidade, sistemas críticos, IBM Z e COBOL.
Um Data Center analisado como uma fortaleza em guerra
A série Engenharia Militar sem Mistérios para Programadores COBOL
compara castelos, exércitos, muralhas, cadeias de comando, logística,
inteligência e operações militares com os ambientes IBM Z responsáveis
por bancos, governos, seguros, transportes e serviços essenciais.
Cada artigo apresenta uma parte dessa arquitetura: aplicações COBOL,
Jobs JCL, transações CICS, bancos Db2, filas MQ, segurança RACF,
monitoramento, contingência, liderança, documentação e continuidade
operacional.
Sala de operações
Índice da campanha
25documentos localizados
Nenhum documento foi encontrado.
Remova os filtros ou pesquise outra palavra.
Índice permanente
Links completos da série Engenharia Militar
Esta relação permanece disponível no HTML da página para mecanismos
de busca, leitores de tela, navegadores sem JavaScript e ferramentas
de arquivamento.
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
