 |
| 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.
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
Sem comentários:
Enviar um comentário