✨ 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

Mostrar mensagens com a etiqueta Tática Militar. Mostrar todas as mensagens

sexta-feira, 5 de agosto de 2016

Engenharia Militar : Os 10 Animes Mais Emblemáticos Sobre Tática Militar

Bellacosa Mainframe apresenta engenharia militar em 10 animes sobre tatica militar

☕ Um Café no Bellacosa Mainframe

Engenharia Militar : Os 10 Animes Mais Emblemáticos Sobre Tática Militar

Quando um Programador COBOL Descobre que uma Boa Decisão Tomada em Cinco Segundos Pode Valer Mais do que Mil Horas de Planejamento

Introdução

Estratégia responde à pergunta "o que conquistar?"

Logística responde "como manter a campanha funcionando?"

Já a tática responde à questão mais crítica de todas:

"O que fazer exatamente agora?"

É na tática que o comandante transforma um plano em ação. É o momento em que uma emboscada é preparada, uma colina é ocupada, um corredor é fechado, uma retirada é simulada ou uma pequena unidade derrota um inimigo muito maior por explorar melhor o terreno, o tempo e a informação disponível.

Curiosamente, esse conceito é extremamente familiar para qualquer profissional IBM Z.

Quando um incidente crítico acontece em produção, ninguém tem tempo para escrever um novo planejamento estratégico. O que salva o ambiente é a decisão tática: identificar rapidamente a causa, isolar o problema, redistribuir recursos, preservar os serviços essenciais e restaurar a operação antes que o impacto se espalhe.

Os melhores animes militares exploram exatamente essa dimensão. Eles mostram que uma vitória não nasce apenas do poder bruto, mas da leitura correta do campo de batalha, da adaptação constante e da inteligência aplicada sob pressão.

Pegue seu café.

Hoje vamos conhecer dez obras que ensinam tática militar com a mesma riqueza que um bom manual de operações de um Data Center.

1. Legend of the Galactic Heroes (銀河英雄伝説)

Lançamento: 1988–1997

Resumo

As batalhas espaciais são verdadeiras aulas de posicionamento, formação de frotas, reconhecimento e adaptação tática. Cada combate é diferente e exige respostas imediatas dos comandantes.

Personagens

Reinhard von Lohengramm
Yang Wen-li
Kircheis
Oberstein

Lição Tática

O melhor comandante adapta o plano à realidade do combate.

Analogia IBM Z

Yang Wen-li lembra um operador experiente que identifica rapidamente um gargalo e reorganiza toda a carga de trabalho antes que a indisponibilidade aconteça.

2. Kingdom

Lançamento: 2012

Resumo

Praticamente toda grande batalha da série apresenta formações, cercos, flanqueamentos, ataques de cavalaria e uso inteligente do terreno.

Personagens

Shin
Ei Sei
Ouki
Riboku
Kanki

Lição Tática

Conhecer o terreno vale mais do que possuir mais soldados.

Analogia IBM Z

Conhecer o comportamento do ambiente vale mais do que apenas aumentar CPU.

3. Alderamin on the Sky (Nejimaki Seirei Senki)

Lançamento: 2016

Resumo

Ikta Solork vence batalhas utilizando leitura do terreno, clima, moral das tropas e movimentação inteligente.

Personagens

Ikta Solork
Yatori
Matthew
Haroma

Lição Tática

Improvisar corretamente exige enorme preparação.

Analogia IBM Z

A melhor recuperação de um incidente parece improvisada apenas para quem não conhece o ambiente.

4. Goblin Slayer

Lançamento: 2018

Resumo

Cada missão é planejada como uma operação especial. Armadilhas, fogo, fumaça, gargalos naturais e controle do espaço são utilizados para compensar a inferioridade numérica.

Personagens

Goblin Slayer
Priestess
High Elf Archer
Dwarf Shaman
Lizard Priest

Lição Tática

Nunca lute nas condições escolhidas pelo inimigo.

Analogia IBM Z

Não permita que um incidente determine o ritmo da operação; controle o problema antes que ele controle você.

5. Saga of Tanya the Evil (Youjo Senki)

Lançamento: 2017

Resumo

Combates aéreos, reconhecimento e decisões rápidas transformam pequenas unidades em forças extremamente eficientes.

Personagens

Tanya Degurechaff
Viktoriya Serebryakov
Erich von Rerugen

Lição Tática

Velocidade de decisão é uma vantagem competitiva.

Analogia IBM Z

Incidentes críticos exigem respostas em minutos, não em horas.

6. Attack on Titan (Shingeki no Kyojin)

Lançamento: 2013

Resumo

As batalhas contra os Titãs envolvem uso tridimensional do terreno, coordenação entre equipes e exploração de pontos fracos.

Personagens

Eren Yeager
Mikasa Ackerman
Armin Arlert
Levi Ackerman
Erwin Smith

Lição Tática

Conhecer a vulnerabilidade do adversário muda completamente o combate.

Analogia IBM Z

Uma única consulta SQL mal otimizada pode ser o verdadeiro "Titã" responsável pelo colapso de todo o ambiente.

7. Gate: Jieitai Kanochi nite, Kaku Tatakaeri

Lançamento: 2015

Resumo

O contraste entre tecnologia moderna e guerra medieval evidencia o uso inteligente de pequenas unidades, reconhecimento e apoio coordenado.

Personagens

Youji Itami
Rory Mercury
Lelei
Tuka
Pina Co Lada

Lição Tática

Superioridade tecnológica só produz resultados quando utilizada corretamente.

Analogia IBM Z

Ferramentas modernas não substituem operadores experientes.

8. Code Geass

Lançamento: 2006

Resumo

Embora seja um anime de ficção científica, cada confronto é construído em torno de emboscadas, distrações, inteligência e manipulação do campo de batalha.

Personagens

Lelouch Lamperouge
Suzaku Kururugi
C.C.
Kallen Stadtfeld

Lição Tática

Enganar o adversário pode ser mais eficiente do que enfrentá-lo diretamente.

Analogia IBM Z

Redirecionar carga de trabalho durante uma manutenção evita indisponibilidades sem interromper o serviço.

9. Arslan Senki (The Heroic Legend of Arslan)

Lançamento: 2015

Resumo

A série apresenta inúmeras decisões tomadas em campo envolvendo formações, recuos estratégicos, exploração do terreno e coordenação entre comandantes.

Personagens

Arslan
Daryun
Narsus
Elam

Lição Tática

Flexibilidade supera rigidez.

Analogia IBM Z

Ambientes resilientes são aqueles capazes de se adaptar rapidamente às mudanças.

10. Vinland Saga

Lançamento: 2019

Resumo

Os confrontos mostram emboscadas, guerra psicológica, reconhecimento e uso inteligente do ambiente natural.

Personagens

Thorfinn
Askeladd
Canute
Thorkell

Lição Tática

O comandante precisa compreender tanto o inimigo quanto seus próprios homens.

Analogia IBM Z

Conhecer as limitações da equipe e da infraestrutura evita decisões desastrosas.

Menções Honrosas

Shoukoku no Altair
Valkyria Chronicles
Mobile Suit Gundam (Universal Century)
Mobile Suit Gundam: The 08th MS Team
Drifters
Crest of the Stars
Record of Grancrest War
Pumpkin Scissors
The Twelve Kingdoms
Mobile Suit Gundam: Iron-Blooded Orphans

As Dez Grandes Lições da Tática Militar

Esses animes mostram princípios que também orientam operações críticas em ambientes IBM Z:

1. A informação vale mais do que a força.

2. O terreno sempre influencia o resultado.

3. Adaptar-se rapidamente é essencial.

4. Coordenação supera heroísmo individual.

5. Surpresa é um multiplicador de força.

6. Conheça seus limites antes de atacar.

7. Nunca desperdice recursos em batalhas desnecessárias.

8. O tempo pode ser uma arma decisiva.

9. Toda decisão possui consequências em cadeia.

10. A melhor vitória é aquela obtida com o menor custo possível.

O Paralelo com COBOL e IBM Z

Quando um incidente ocorre em produção, a equipe não dispõe de horas para elaborar uma nova estratégia corporativa. É preciso agir imediatamente.

Isolar aplicações.

Cancelar Jobs.

Redistribuir cargas.

Ativar ambientes alternativos.

Liberar espaço em discos.

Reduzir consumo de CPU.

Priorizar transações críticas.

Cada uma dessas ações corresponde a uma decisão tática. O objetivo é estabilizar o ambiente e ganhar tempo para que o planejamento estratégico e a logística retomem seu papel.

Assim como nos animes apresentados, a excelência operacional nasce da combinação entre conhecimento técnico, experiência prática e capacidade de adaptação.

Curiosidade Histórica

O tratado A Arte da Guerra, de Sun Tzu, distingue claramente estratégia e tática. Estratégia define a campanha; tática define como cada batalha será conduzida. Diversos generais da Antiguidade afirmavam que uma boa estratégia podia fracassar por causa de uma execução tática ruim, enquanto uma excelente tática dificilmente conseguiria salvar uma estratégia completamente equivocada.

Nos Data Centers ocorre algo semelhante. Uma arquitetura bem projetada pode ser comprometida por decisões operacionais inadequadas durante um incidente. Da mesma forma, uma equipe altamente treinada consegue muitas vezes minimizar os efeitos de uma arquitetura imperfeita graças à qualidade de suas decisões táticas.

Easter Egg

Conta-se que um comandante perguntou ao seu melhor capitão:

— Qual é a formação perfeita para vencer qualquer batalha?

O capitão respondeu:

— A que muda antes que o inimigo perceba.

Muitos anos depois...

um gerente perguntou ao especialista IBM Z:

— Qual é o melhor procedimento para resolver um incidente?

O veterano respondeu:

— Aquele que se adapta ao incidente antes que ele derrube o restante do ambiente.

Porque nenhuma batalha é igual à anterior.

E nenhum ABEND escolhe o melhor momento para acontecer.

Conclusão

Ao observar esses dez animes sob a ótica da engenharia, percebemos que a tática não é apenas uma sequência de movimentos inteligentes em um campo de batalha.

Ela representa a capacidade humana de tomar decisões corretas quando o tempo é escasso, os recursos são limitados e as consequências de um erro podem ser enormes.

Essa habilidade também define os grandes profissionais de Mainframe.

Todos os dias, operadores, desenvolvedores COBOL, Sysprogs, DBAs e arquitetos enfrentam pequenas batalhas invisíveis. Um gargalo inesperado, uma fila congestionada, um Job atrasado ou uma falha de armazenamento exigem respostas rápidas e coordenadas.

Os usuários enxergam apenas que o sistema continuou funcionando.

Assim como um reino via apenas a vitória no campo de batalha.

Mas, por trás desse sucesso, existiu alguém que leu corretamente o cenário, escolheu a melhor formação e tomou a decisão certa no momento exato.

Porque, seja em um castelo medieval, em uma frota espacial ou em um Data Center IBM Z, a vitória pertence àqueles que dominam a arte da tática.

☕ 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.

Consultar arquivo

25 documentos

2014–2016 linha histórica

IBM Z fortaleza digital

COBOL linguagem da missão

Arquivo estratégico

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

25 documentos localizados

Pesquisar no arquivo Categoria Ordenação

Í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.

Engenharia Militar — Índice da campanha

O JavaScript está desativado. Utilize o índice permanente de links exibido nesta página para acessar os artigos.

terça-feira, 6 de janeiro de 2015

Engenharia Militar : Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar

Bellacosa Mainframe e a engenharia militar parte I

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar

Quando um Programador Descobre que a Guerra Não é Vencida pela Espada, mas por Quem Constrói a Estrada, Protege os Suprimentos e Mantém o Sistema Funcionando

A chuva caía sobre os telhados do castelo como milhões de pequenos registros sendo gravados em um arquivo sequencial.

No alto da torre, sentinelas observavam o vale encoberto pela neblina. Abaixo delas, dezenas de homens reforçavam portões, transportavam madeira, verificavam cordas, enchiam depósitos de água e reparavam uma ponte que atravessava o rio.

Ao longe, nenhuma tropa inimiga podia ser vista.

Nenhuma bandeira tremulava no horizonte.

Nenhum tambor anunciava batalha.

Ainda assim, todos trabalhavam como se a guerra já tivesse começado.

Dentro da fortaleza, o senhor feudal estudava mapas à luz de uma lamparina. Ao seu lado estavam generais, conselheiros, mensageiros e um homem que não carregava espada.

Vestia roupas simples, tinha as mãos marcadas pelo trabalho e examinava cuidadosamente uma pequena maquete de madeira.

Era o engenheiro.

O general mais jovem, impaciente, perguntou:

— Por que perdemos tempo fortalecendo pontes? Precisamos de mais guerreiros.

O engenheiro não respondeu imediatamente.

Pegou uma pequena peça que representava uma carroça de suprimentos e a colocou sobre a ponte da maquete.

— Quantos dias seus homens conseguem lutar sem arroz?

O general permaneceu em silêncio.

— Quantas flechas seus arqueiros podem disparar sem madeira? Quantos feridos sobreviverão sem água? Quantos mensageiros chegarão ao castelo se o rio transbordar?

O senhor feudal ergueu os olhos.

— Uma espada vence um duelo — disse ele. — Mas uma estrada pode decidir uma guerra.

Séculos depois, em uma sala de operações iluminada por monitores, um jovem programador COBOL cometeria exatamente o mesmo erro daquele general.

Ele acreditaria que um sistema era apenas código.

E descobriria, da pior maneira possível, que programas também precisam de estradas, pontes, suprimentos, muralhas, mensageiros e planos de retirada.

Bem-vindo ao primeiro capítulo de nossa campanha.

Prepare o café.

Confira o MAXCC.

E não atravesse a ponte antes de verificar quem a construiu.

1. O que realmente significa engenharia militar?

Quando alguém escuta a expressão “engenharia militar”, normalmente imagina soldados construindo pontes improvisadas, abrindo caminhos em florestas, explodindo obstáculos ou levantando fortificações.

Tudo isso faz parte da engenharia militar.

Mas a ideia é muito maior.

Engenharia militar é o uso organizado de conhecimentos técnicos para criar as condições necessárias para uma operação.

Ela procura responder perguntas fundamentais:

Como uma força chegará ao seu destino?
Como atravessará rios, montanhas e áreas destruídas?
Como se protegerá?
Como receberá alimentos, água, energia e equipamentos?
Como manterá comunicação?
Como poderá avançar?
Como poderá recuar?
Como continuará funcionando quando algo falhar?

Observe uma diferença importante.

O guerreiro executa a missão.

O engenheiro cria as condições para que a missão possa ser executada.

Um exército pode possuir soldados valentes, excelentes armas e um comandante brilhante. Mas, se não houver estrada, alimentação, abrigo, comunicação e reposição, aquela força terá pouca utilidade.

A engenharia militar cuida da realidade que existe atrás da imagem heroica.

Os filmes mostram a carga de cavalaria.

O engenheiro pensa na ração dos cavalos.

Os animes mostram o golpe decisivo.

O engenheiro pergunta como o personagem chegou vivo até aquela batalha.

As empresas mostram uma transação concluída em segundos.

O profissional de mainframe pensa em CPU, memória, banco de dados, segurança, filas, arquivos, redes, jobs e recuperação.

A vitória é visível.

A infraestrutura que permitiu a vitória quase nunca é.

2. O programador que acreditava que tudo era código

Imagine uma instituição financeira que precisa calcular o rendimento de milhões de contas durante a madrugada.

O programa COBOL recebe um arquivo de entrada, consulta tabelas Db2, calcula valores, atualiza registros e gera arquivos para outros sistemas.

O código foi cuidadosamente alterado.

Os testes unitários passaram.

A compilação terminou com sucesso.

O bind foi realizado.

O novo load module foi promovido.

Tudo parecia perfeito.

Às 2h13 da madrugada, o job entrou em execução.

Às 2h14, terminou com erro.

O programador foi chamado.

Ele abriu o programa, revisou os parágrafos e examinou as condições.

Nenhum problema.

Depois olhou o JCL.

O arquivo de entrada estava vazio.

O sistema anterior, responsável por gerar aquele arquivo, havia terminado com erro devido à falta de espaço em disco.

O programa COBOL estava correto.

Mas a operação estava derrotada.

Esse é o primeiro princípio da engenharia militar aplicada à tecnologia:

Um componente correto pode participar de um sistema fracassado.

O jovem programador havia pensado como um duelista.

Precisava aprender a pensar como um engenheiro de campanha.

3. O campo de batalha chamado produção

O ambiente de produção não é literalmente uma guerra.

Entretanto, a comparação ajuda a compreender sua complexidade.

Em produção, existem:

recursos limitados;
riscos;
dependências;
prazos;
cadeias de decisão;
responsabilidades;
contingências;
informações incompletas;
consequências reais.

Uma falha pode interromper pagamentos, bloquear transações, atrasar entregas, prejudicar clientes ou gerar perdas financeiras.

Por isso, ambientes críticos não podem depender apenas da habilidade individual.

Eles precisam de organização.

No mundo COBOL e mainframe, essa organização aparece em várias camadas.

O programa COBOL

Representa a unidade que executa uma tarefa específica.

O JCL

Representa o plano operacional.

Define quais recursos serão utilizados, qual sequência deverá ser seguida e como cada etapa será executada.

O JES

Organiza a movimentação dos jobs.

É como uma autoridade responsável por receber, ordenar e despachar as operações.

O WLM

Distribui recursos conforme prioridades e objetivos definidos.

É o comandante que precisa decidir quais unidades receberão atenção primeiro.

O RACF

Controla acessos e protege os portões.

Determina quem pode entrar, o que pode acessar e quais ações pode executar.

O Db2

Armazena informações vitais.

É simultaneamente arquivo imperial, tesouro, registro histórico e centro administrativo.

O CICS

Atende solicitações em tempo quase imediato.

É a cidade comercial dentro da fortaleza, onde milhares de transações acontecem continuamente.

O MQ

Transporta mensagens entre sistemas.

Funciona como uma rede de mensageiros que precisa garantir que a informação chegue ao destino correto.

O storage

Armazena dados, versões, históricos e cópias.

É o conjunto de depósitos, arsenais, arquivos e reservas da fortaleza.

O programador iniciante costuma enxergar apenas seu programa.

O engenheiro enxerga a campanha inteira.

4. Mobilidade: como chegar até o objetivo?

Uma das principais funções da engenharia militar é permitir movimento.

Isso inclui:

construir pontes;
abrir estradas;
remover obstáculos;
preparar travessias;
criar rotas alternativas;
reparar caminhos destruídos.

No mainframe, mobilidade significa permitir que os dados se movam.

Os dados precisam atravessar:

arquivos;
filas;
tabelas;
redes;
APIs;
programas;
subsistemas;
plataformas.

Uma empresa pode possuir informações excelentes, mas elas não possuem valor se não conseguem chegar ao lugar certo no momento certo.

Imagine um arquivo COBOL produzido com o seguinte layout:

       01  REGISTRO-CLIENTE.
           05  CODIGO-CLIENTE      PIC 9(10).
           05  NOME-CLIENTE        PIC X(40).
           05  SALDO-CLIENTE       PIC S9(11)V99 COMP-3.

Outro sistema precisa consumir esse arquivo.

À primeira vista, parece simples.

Mas surgem várias perguntas:

Qual é o tamanho total do registro?
O arquivo é FB ou VB?
Qual é o LRECL?
A codificação é EBCDIC ou ASCII?
O campo compactado será compreendido pelo consumidor?
Existe cabeçalho?
Existe trailer?
Como o consumidor detecta duplicidade?
Como confirma que o arquivo está completo?
Como ocorre o reprocessamento?
O nome do dataset muda diariamente?
Há uma geração GDG?
O arquivo é criptografado?
Quem possui autorização de leitura?

Essas perguntas pertencem à engenharia da ponte.

O código apenas produz registros.

A integração garante que eles atravessem o rio.

5. Contramobilidade: impedir que o adversário avance

A engenharia militar não serve apenas para facilitar o movimento das próprias forças.

Também pode dificultar o movimento adversário.

Isso é feito por meio de:

fossos;
barreiras;
destruição controlada de pontes;
obstáculos;
campos defensivos;
rotas bloqueadas;
fortificações.

Na tecnologia, essa função corresponde à segurança.

Não basta permitir que usuários autorizados utilizem o sistema.

Também é necessário impedir ações indevidas.

O RACF, por exemplo, não é apenas um cadastro de usuários.

Ele representa uma política de acesso.

Pode determinar:

quem pode ler um dataset;
quem pode alterá-lo;
quem pode executar determinado recurso;
quais grupos possuem acesso;
quando uma tentativa deve ser registrada;
quais privilégios precisam ser separados.

Um ambiente sem controles é como uma fortaleza cujos portões permanecem abertos porque os moradores consideram inconveniente usar chaves.

A segurança cria obstáculos.

Mas esses obstáculos precisam ser inteligentes.

Uma proteção mal planejada pode impedir o próprio trabalho.

Uma proteção fraca pode facilitar uma invasão.

O verdadeiro desafio está no equilíbrio.

6. Fortificação: sobreviver ao impacto

Fortificações existem porque nenhum território pode presumir que jamais será atacado.

Castelos, muralhas e bunkers são construídos com uma ideia fundamental:

O impacto acontecerá. Precisamos continuar funcionando depois dele.

Esse princípio também deve orientar sistemas críticos.

Não é realista imaginar que nunca ocorrerão:

erros humanos;
falhas de hardware;
arquivos corrompidos;
indisponibilidade de rede;
problemas de software;
credenciais expiradas;
ataques;
interrupções;
volumes inesperados;
dados inválidos.

Por isso, sistemas precisam de mecanismos de resistência.

No COBOL, alguns exemplos são:

       READ ARQUIVO-CLIENTES
           AT END
               MOVE 'S' TO FIM-DO-ARQUIVO
           NOT AT END
               PERFORM PROCESSAR-CLIENTE
       END-READ

O tratamento de fim de arquivo é uma proteção simples.

Mas também existem situações mais críticas:

       IF WS-FILE-STATUS NOT = '00'
           DISPLAY 'ERRO NO ARQUIVO CLIENTES: '
                   WS-FILE-STATUS
           MOVE 12 TO RETURN-CODE
           PERFORM ENCERRAR-PROCESSAMENTO
       END-IF

O FILE STATUS é uma sentinela.

Ele informa se o portão abriu corretamente.

No Db2, o SQLCODE exerce função semelhante.

       EXEC SQL
           UPDATE CONTA
              SET SALDO = :WS-NOVO-SALDO
            WHERE NUMERO_CONTA = :WS-CONTA
       END-EXEC

       EVALUATE SQLCODE
           WHEN 0
               CONTINUE
           WHEN 100
               PERFORM TRATAR-CONTA-NAO-ENCONTRADA
           WHEN OTHER
               PERFORM TRATAR-ERRO-SQL
       END-EVALUATE

Ignorar o SQLCODE equivale a enviar tropas para uma ponte sem confirmar se ela ainda existe.

7. A engenharia da logística

Esta talvez seja a parte menos glamorosa e mais decisiva de qualquer campanha.

Logística é o processo de disponibilizar recursos no lugar certo e na hora certa.

Em uma operação militar, envolve:

comida;
água;
munição;
roupas;
combustível;
transporte;
ferramentas;
medicamentos;
peças de reposição.

Em um ambiente mainframe, envolve:

CPU;
memória;
storage;
espaço temporário;
arquivos;
conexões;
filas;
tempo de janela;
disponibilidade de subsistemas;
equipes de suporte.

Considere um programa de ordenação.

O programador pode escrever:

       SORT ARQUIVO-SORT
           ON ASCENDING KEY CHAVE-CLIENTE
           USING ARQUIVO-ENTRADA
           GIVING ARQUIVO-SAIDA

A instrução parece pequena.

Mas, nos bastidores, talvez precise processar milhões de registros.

Então a operação exige:

espaço temporário;
memória;
tempo;
dispositivos;
estimativas de volume;
parâmetros adequados;
capacidade de reinício.

O comando é simples.

A logística é complexa.

É por isso que sistemas críticos não podem ser avaliados apenas pela elegância do código.

Um algoritmo maravilhoso que ultrapassa a janela batch pode ser operacionalmente inútil.

Um programa rápido que consome recursos excessivos pode prejudicar outros serviços.

Um job que funciona com dez mil registros pode falhar com cem milhões.

Engenharia significa avaliar escala.

8. JCL: o mapa de campanha

O JCL costuma assustar iniciantes.

Ele parece antigo, cheio de parâmetros, símbolos e regras peculiares.

Mas, quando compreendido como um plano operacional, começa a fazer sentido.

Observe:

//CALC001  JOB (ACCT),'CALCULO',CLASS=A,MSGCLASS=X
//STEP010  EXEC PGM=CALCREND
//STEPLIB  DD  DSN=EMPRESA.LOADLIB,DISP=SHR
//ENTRADA  DD  DSN=EMPRESA.CLIENTES.DIARIO,DISP=SHR
//SAIDA    DD  DSN=EMPRESA.RESULTADO(+1),
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(CYL,(100,20)),
//             DCB=(RECFM=FB,LRECL=120,BLKSIZE=0)
//SYSOUT   DD  SYSOUT=*

Esse JCL responde várias perguntas.

Qual programa será executado?

//STEP010 EXEC PGM=CALCREND

Onde está o módulo?

//STEPLIB DD DSN=EMPRESA.LOADLIB,DISP=SHR

Qual é o arquivo de entrada?

//ENTRADA DD DSN=EMPRESA.CLIENTES.DIARIO,DISP=SHR

Onde será produzido o resultado?

//SAIDA DD DSN=EMPRESA.RESULTADO(+1)

Quanto espaço será reservado?

// SPACE=(CYL,(100,20))

O que acontecerá se o step falhar?

// DISP=(NEW,CATLG,DELETE)

O JCL é o mapa de campanha.

O COBOL descreve o que a unidade fará.

O JCL define como ela será enviada ao campo.

9. Comunicação: ordens que precisam ser compreendidas

Em guerras antigas, uma mensagem mal transmitida podia destruir um exército.

Uma ordem atrasada, ambígua ou entregue ao comandante errado poderia alterar completamente uma batalha.

Nos sistemas, mensagens e logs também precisam ser claros.

Considere:

ERRO 102

Essa mensagem possui pouco valor operacional.

Agora compare:

ERRO 102 - ARQUIVO DE MOVIMENTOS NÃO DISPONÍVEL
DATA ESPERADA: 20260725
JOB PRODUTOR: MOVGER01
AÇÃO RECOMENDADA: VALIDAR STEP020 E REINICIAR A PARTIR DO STEP030

A segunda mensagem funciona como uma ordem útil.

Ela informa:

o problema;
o contexto;
a dependência;
a ação sugerida.

Em produção, clareza reduz tempo de recuperação.

Mensagens precisam ser escritas para seres humanos sob pressão.

Esse é um detalhe frequentemente ignorado.

O programador escreve o erro pensando no momento do desenvolvimento.

Mas quem verá aquela mensagem poderá ser um operador às três da madrugada, durante um incidente, sem conhecer o programa.

Uma boa mensagem deve funcionar como um mensageiro treinado.

10. Reconhecimento: estudar antes de atacar

Nenhum comandante responsável avança sem conhecer o terreno.

Antes de uma operação, procura informações sobre:

distância;
rios;
estradas;
elevações;
obstáculos;
forças adversárias;
clima;
população;
rotas de retirada.

No desenvolvimento, reconhecimento significa análise de impacto.

Antes de alterar um programa COBOL, o iniciante deve investigar.

Passo 1 — Descubra como o programa é chamado

É executado por JCL?

É chamado por outro programa?

É uma transação CICS?

É acionado por uma mensagem?

Passo 2 — Mapeie entradas e saídas

Quais arquivos são lidos?

Quais arquivos são gerados?

Quais tabelas são consultadas ou atualizadas?

Passo 3 — Localize dependências

Existem copybooks?

Subprogramas?

Stored procedures?

Filas MQ?

Passo 4 — Verifique consumidores

Quem utiliza o resultado?

Outro job?

Uma API?

Um relatório?

Uma equipe externa?

Passo 5 — Analise volumes

Quantos registros?

Qual crescimento esperado?

Qual tempo atual?

Passo 6 — Procure regras escondidas

Comentários antigos.

Condições especiais.

Datas críticas.

Exceções históricas.

Passo 7 — Consulte veteranos

Documentação ajuda.

Mas, em ambientes antigos, parte do mapa pode existir apenas na memória de quem já percorreu o terreno.

Modificar antes de investigar é entrar na floresta acreditando que todas as sombras são árvores.

11. Animes como manuais invisíveis de organização

A relação entre animes e engenharia militar não está apenas em obras sobre guerra.

Ela aparece na forma como os personagens são organizados e treinados.

Em muitas histórias japonesas, existe:

uma instituição;
uma hierarquia;
um mestre;
uma equipe;
um período de treinamento;
regras;
testes;
falhas;
amadurecimento;
responsabilidade coletiva.

Em Attack on Titan, a formação é explicitamente militar.

Os personagens aprendem combate, disciplina, formação, comando e sacrifício.

Em Kingdom, vemos estratégia, logística, terreno, moral e comando.

Em Legend of the Galactic Heroes, a guerra é tratada como política, administração, liderança e economia.

Em Goblin Slayer, o combate é engenharia operacional.

O protagonista avalia:

entradas;
saídas;
quantidade de inimigos;
terreno;
ventilação;
suprimentos;
possibilidades de fuga;
armas disponíveis.

Ele não pergunta apenas:

— Consigo vencer?

Pergunta:

— Como impedir que o problema retorne?

Esse é pensamento sistêmico.

E pensamento sistêmico é essencial para programadores.

12. Um Estado poderia utilizar animes e mangás para educar?

Sim.

Narrativas visuais são instrumentos poderosos de educação.

Elas podem ensinar:

primeiros socorros;
prevenção de incêndios;
defesa civil;
segurança no trânsito;
educação financeira;
preparação para enchentes;
comportamento em terremotos;
segurança digital;
saúde pública;
cidadania.

A grande vantagem está na identificação emocional.

Uma lista de instruções pode ser esquecida.

Uma história pode permanecer durante décadas.

Quando uma personagem admirada toma uma decisão correta e salva outras pessoas, o público não recebe apenas informação.

Recebe um modelo de comportamento.

Esse mecanismo pode ser positivo.

Mas também pode ser perigoso.

A mesma ferramenta que ensina cooperação pode ensinar submissão.

A mesma narrativa que estimula coragem pode glorificar sacrifícios inúteis.

A mesma obra que valoriza disciplina pode tentar eliminar questionamentos.

Por isso, precisamos separar educação de propaganda.

Educação

Apresenta conhecimento, contexto e possibilidades.

Propaganda

Busca produzir adesão emocional a uma causa.

Doutrinação

Procura impedir o pensamento alternativo.

A pergunta essencial é:

A obra ensina o cidadão a pensar ou apenas a obedecer?

Muitos animes interessantes fazem exatamente o contrário da propaganda simplista.

Eles mostram:

autoridades que erram;
líderes que manipulam;
instituições corrompidas;
ordens imorais;
conflitos entre dever e consciência;
consequências do militarismo.

Disciplina e pensamento crítico não precisam ser inimigos.

A melhor formação ensina quando obedecer, por que obedecer e quando uma ordem precisa ser questionada.

13. Shogun e a engenharia do poder invisível

Em uma narrativa no estilo de Shogun, a guerra raramente acontece apenas no campo de batalha.

Ela ocorre:

em conversas;
em casamentos;
em alianças;
em cerimônias;
em decisões comerciais;
no controle de portos;
na circulação de informação;
na interpretação de gestos.

Uma fortaleza pode cair sem ser atacada.

Basta cortar seus suprimentos.

Um senhor pode perder poder sem perder soldados.

Basta perder aliados.

Uma frota pode ser inutilizada sem combate.

Basta impedir o acesso ao porto.

Isso também acontece nos sistemas.

Uma aplicação pode parar mesmo com seu código intacto.

Basta:

revogar uma credencial;
bloquear uma porta de rede;
atrasar um arquivo;
indisponibilizar uma tabela;
encher uma fila;
remover espaço;
alterar uma autorização.

O poder real está nas dependências.

Quem controla as dependências controla a operação.

Esse é um dos maiores ensinamentos da engenharia militar e da arquitetura de sistemas.

14. O passo a passo do engenheiro COBOL

Antes de realizar uma alteração, siga este pequeno ritual de campanha.

1. Defina a missão

O que precisa mudar?

Qual problema empresarial será resolvido?

2. Conheça o terreno

Onde o programa executa?

Batch, CICS, IMS ou outro ambiente?

3. Identifique as unidades envolvidas

Quais programas, arquivos, tabelas e filas participam?

4. Verifique os suprimentos

Existe espaço, tempo, capacidade e disponibilidade?

5. Proteja as fronteiras

Quais acessos e autorizações são necessários?

6. Teste as pontes

As interfaces funcionam corretamente?

7. Prepare comunicação

As mensagens de erro são claras?

Os logs permitem investigação?

8. Defina contingência

Como interromper?

Como reiniciar?

Como reverter?

9. Execute testes realistas

Utilize volumes e cenários próximos da produção.

10. Reúna evidências

Guarde resultados, relatórios, logs e comparações.

Esse processo parece mais lento que simplesmente alterar o código.

Na verdade, ele é muito mais rápido que corrigir um desastre em produção.

15. Easter egg: o programador que removeu a ponte

Em uma instalação antiga, havia um campo aparentemente inútil no final de um copybook.

       05  FILLER                  PIC X(08).

O campo não era utilizado por nenhum programa conhecido.

Um desenvolvedor decidiu removê-lo para “otimizar o layout”.

A compilação passou.

Os testes locais passaram.

O programa produziu registros menores.

Na madrugada seguinte, um sistema externo começou a interpretar os campos usando posições fixas.

Datas foram lidas como valores.

Valores foram lidos como códigos.

Códigos foram lidos como espaços.

O problema não estava no programa alterado.

Estava na ponte que conectava dois sistemas.

O FILLER aparentemente inútil era parte do contrato de integração.

O novo programador havia removido oito bytes.

Na prática, havia desmontado uma ponte enquanto a caravana ainda atravessava.

Desde então, um comentário passou a aparecer em vários copybooks daquela instalação:

      * ANTES DE REMOVER UMA PEDRA,
      * DESCUBRA QUAL MURALHA ELA SUSTENTA.

Talvez seja apenas uma lenda de data center.

Mas toda lenda antiga costuma proteger alguma verdade.

16. Checklist de campo

Antes de considerar seu programa pronto, pergunte:

Entendi a missão empresarial?
Conheço o ambiente de execução?
Identifiquei entradas e saídas?
Mapeei todas as dependências?
Conheço os consumidores dos dados?
Verifiquei volume e capacidade?
Tratei FILE STATUS e SQLCODE?
Preparei mensagens claras?
Existe procedimento de reinício?
Existe rollback?
As autorizações foram verificadas?
Os testes representam situações reais?
Os resultados podem ser comprovados?
Alguém além de mim entende a operação?

Se alguma resposta for “não”, talvez o código esteja pronto.

Mas a campanha ainda não está.

Conclusão — O homem sem espada

De volta ao castelo, o jovem general observava os trabalhadores terminando a ponte.

Durante a noite, a chuva havia aumentado.

O rio estava mais forte.

Ao amanhecer, mensageiros chegaram com notícias: uma força inimiga avançava pela estrada do norte.

O general colocou a mão na espada.

— Finalmente.

O engenheiro, porém, olhou para o rio.

As carroças começaram a atravessar a ponte levando alimentos, flechas, ferramentas e medicamentos para as unidades posicionadas no vale.

Sem aquela estrutura, os soldados ficariam isolados.

Sem os suprimentos, não resistiriam.

Sem mensageiros, não receberiam ordens.

Sem rota de retirada, poderiam ser cercados.

O general compreendeu.

A batalha ainda seria travada por guerreiros.

Mas a possibilidade de vitória havia sido construída por homens que não apareceriam nas canções.

Séculos depois, o jovem programador COBOL observou seu job executar novamente.

O arquivo de entrada fora corrigido.

O espaço de storage havia sido ampliado.

As permissões estavam ajustadas.

A dependência anterior havia terminado.

O processamento avançou.

Milhões de registros foram lidos.

Tabelas foram atualizadas.

Arquivos foram gerados.

O job terminou com:

MAXCC=0000

O veterano levantou sua caneca.

— Agora você entende?

O jovem assentiu.

— O programa não é o sistema.

— Exatamente.

— E o programador não é apenas alguém que escreve código.

O veterano sorriu.

— Quando aprende a enxergar estradas, muralhas, suprimentos e rotas de retirada, ele se torna engenheiro.

Do lado de fora da sala de operações, a empresa continuava funcionando sem saber que, durante a madrugada, uma pequena batalha havia sido vencida.

Não por uma espada.

Não por uma linha de código isolada.

Mas por uma ponte que permaneceu de pé.

E, em algum lugar da fortaleza, o homem sem espada já examinava o próximo mapa.

☕ 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.

Consultar arquivo

25 documentos

2014–2016 linha histórica

IBM Z fortaleza digital

COBOL linguagem da missão

Arquivo estratégico

Um Data Center analisado como uma fortaleza em guerra

Sala de operações

Índice da campanha

25 documentos localizados

Pesquisar no arquivo Categoria Ordenação

Í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.

Engenharia Militar — Índice da campanha

O JavaScript está desativado. Utilize o índice permanente de links exibido nesta página para acessar os artigos.

Translate

sexta-feira, 5 de agosto de 2016