 |
| Bellacosa Mainframe e a engenharia militar parte ii |
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Capítulo II — Estratégia, Operação e Tática: O IF, o Job e a Guerra Inteira
Quando um Programador Descobre que Vencer uma Batalha Não Significa Salvar o Sistema — e que Alterar Dez Linhas Pode Derrotar uma Campanha de Trinta Anos
O nevoeiro ainda cobria o vale quando o mensageiro chegou ao castelo.
Seu cavalo estava coberto de espuma, suas roupas carregavam lama e uma das sandálias havia se rompido durante a subida. Ele atravessou o portão principal sem desmontar, ignorou os protestos dos guardas e somente parou diante da escadaria do salão de comando.
Trazia uma mensagem simples:
A ponte do leste havia sido tomada.
O jovem general ergueu-se imediatamente.
— Mandarei duzentos homens para recuperá-la.
O engenheiro permaneceu em silêncio.
O conselheiro político fechou o mapa.
O senhor feudal observou o mensageiro e perguntou:
— Quantos inimigos?
— Talvez cinquenta.
— Então duzentos homens bastam — respondeu o general.
O senhor feudal não pareceu convencido.
— Por que eles tomaram a ponte?
O mensageiro hesitou.
Não sabia.
A ponte era pequena. Não conduzia diretamente ao castelo. Não ficava na principal rota de suprimentos. À primeira vista, recuperá-la parecia apenas uma questão de honra.
O general via uma batalha.
O senhor feudal tentava compreender a campanha.
Naquela mesma madrugada, muitos séculos depois, um programador COBOL recebeu uma solicitação aparentemente simples:
Alterar uma condição para que clientes com determinado código fossem processados de maneira diferente.
Era apenas um IF.
Talvez dez linhas.
Talvez quinze minutos de trabalho.
Mas ninguém havia explicado por que a regra existia, de onde vinha o código, quem consumia o resultado ou o que aconteceria no fechamento mensal.
O programador enxergava a alteração.
O sistema escondia a guerra inteira.
Prepare o café.
Abra o editor.
E antes de modificar o IF, descubra quem está tentando tomar a ponte.
1. Três palavras que mudam a maneira de pensar
Estratégia, operação e tática são palavras frequentemente utilizadas como se significassem a mesma coisa.
Em reuniões corporativas, quase tudo é chamado de estratégia.
Existe estratégia de senha, estratégia de impressão, estratégia de atualização de planilha e até estratégia para marcar uma reunião sobre outra reunião.
No pensamento militar, porém, essas palavras representam níveis diferentes de decisão.
Estratégia
A estratégia define o objetivo maior.
Ela responde:
O que queremos alcançar?
Por que isso é importante?
Quais resultados justificam o esforço?
Que riscos estamos dispostos a aceitar?
Como essa ação se conecta ao futuro?
Operação
A operação coordena diversas ações para transformar a estratégia em realidade.
Ela responde:
Quais campanhas ou processos precisam acontecer?
Quais unidades participarão?
Em qual sequência?
Com quais recursos?
Dentro de qual período?
Tática
A tática trata da ação local.
Ela responde:
Como executaremos esta tarefa específica?
Qual formação será utilizada?
Qual técnica resolverá o problema imediato?
Como reagiremos ao obstáculo encontrado agora?
Esses três níveis não competem entre si.
Eles se encaixam.
A estratégia aponta o destino.
A operação organiza a viagem.
A tática decide como atravessar a próxima ponte.
2. A estratégia empresarial escondida atrás do COBOL
Um programa COBOL raramente existe apenas para processar registros.
Ele existe porque alguma organização precisa cumprir uma missão.
Pode ser:
pagar aposentadorias;
liberar transações bancárias;
calcular impostos;
emitir faturas;
processar sinistros;
controlar estoques;
fechar a contabilidade;
registrar movimentações;
atualizar saldos;
gerar informações regulatórias.
Essa é a camada estratégica.
Quando o programador recebe uma manutenção, normalmente não recebe toda essa explicação.
O pedido pode chegar assim:
Incluir o código 47 na condição do parágrafo 3200-VALIDAR-CLIENTE.
A frase descreve uma ação tática.
Mas esconde perguntas estratégicas:
O que representa o código 47?
Por que ele passou a ser aceito?
É uma exigência legal?
Afeta clientes antigos?
Altera cálculo financeiro?
Produz impacto regulatório?
Existe data de vigência?
Pode ser aplicado retroativamente?
Quem autorizou a mudança?
O perigo nasce quando uma decisão estratégica é tratada como simples alteração técnica.
Em sistemas críticos, códigos misteriosos raramente são apenas números.
Podem representar produtos, contratos, categorias fiscais, exceções jurídicas ou regras construídas após incidentes históricos.
O programador vê 47.
A empresa vê milhões de reais.
3. O IF como manobra tática
Considere o seguinte trecho:
IF TIPO-CLIENTE = 10
PERFORM PROCESSAR-CLIENTE-PREFERENCIAL
ELSE
PERFORM PROCESSAR-CLIENTE-PADRAO
END-IF
A solicitação pede que os tipos 10 e 47 sejam tratados como preferenciais.
Uma solução possível seria:
IF TIPO-CLIENTE = 10 OR 47
PERFORM PROCESSAR-CLIENTE-PREFERENCIAL
ELSE
PERFORM PROCESSAR-CLIENTE-PADRAO
END-IF
Além de essa forma poder ser inadequada dependendo do compilador, do padrão adotado e da clareza desejada, ela revela um problema maior: alterar a condição sem compreender o significado.
Uma forma mais explícita seria:
IF TIPO-CLIENTE = 10
OR TIPO-CLIENTE = 47
PERFORM PROCESSAR-CLIENTE-PREFERENCIAL
ELSE
PERFORM PROCESSAR-CLIENTE-PADRAO
END-IF
Ou:
EVALUATE TIPO-CLIENTE
WHEN 10
WHEN 47
PERFORM PROCESSAR-CLIENTE-PREFERENCIAL
WHEN OTHER
PERFORM PROCESSAR-CLIENTE-PADRAO
END-EVALUATE
Tecnicamente, a alteração pode estar correta.
Mas a pergunta permanece:
O que significa ser preferencial?
Talvez esse processamento conceda:
juros diferentes;
tarifa reduzida;
prioridade de pagamento;
limite especial;
tratamento tributário;
isenção;
relatórios distintos.
A tática cuida do IF.
A estratégia precisa justificar a regra.
4. Um exército pode vencer a batalha errada
Na história militar, existem inúmeros casos em que uma força venceu um confronto local, mas piorou sua situação geral.
Ela pode ter:
conquistado território sem valor;
utilizado recursos demais;
perdido tempo;
exposto uma rota importante;
abandonado uma posição melhor;
perseguido o inimigo até uma armadilha;
vencido sem capacidade de manter a conquista.
No desenvolvimento de sistemas, também é possível vencer a batalha errada.
Imagine que um programa esteja lento.
A equipe modifica o código e reduz o tempo de execução de quarenta para vinte minutos.
Vitória?
Talvez.
Mas, durante a otimização, o programa passa a manter locks por mais tempo em uma tabela crítica, prejudicando centenas de transações CICS.
O batch ficou mais rápido.
O sistema inteiro ficou pior.
A tática venceu.
A operação perdeu.
Outro exemplo:
Um desenvolvedor elimina uma validação considerada redundante.
O programa processa mais registros e reduz rejeições.
Entretanto, dados inconsistentes começam a chegar ao sistema contábil.
O relatório diário parece melhor.
A reconciliação mensal explode.
Mais uma vez, a batalha local foi vencida, mas a campanha sofreu uma derrota.
5. A estratégia pergunta “por quê?”
O pensamento tático normalmente começa com:
Como faço?
O pensamento estratégico começa com:
Por que fazemos?
Essa diferença é essencial para programadores iniciantes.
Quando alguém solicita uma alteração, não significa que o desenvolvedor deva contestar tudo ou transformar uma manutenção simples em investigação filosófica.
Significa apenas que precisa compreender o objetivo suficiente para não produzir uma solução tecnicamente correta e operacionalmente desastrosa.
Perguntas estratégicas úteis
Qual problema empresarial estamos resolvendo?
Quem será beneficiado?
Qual risco existe se nada for feito?
Existe prazo legal ou comercial?
A regra será permanente ou temporária?
Como saberemos que a mudança funcionou?
Qual resultado não pode ser afetado?
Essas perguntas ajudam a transformar uma especificação superficial em uma missão compreensível.
6. A operação conecta sistemas, equipes e horários
A estratégia pode determinar:
Todos os pagamentos devem estar disponíveis antes das seis da manhã.
Essa frase não diz como isso acontecerá.
A operação traduz a intenção em uma cadeia coordenada:
receber os movimentos;
validar arquivos;
consolidar transações;
consultar cadastros;
calcular valores;
atualizar contas;
gerar relatórios;
transmitir resultados;
reconciliar totais;
liberar os sistemas online.
Cada etapa pode envolver programas, jobs, bancos de dados, filas, equipes e janelas diferentes.
No mainframe, uma operação pode ser representada por uma cadeia batch composta por dezenas ou centenas de jobs.
Por exemplo:
RECEBE01
↓
VALIDA01
↓
ORDENA01
↓
CALCULA01
↓
ATUALIZA01
↓
RELATOR01
↓
ENVIA001
O programador responsável pelo CALCULA01 pode acreditar que sua responsabilidade termina quando o job retorna MAXCC=0000.
Mas isso não garante sucesso operacional.
Talvez o arquivo gerado esteja vazio.
Talvez os totais estejam incorretos.
Talvez o layout tenha mudado.
Talvez o job seguinte não reconheça a nova geração.
Talvez o processamento tenha terminado depois da janela.
Operação não é apenas executar.
É entregar o resultado necessário ao próximo participante da campanha.
7. MAXCC=0000 não significa vitória
Uma das armadilhas mais famosas do mundo batch é acreditar que MAXCC=0000 significa que tudo ocorreu corretamente.
Ele significa apenas que, segundo os critérios técnicos do job, nenhuma condição registrada elevou o código de retorno.
Um programa pode terminar com zero e ainda produzir:
arquivo vazio;
valor incorreto;
quantidade errada;
registros duplicados;
layout inválido;
totais inconsistentes;
resultado referente à data errada.
Imagine:
IF DATA-MOVIMENTO = DATA-PROCESSAMENTO
PERFORM PROCESSAR-REGISTRO
END-IF
Se DATA-PROCESSAMENTO estiver incorreta, nenhum registro será processado.
O programa chegará ao final sem ABEND.
Poderá retornar zero.
Tecnicamente, executou o que foi programado.
Operacionalmente, fracassou.
Por isso, sistemas maduros utilizam controles de negócio:
quantidade de entrada;
quantidade processada;
quantidade rejeitada;
totais financeiros;
data de referência;
arquivo de trailer;
reconciliação;
limites esperados.
Exemplo:
IF WS-QTD-PROCESSADA = ZERO
DISPLAY 'ERRO: NENHUM REGISTRO PROCESSADO'
MOVE 12 TO RETURN-CODE
END-IF
O código de retorno começa a representar a missão, não apenas a ausência de falhas técnicas.
8. Tática é escolher como fazer
No campo militar, a tática pode determinar:
posicionamento;
formação;
horário do ataque;
uso do terreno;
distribuição das unidades;
reação a uma ameaça imediata.
Na programação, a tática envolve escolhas como:
usar
IFouEVALUATE;utilizar busca sequencial ou binária;
ler arquivo ou consultar tabela;
ordenar antes de processar;
usar subprograma;
realizar commit por lote;
tratar erro imediatamente ou acumular rejeições.
Essas escolhas importam.
Mas precisam servir ao objetivo maior.
Exemplo: commit em lote
Imagine um programa que atualiza um milhão de registros no Db2.
Uma abordagem ingênua pode fazer commit apenas ao final.
PERFORM UNTIL FIM-DO-ARQUIVO = 'S'
PERFORM LER-REGISTRO
PERFORM ATUALIZAR-DB2
END-PERFORM
EXEC SQL
COMMIT
END-EXEC
Isso pode gerar:
locks prolongados;
consumo excessivo;
rollback enorme;
dificuldade de recuperação;
impacto em outros sistemas.
Uma tática melhor pode incluir commits periódicos:
ADD 1 TO WS-CONTADOR-COMMIT
IF WS-CONTADOR-COMMIT >= 1000
EXEC SQL
COMMIT
END-EXEC
MOVE ZERO TO WS-CONTADOR-COMMIT
END-IF
Mas até isso depende da estratégia e da operação.
É aceitável ter commits parciais?
O programa pode ser reiniciado?
Como evitar duplicidade?
Existe checkpoint?
A escolha tática precisa respeitar a arquitetura operacional.
9. Quando a tática contradiz a estratégia
Considere uma empresa cuja estratégia seja:
Garantir máxima rastreabilidade de operações financeiras.
Durante uma manutenção, um desenvolvedor decide remover logs para melhorar o desempenho.
Do ponto de vista tático, a decisão parece eficiente.
Menos I/O.
Menos dados gravados.
Job mais rápido.
Mas a decisão viola a estratégia de rastreabilidade.
Outro exemplo:
A estratégia determina alta disponibilidade.
Uma equipe realiza uma implantação que exige seis horas de indisponibilidade porque o procedimento técnico é mais simples.
A tática favorece a equipe.
A estratégia exigia proteger o serviço.
Outro caso:
A empresa deseja reduzir riscos de fraude.
Um sistema é alterado para aprovar automaticamente determinadas exceções e diminuir trabalho manual.
A operação fica mais rápida.
O controle estratégico enfraquece.
É possível produzir eficiência local e fragilidade global.
O bom engenheiro aprende a desconfiar de otimizações que beneficiam apenas um componente.
10. O mapa estratégico do programa COBOL
Antes de alterar um programa, tente construir um pequeno mapa.
Não precisa ser sofisticado.
Pode ser uma página com cinco áreas.
Missão
O que o programa entrega ao negócio?
Entradas
Quais dados recebe?
Processamento
Quais regras aplica?
Saídas
Quem consome o resultado?
Controles
Como verificamos se tudo funcionou?
Exemplo:
MISSÃO:
Calcular tarifas mensais dos clientes.
ENTRADAS:
Arquivo de contas.
Tabela de produtos.
Tabela de isenções.
PROCESSAMENTO:
Classificar cliente.
Determinar tarifa.
Aplicar descontos.
Registrar exceções.
SAÍDAS:
Atualização Db2.
Arquivo contábil.
Relatório de rejeições.
CONTROLES:
Quantidade recebida.
Quantidade tarifada.
Total financeiro.
Quantidade rejeitada.
Esse mapa ajuda a compreender onde uma pequena alteração pode produzir impacto.
Adicionar o código 47 talvez afete:
classificação;
cálculo;
contabilidade;
relatórios;
auditoria.
O IF está em uma linha.
A regra atravessa o sistema inteiro.
11. Shogun: a guerra travada antes da batalha
Em narrativas como Shogun, o conflito mais importante raramente se limita ao choque de exércitos.
A guerra acontece por meio de:
alianças;
casamentos;
religião;
comércio;
informação;
reputação;
reféns;
rotas marítimas;
cerimônias;
promessas.
Toranaga não avalia apenas quantos soldados possui.
Ele observa:
quem aparenta ser aliado;
quem depende de quem;
quem controla portos;
quem possui legitimidade;
quem teme perder posição;
quem pode mudar de lado.
Isso é estratégia.
Uma batalha pode ser apenas uma peça de uma campanha política maior.
No mainframe, também existem forças invisíveis.
Um sistema pode parecer tecnicamente independente, mas depender de:
calendário fiscal;
contrato com fornecedor;
exigência regulatória;
janela de parceiro externo;
equipe disponível;
licença;
autorização;
fluxo contábil.
O código é apenas o campo visível.
As verdadeiras alianças estão nas dependências.
12. Legend of the Galactic Heroes: vencer custa recursos
Legend of the Galactic Heroes é quase um tratado animado sobre estratégia, política, logística e liderança.
A obra mostra algo que muitas narrativas simplificam:
Toda vitória possui custo.
Uma frota pode vencer e ainda perder:
naves;
oficiais;
combustível;
tempo;
legitimidade;
apoio político;
capacidade futura.
No desenvolvimento, também precisamos calcular o custo da solução.
Uma mudança pode resolver o problema, mas aumentar:
complexidade;
dependência;
tempo de processamento;
manutenção;
consumo;
risco;
necessidade de suporte.
Uma solução tecnicamente brilhante pode gerar uma dívida operacional que permanecerá durante anos.
Por isso, a pergunta não é apenas:
Funciona?
Também precisamos perguntar:
Quanto custa manter funcionando?
13. Attack on Titan: informação muda a estratégia
Em Attack on Titan, muitos planos fracassam porque os personagens trabalham com informações incompletas ou incorretas.
Quando novas informações surgem, a interpretação do inimigo, da missão e até da própria sociedade muda.
Esse é um ponto essencial para sistemas.
Uma estratégia baseada em premissas erradas pode produzir operações perfeitamente organizadas e completamente inúteis.
Imagine uma solicitação:
Todos os clientes do código 47 devem receber isenção.
O desenvolvedor implementa corretamente.
Depois descobre que apenas clientes ativos antes de determinada data deveriam receber o benefício.
A primeira informação estava incompleta.
O código executou a ordem.
A missão foi mal definida.
Por isso, requisitos precisam conter:
público afetado;
condições;
exceções;
vigência;
exemplos;
resultados esperados;
critérios de aceitação.
O programador não precisa conhecer todo o universo empresarial.
Mas precisa reconhecer quando o mapa possui áreas em branco.
14. Goblin Slayer: tática rigorosa dentro de uma estratégia simples
Goblin Slayer possui uma estratégia muito clara:
Impedir que goblins continuem ameaçando pessoas.
As operações variam:
limpar cavernas;
proteger aldeias;
resgatar vítimas;
defender cidades;
eliminar ninhos.
As táticas mudam conforme o terreno:
fogo;
fumaça;
água;
armadilhas;
corredores estreitos;
trabalho em equipe;
bloqueio de rotas.
A força da personagem está em não confundir objetivo com método.
Ele não se apaixona por uma arma específica.
Usa o que funciona dentro das condições existentes.
Essa é uma excelente lição para tecnologia.
O bom programador não deve ser devoto de uma solução.
Não importa se prefere:
arquivo;
tabela;
API;
MQ;
programa interno;
serviço externo.
A ferramenta precisa servir à missão.
Quando a tecnologia vira religião, a estratégia desaparece.
15. O erro do herói overpower
Muitos sistemas são construídos ao redor de uma única pessoa extraordinária.
É o analista que conhece tudo.
O programador que resolve qualquer incidente.
O sysprog que sabe o comando secreto.
O operador que lembra a sequência correta.
Essa estrutura parece eficiente enquanto o herói está disponível.
Mas é estrategicamente frágil.
No anime, o personagem overpower resolve tudo sozinho.
Na produção, isso cria um ponto único de falha humano.
Uma estratégia madura exige:
documentação;
treinamento;
compartilhamento;
automação;
revisão;
procedimentos;
sucessão.
Se apenas uma pessoa sabe recuperar o sistema, não existe capacidade operacional.
Existe dependência pessoal.
O verdadeiro mestre não apenas vence.
Ele cria outros que também podem vencer.
16. Planejamento operacional de uma mudança
Vamos transformar a teoria em um roteiro prático.
Suponha que o código 47 precise ser incluído no processamento preferencial.
Fase 1 — Entender a estratégia
Pergunte:
Qual objetivo da mudança?
Qual regra empresarial está sendo aplicada?
Existe data de vigência?
Há impacto financeiro?
Quem aprovou?
Fase 2 — Mapear a operação
Identifique:
programas afetados;
jobs;
tabelas;
arquivos;
relatórios;
consumidores;
horários;
equipes.
Fase 3 — Definir a tática
Escolha:
forma de alterar a condição;
tratamento de exceções;
mensagens;
validações;
ajustes de teste.
Fase 4 — Preparar cenários
Teste pelo menos:
cliente tipo 10;
cliente tipo 47;
cliente padrão;
código inválido;
registro incompleto;
data antes da vigência;
data depois da vigência.
Fase 5 — Validar impactos
Confira:
valores calculados;
arquivos;
tabelas;
relatórios;
totais;
códigos de retorno.
Fase 6 — Preparar implantação
Defina:
load module;
bind;
promoção;
janela;
responsáveis;
rollback;
monitoramento.
Fase 7 — Verificar a missão
Após executar, não confira apenas o job.
Confirme se o resultado empresarial aconteceu.
17. O quadro de comando do programador
Antes de iniciar uma manutenção, o programador pode preencher uma tabela mental.
| Nível | Pergunta | Exemplo |
|---|---|---|
| Estratégia | Por que mudar? | Cumprir nova regra de isenção |
| Operação | Onde a regra circula? | Batch, Db2, contabilidade e relatório |
| Tática | Como alterar? | Incluir código 47 no EVALUATE |
| Controle | Como comprovar? | Totais, testes e reconciliação |
| Contingência | Como voltar? | Restaurar load anterior e reprocessar |
Essa estrutura evita que o desenvolvedor fique preso apenas à linha alterada.
18. Estratégia sem tática é discurso
Também existe o problema oposto.
Algumas organizações produzem grandes declarações estratégicas, mas não fornecem meios para executá-las.
Dizem:
precisamos modernizar;
precisamos inovar;
precisamos ser ágeis;
precisamos melhorar a qualidade;
precisamos reduzir riscos.
Mas não definem:
responsáveis;
recursos;
prazos;
prioridades;
métricas;
arquitetura;
treinamento.
Estratégia sem operação vira apresentação.
Operação sem tática vira confusão.
Tática sem estratégia vira movimento sem direção.
Os três níveis precisam estar conectados.
19. O programador COBOL como soldado ou estrategista?
O iniciante pode perguntar:
Preciso virar estrategista empresarial para alterar um programa?
Não.
Mas precisa desenvolver consciência de contexto.
No início, sua responsabilidade será principalmente tática:
corrigir;
testar;
documentar;
analisar;
implementar.
Com experiência, começará a enxergar a operação:
cadeias;
dependências;
janelas;
integrações;
riscos.
Mais tarde, poderá contribuir estrategicamente:
arquitetura;
modernização;
continuidade;
governança;
capacidade;
segurança.
A carreira técnica amadurece quando a pessoa deixa de enxergar apenas comandos e passa a compreender consequências.
20. Easter egg: o IF que protegia o império
Em um sistema antigo, existia uma condição curiosa:
IF CODIGO-OPERACAO = 88
MOVE 'N' TO IND-PROCESSAR
END-IF
Ninguém sabia por que o código 88 era ignorado.
Não havia comentário.
A documentação havia desaparecido.
Durante uma modernização, a condição foi removida.
Os testes comuns passaram.
Na produção, operações históricas começaram a ser processadas novamente.
O código 88 identificava registros enviados apenas para auditoria. Eles não deveriam gerar movimento financeiro.
O IF não era uma gambiarra.
Era uma fronteira entre informação e transação.
Alguém havia preservado a regra durante décadas, mas o significado se perdera.
Depois do incidente, o trecho foi reescrito:
IF CODIGO-OPERACAO = 88
MOVE 'N' TO IND-PROCESSAR
DISPLAY
'OPERACAO 88: REGISTRO SOMENTE PARA AUDITORIA'
END-IF
E recebeu um comentário:
* NÃO PROCESSAR FINANCEIRAMENTE.
* REGISTRO UTILIZADO PARA RASTREABILIDADE.
Uma única linha havia protegido o império.
O problema não era o código antigo.
Era a estratégia esquecida.
21. Curiosidade: o terreno pode ser mais forte que o exército
Ao longo da história, forças menores venceram adversários maiores porque utilizaram melhor:
montanhas;
rios;
estreitos;
clima;
distância;
fortificações.
O terreno altera a força real de cada unidade.
Em tecnologia, o “terreno” também importa.
O mesmo programa pode comportar-se de maneira diferente conforme:
volume;
ambiente;
configuração;
concorrência;
versão do compilador;
plano Db2;
disponibilidade de memória;
janela de execução.
Um teste com mil registros não representa necessariamente produção com cem milhões.
Uma consulta eficiente em desenvolvimento pode encontrar estatísticas diferentes em produção.
Uma rotina rápida isoladamente pode degradar quando centenas de jobs executam ao mesmo tempo.
Nunca avalie a tática ignorando o terreno.
22. Erros comuns do programador tático
Alterar somente o ponto indicado
A regra pode existir em outros módulos.
Testar apenas o caminho feliz
As exceções revelam a verdadeira qualidade.
Confiar apenas no MAXCC
O resultado de negócio pode estar errado.
Ignorar quem consome a saída
A alteração pode quebrar sistemas posteriores.
Otimizar sem medir impacto global
Ganhar tempo em um ponto pode aumentar contenção em outro.
Aceitar requisitos sem exemplos
Ambiguidades aparecem tarde demais.
Implantar sem rollback
Toda campanha precisa de rota de retirada.
23. Checklist de campanha
Antes de modificar uma regra, responda:
Qual é a missão empresarial?
Qual resultado precisa ser preservado?
A regra possui data de vigência?
Existem exceções?
Quais sistemas participam?
Quem produz as entradas?
Quem consome as saídas?
Qual é o volume?
Quais controles comprovam o resultado?
O código de retorno representa falhas de negócio?
Existe reconciliação?
O teste cobre caminhos alternativos?
Existe plano de rollback?
Quem decide interromper a implantação?
Quem precisa ser informado?
Quando essas respostas existem, a alteração deixa de ser um salto no escuro.
Torna-se uma operação planejada.
Conclusão — A ponte que não deveria ser recuperada
De volta ao castelo, o jovem general aguardava autorização para marchar.
Duzentos homens estavam preparados.
Arqueiros ajustavam cordas.
Cavalos batiam os cascos contra o chão.
O senhor feudal, porém, continuava olhando o mapa.
Finalmente, o engenheiro apontou para o norte.
— A ponte do leste não possui valor suficiente para justificar a força inimiga.
O conselheiro compreendeu primeiro.
— Eles querem que retiremos homens da estrada principal.
O senhor feudal assentiu.
A pequena ponte era uma distração.
Se o general marchasse, enfraqueceria a rota por onde chegariam os verdadeiros suprimentos.
O inimigo não pretendia manter a ponte.
Pretendia controlar a decisão do castelo.
O general baixou a cabeça.
Havia preparado uma excelente tática para cumprir a estratégia do adversário.
Na madrugada do data center, o jovem programador também interrompeu sua alteração.
Em vez de incluir imediatamente o código 47, procurou o analista de negócio.
Descobriu que a regra começaria apenas no mês seguinte.
Somente determinados contratos seriam afetados.
O relatório contábil precisava ser ajustado.
O programa de estorno também utilizava a mesma classificação.
A alteração não era um IF.
Era uma pequena campanha.
O programador desenhou o fluxo, listou dependências, preparou cenários e definiu controles.
Dias depois, a mudança entrou em produção.
Os jobs terminaram.
Os totais fecharam.
Os sistemas consumidores receberam os dados.
Nenhum cliente indevido recebeu o benefício.
O veterano aproximou-se com duas canecas.
— Qual foi a parte mais difícil?
O jovem respondeu:
— Não foi escrever a condição.
— Então o que foi?
— Descobrir qual guerra ela estava ajudando a vencer.
O veterano sorriu.
No terminal, o cursor piscava diante de uma nova solicitação.
Outra alteração pequena.
Outro território desconhecido.
O jovem respirou fundo e abriu o mapa antes de tocar no código.
Porque agora sabia:
A estratégia define a vitória.
A operação organiza o caminho.
A tática executa o movimento.
E um programador que enxerga apenas o IF pode vencer a batalha errada.
No alto da fortaleza, as bandeiras permaneceram imóveis.
A ponte do leste continuou nas mãos do inimigo.
Mas a rota principal estava protegida.
E, naquela manhã, não lutar havia sido a decisão mais poderosa de toda a campanha.
☕ 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.
Índice da campanha
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.
- Engenharia Militar sem Mistérios para Programadores COBOL
- Prólogo — O Chamado do Guardião
- Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar
- Capítulo II — Estratégia, Operação e Tática
- Capítulo III — A Cadeia de Comando
- Capítulo IV — Logística
- Capítulo V — As Muralhas Invisíveis
- Capítulo VI — Inteligência, Reconhecimento e Espionagem
- Capítulo VII — A Arte da Guerra Aplicada ao Mainframe
- Capítulo VIII — Liderança, Moral e Disciplina
- Capítulo IX — Inovação, Evolução e o Futuro
- Capítulo X — O Legado do Engenheiro
- Capítulo XI — O Guardião Invisível
- Capítulo XII — A Fortaleza Invisível
- Capítulo XIII — Os Sentinelas da Madrugada
- Capítulo XIV — A Civilização Invisível
- Capítulo XV — Engenharia de Cerco
- Glossário IBM Z + Engenharia Militar
- Apêndice A — Correspondências Históricas e Técnicas
- Os 10 Animes Mais Emblemáticos Sobre Engenharia Militar
- Os 10 Animes Mais Emblemáticos Sobre Logística Militar
- Os 10 Animes Mais Emblemáticos Sobre Tática Militar
- Os 10 Animes Mais Emblemáticos Sobre Estratégia Militar
- Especial — Guerrilha Urbana
- Especial — Guerrilha no Campo e na Floresta
