✨ 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 e um teoria sobre o desuso dos fluxogramas
☕💥 Por que os Fluxogramas Caíram em Desuso?
Ou como um Padawan COBOL descobriu que o vilão não era o losango, mas a pressa do mercado
A resposta curta é:
Fluxogramas não morreram. Eles foram substituídos, fragmentados, escondidos dentro de outras ferramentas e vítimas da pressão por velocidade de entrega.
E isso aconteceu por vários motivos.
1. O software ficou monstruosamente grande
Na década de 70, um programa COBOL típico poderia ter:
Bellacosa Mainframe e o fluxograma no mundo mainframe
☕💥 Fluxogramas no Mundo Mainframe
Ou como um Padawan COBOL descobre que antes do IF WS-SALDO > ZERO, existia um desenhinho que salvava projetos milionários
"Um programa COBOL sem fluxograma é como um JCL sem JOB CARD. Talvez execute. Talvez funcione. Mas ninguém vai entender daqui seis meses."
— Mestre Bellacosa Mainframe
Introdução
Uma das maiores diferenças entre um desenvolvedor COBOL júnior de hoje e um analista de sistemas da década de 1970, 1980 ou 1990 não está na linguagem.
Não está no z/OS.
Não está no DB2.
Não está no CICS.
Está na forma de pensar software.
Hoje aprendemos:
Fazer código
Testar
Commitar
Fazer Pull Request
Antigamente aprendíamos:
Analisar
Modelar
Desenhar
Revisar
Aprovar
Codificar
E neste mundo existia um personagem muito poderoso.
O Fluxograma.
O nascimento dos fluxogramas
A ideia é muito antiga.
Vem dos trabalhos de engenharia industrial.
Frank Gilbreth
Henry Gantt
Por volta de 1921 começaram a desenhar processos industriais.
Exemplo:
Receber matéria-prima
↓
Produzir
↓
Inspecionar
↓
Embalar
↓
Enviar
Décadas depois os computadores apareceram.
E alguém percebeu:
"Programas são processos."
Logo...
Processos industriais
viraram
Processos computacionais.
O modelo Waterfall
Se você trabalha em Mainframe bancário provavelmente ainda verá isso.
Waterfall.
As fases clássicas:
Requisitos
↓
Análise
↓
Fluxogramas
↓
Especificação Técnica
↓
Codificação
↓
Teste
↓
Implantação
Documentos clássicos do Waterfall
Documento Funcional
O que o sistema faz.
Exemplo:
Pagamento de boleto
Regra:
Se vencido
cobrar multa
Se pago em dia
valor normal
Documento Técnico
Como será implementado.
Exemplo:
Programa:
PAGBOL01
Tabela:
TB_BOLETO
Transação:
PB01
Copybooks
CPBOLETO
Fluxograma
É a ponte entre os dois.
Negócio
↓
Fluxograma
↓
COBOL
Bellacosa Mainframe e os simbolos de fluxograma
O que é um Fluxograma?
É uma representação gráfica de um algoritmo.
Ao invés de escrever:
IF SALDO > ZERO
DISPLAY "OK"
ELSE
DISPLAY "NEGADO"
END-IF
Desenhamos.
◇
SALDO > 0 ?
/ \
SIM NÃO
↓ ↓
OK NEGADO
Nosso cérebro entende imagens mais rapidamente.
Por isso funcionam.
Símbolos principais
Oval
Significado:
Início
Fim
Exemplo
_______
(START )
-------
ou
_______
( END )
-------
Retângulo
Processamento.
Fazer algo.
Exemplo:
Calcular juros
Atualizar cadastro
Mover campos
Exemplo COBOL
COMPUTE JUROS =
SALDO * 0.05
Fluxograma
□ Calcular juros
Losango
Decisão.
Pergunta.
Tem duas saídas.
SIM
NÃO
Exemplo
Cliente VIP?
COBOL
IF CLIENTE-VIP='S'
Paralelogramo
Entrada e saída.
DISPLAY
ACCEPT
RECEIVE
SEND
Batch
Ler arquivo
Online
Receber PFKEY
Seta
Fluxo.
Indica sequência.
Sem seta.
Existe caos.
Com seta.
Existe entendimento.
Círculo
Conector.
Liga páginas.
Muito usado em especificações gigantes.
Página 1
↓
○A
Página 10
○A
continuação
Bellacosa Mainframe e um fluxograma cobol batch
Fluxograma de Batch COBOL
Imagine:
Pagar folha salarial.
Desenho
START
↓
Abrir arquivo
↓
Ler funcionário
↓
Fim Arquivo?
◇
Sim
Gerar relatório
END
Não
Calcular salário
Gravar saída
Ler próximo
COBOL
OPEN INPUT FUNCIONARIO
PERFORM UNTIL EOF='S'
READ FUNCIONARIO
AT END
MOVE 'S' TO EOF
NOT AT END
PERFORM CALCULA
WRITE REG-SAIDA
END-READ
END-PERFORM
Bellacosa Mainframe exemplo de fluxograma cobol vsam
Fluxograma para VSAM
Abrir KSDS
↓
READ
↓
FOUND?
SIM
UPDATE
REWRITE
NÃO
WRITE
END
Bellacosa Mainframe exemplo de fluxograma online cics
Fluxograma Online CICS
Exemplo.
Consulta saldo.
START
Receber tela
↓
ENTER?
SIM
↓
Validar conta
↓
Conta existe?
◇
SIM
Ler DB2
Enviar tela
NÃO
Mensagem erro
END
COBOL
EXEC CICS RECEIVE MAP
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTA
END-EXEC
EXEC CICS SEND MAP
END-EXEC
Bellacosa Mainframe exemplo de fluxograma db2
Fluxograma com DB2
Exemplo.
Transferência bancária.
START
Receber origem
Receber destino
Valor válido?
◇
SIM
BEGIN UNIT OF WORK
SELECT
UPDATE
UPDATE
COMMIT
NÃO
ROLLBACK
END
Fluxograma das tabelas DB2
Tabela
CLIENTE
Tabela
CONTA
Tabela
MOVIMENTO
Fluxo
CLIENTE
↓
CONTA
↓
MOVIMENTO
Exemplo SQL
SELECT
C.NOME,
M.VALOR
FROM CLIENTE C
JOIN CONTA CT
ON...
JOIN MOVIMENTO M
Fluxograma ajuda a enxergar joins.
Workflow
Muitos confundem.
Fluxograma
não é
Workflow
Mas workflow pode usar fluxograma.
Exemplo
Solicitação crédito
Cliente
↓
Análise
↓
Aprovação gerente
↓
Compliance
↓
Liberação
Hoje isso está em:
IBM BPM
Camunda
ServiceNow
Power Automate
Fluxos de diálogo
Muito usado em CICS.
Tela login
↓
Senha válida?
◇
Sim
Menu
Não
Mensagem erro
Chatbots fazem isso.
ChatGPT faz isso.
URA faz isso.
PIX faz isso.
Boas práticas
1 Não cruzar linhas
Errado
Linhas embaralhadas.
Causa dor psicológica.
2 Usar nomes claros
Errado
Processo 1
Correto
Calcular IOF
3 Uma decisão por vez
Evita confusão.
4 Modularizar
Subfluxos.
Exemplo
Pagamento
↓
Calcular imposto
↓
Fluxograma separado
Curiosidades
Easter Egg 1
COBOL nasceu em 1959.
Fluxogramas já eram padrão.
Easter Egg 2
Muitos programadores COBOL dos anos 80 codificavam olhando apenas para fluxogramas.
Nem tinham acesso ao usuário.
Easter Egg 3
Ferramentas CASE prometiam gerar COBOL automaticamente.
Excelerator
ADW
CoolGen
IEF
Pacbase
A ideia era:
Desenhar
Gerar programa
Compilar
Easter Egg 4
IBM usou fluxogramas extensivamente na documentação do OS/360.
Centenas de páginas.
Easter Egg 5
DFSORT pode ser representado perfeitamente por fluxograma.
INPUT
↓
SORT
↓
SUM
↓
OUTREC
↓
OUTPUT
Por que ainda usamos em Mainframe?
Porque sistemas bancários possuem:
Centenas de regras
Milhares de IFs
Milhões de contas
Um código COBOL pode ter:
30000 linhas
500 parágrafos
200 IFs
Ler isso é cansativo.
Ver um desenho leva segundos.
O Fluxograma como ferramenta de sobrevivência do Padawan COBOL
É por isso que arquitetos, analistas de sistemas, especialistas em CICS, DB2, IMS, MQ, BPM e até equipes DevOps continuam utilizando fluxogramas.
Eles não substituem COBOL.
Não substituem UML.
Não substituem documentação funcional.
Mas fazem algo extremamente valioso: transformam milhares de linhas de código em uma história visual que qualquer pessoa consegue seguir.
E, no universo Bellacosa Mainframe, talvez esta seja a melhor definição possível:
Fluxograma é o mapa da dungeon. COBOL é a espada. DB2 é o tesouro. CICS é o portal de entrada. E o programador júnior que aprende a desenhar processos deixa de ser apenas um codificador e começa a pensar como um verdadeiro Analista de Sistemas do Reino IBM Z. ☕🚀
Bellacosa Mainframe o que é analise de sistema em mainframe
O que é Análise de Sistemas em Mainframe?
Quando alguém ouve a expressão Analista de Sistemas Mainframe, normalmente imagina uma pessoa programando em COBOL diante de um terminal 3270.
Na realidade, essa é apenas uma pequena parte do trabalho.
O Analista de Sistemas Mainframe é o profissional responsável por compreender o negócio da empresa, transformar necessidades em soluções tecnológicas e garantir que aplicações críticas continuem funcionando com segurança, desempenho e confiabilidade.
Em um banco, por exemplo, ele ajuda a garantir que milhões de transações financeiras sejam processadas corretamente todos os dias.
Definição simples
A Análise de Sistemas Mainframe é a disciplina que estuda, projeta, desenvolve, mantém e evolui aplicações executadas em ambientes IBM Z (z/OS), alinhando tecnologia às necessidades do negócio.
Ela envolve muito mais do que escrever programas COBOL.
O analista precisa compreender:
processos de negócio;
regras bancárias;
requisitos legais;
arquitetura dos sistemas;
bancos de dados;
integração entre aplicações;
desempenho;
segurança;
qualidade.
Em outras palavras:
O Analista de Sistemas transforma problemas do negócio em soluções executadas no Mainframe.
Uma analogia simples
Imagine a construção de um hospital.
O médico sabe tratar pacientes.
O engenheiro sabe construir o prédio.
O arquiteto transforma necessidades em um projeto.
O Analista de Sistemas faz algo parecido.
Ele conversa com usuários, entende os problemas e desenha a solução que será implementada pelos desenvolvedores.
Onde trabalha?
Praticamente todos os setores que utilizam IBM Mainframe.
Por exemplo:
bancos;
seguradoras;
operadoras de cartões;
bolsas de valores;
companhias aéreas;
telecomunicações;
indústrias;
empresas de energia;
órgãos governamentais.
O objetivo
Todo projeto começa com uma necessidade.
Exemplo:
"O banco deseja permitir pagamentos via PIX parcelado."
O Analista deverá responder perguntas como:
quais programas serão alterados?
quais tabelas Db2 mudarão?
haverá novos arquivos VSAM?
quais APIs serão chamadas?
haverá impacto no CICS?
será necessário alterar JCLs?
existem riscos?
Como funciona?
Um projeto normalmente segue este fluxo:
Necessidade do Negócio
↓
Análise
↓
Especificação
↓
Desenvolvimento COBOL
↓
Testes
↓
Homologação
↓
Produção
Principais atividades
Levantamento de requisitos
Conversa com:
clientes;
usuários;
gerentes;
especialistas do negócio.
Objetivo:
Entender exatamente o problema.
Análise das aplicações
O analista estuda:
programas COBOL;
CICS;
JCL;
Db2;
VSAM;
MQ;
APIs.
Ele identifica:
dependências;
impactos;
riscos.
Especificação funcional
Produz documentos descrevendo:
o que será feito;
regras de negócio;
validações;
exceções;
telas;
mensagens;
relatórios.
Especificação técnica
Detalha:
programas envolvidos;
arquivos;
tabelas;
campos;
transações;
interfaces.
Serve de base para os desenvolvedores.
Acompanhamento do desenvolvimento
Durante a implementação:
esclarece dúvidas;
revisa soluções;
valida regras.
Testes
Participa de:
testes unitários;
integração;
homologação;
regressão.
Implantação
Auxilia na entrada em produção.
Tecnologias utilizadas
O Analista normalmente trabalha com:
Linguagens
COBOL;
PL/I;
Assembler;
Java.
Banco de Dados
Db2;
IMS DB.
Processamento
CICS;
IMS TM;
Batch.
Arquivos
VSAM;
Sequential Files;
GDG.
Integração
MQ;
APIs REST;
z/OS Connect;
Kafka (em ambientes híbridos).
DevOps
Git;
Jenkins;
GitHub;
GitLab;
IBM DBB.
Conhecimentos importantes
Além da programação, o analista precisa entender:
arquitetura Mainframe;
processos bancários;
cartões;
PIX;
boletos;
crédito;
contabilidade;
LGPD;
segurança.
Exemplo prático
Imagine que um banco deseja aumentar o limite do PIX.
O Analista precisará verificar:
Nova Regra
↓
Programas COBOL
↓
Db2
↓
CICS
↓
APIs
↓
Testes
↓
Produção
Antes que qualquer linha de código seja alterada.
Diferença entre Programador e Analista
Programador
Seu foco principal é implementar o código.
Exemplo:
escreve COBOL;
cria JCL;
corrige erros.
Analista
Seu foco é entender o sistema como um todo.
Ele responde perguntas como:
por que essa regra existe?
quais sistemas serão afetados?
quais riscos existem?
como integrar novos módulos?
Benefícios da profissão
Grande demanda no mercado financeiro.
Contato com regras de negócio complexas.
Participação em projetos estratégicos.
Salários competitivos.
Evolução para arquitetura e liderança.
Curiosidades
1. Boa parte do trabalho não envolve programação
Analistas passam muito tempo estudando regras de negócio, documentos, diagramas e impactos antes que o desenvolvimento comece.
2. Conhecer o negócio é tão importante quanto conhecer COBOL
Um excelente programador pode escrever código perfeito, mas sem entender as regras bancárias pode implementar uma solução incorreta.
3. Um analista pode trabalhar em dezenas de sistemas ao mesmo tempo
É comum acompanhar aplicações de cartões, contas correntes, empréstimos, PIX, investimentos e canais digitais simultaneamente.
4. A IA está mudando a profissão
Ferramentas baseadas em Inteligência Artificial já ajudam na análise de programas COBOL, documentação, geração de testes e identificação de impactos, mas a decisão sobre regras de negócio continua sendo responsabilidade do analista.
Habilidades necessárias
Um bom Analista de Sistemas Mainframe desenvolve competências como:
lógica de programação;
comunicação;
análise de requisitos;
resolução de problemas;
documentação;
modelagem de processos;
visão sistêmica;
trabalho em equipe.
Erros comuns de iniciantes
"Analista só programa COBOL"
Não.
Grande parte do trabalho envolve análise, documentação, reuniões e entendimento das regras de negócio.
"Conhecer COBOL é suficiente"
Não.
Também é importante conhecer CICS, Db2, JCL, VSAM, APIs, DevOps e o funcionamento do negócio da empresa.
"Análise de Sistemas acabou por causa da IA"
Pelo contrário.
A IA automatiza tarefas repetitivas, mas compreender necessidades do negócio, avaliar impactos e tomar decisões arquiteturais continua sendo uma atividade essencialmente humana.
Quando estudar Análise de Sistemas Mainframe?
Uma boa sequência é:
Lógica de Programação.
COBOL.
JCL.
z/OS.
VSAM.
CICS.
Db2.
MQ.
APIs REST.
DevOps.
Engenharia de Requisitos.
Arquitetura de Sistemas.
Inteligência Artificial aplicada ao Mainframe.
Conclusão
A Análise de Sistemas Mainframe é uma das funções mais estratégicas do ambiente IBM Z. Ela conecta o mundo dos negócios ao mundo da tecnologia, garantindo que aplicações críticas evoluam com segurança, desempenho e confiabilidade.
O Analista de Sistemas não é apenas um programador experiente. Ele é o profissional que compreende processos, interpreta regras de negócio, avalia impactos, especifica soluções, acompanha o desenvolvimento e ajuda a manter funcionando sistemas que movimentam bancos, seguradoras, governos e grandes empresas. Para quem deseja construir uma carreira sólida no Mainframe, dominar Análise de Sistemas é um passo fundamental rumo a cargos de arquitetura, liderança técnica e consultoria especializada.
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
