☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sábado, 7 de maio de 2016

Mainframe History : Parte V — Z4: O Computador que Sobreviveu à Guerra e Ensinou a Europa a Computar

 

Bellacosa Mainframe e o outro computador z parte v

☕ Um Café no Bellacosa Mainframe

Muito Antes do IBM Z Existia Outro "Z"

Parte V — Z4: O Computador que Sobreviveu à Guerra e Ensinou a Europa a Computar

"Algumas máquinas são aposentadas. Outras tornam-se peças de museu. O Z4 atravessou uma guerra, cruzou montanhas e inaugurou uma nova era da computação científica."

Até aqui acompanhamos a extraordinária jornada de Konrad Zuse.

Conhecemos o apartamento transformado em laboratório.

Vimos nascer o Z1, praticamente um relógio mecânico capaz de calcular.

Assistimos ao surgimento do Z2, quando os relés telefônicos começaram a substituir parte da mecânica.

Depois testemunhamos o Z3, considerado por muitos historiadores o primeiro computador digital programável totalmente funcional do mundo.

Mas a história ainda reservaria um capítulo digno de um romance de aventura.

Porque o próximo computador de Zuse não seria apenas mais rápido.

Ele precisaria sobreviver.

Não a um erro de programação.

Não a um ABEND.

Não a uma pane elétrica.

Precisaria sobreviver à maior guerra que a humanidade já havia conhecido.

Seu nome era Z4.

E, de certa forma, ele foi o primeiro computador europeu a provar que uma máquina programável podia deixar o laboratório e tornar-se uma ferramenta indispensável para a ciência.


Quando a História Invade a Engenharia

No início da década de 1940, a Segunda Guerra Mundial já havia transformado completamente a Europa.

Berlim deixara de ser apenas uma grande capital industrial.

Era também alvo constante de bombardeios.

Laboratórios desapareciam.

Universidades interrompiam pesquisas.

Fábricas eram destruídas.

A infraestrutura alemã começava a ruir.

Nesse ambiente caótico, continuar construindo computadores parecia uma tarefa quase impossível.

Mesmo assim, Konrad Zuse continuou trabalhando.

Talvez porque engenheiros possuam uma característica peculiar.

Eles costumam enxergar problemas onde outros enxergam apenas caos.

E gostam de resolvê-los.


O Fim do Z3

O Z3, orgulho da engenharia alemã, não teve um destino feliz.

Durante um bombardeio aliado sobre Berlim, em 1943, o computador foi destruído juntamente com o prédio onde estava instalado.

Não existiam backups.

Não havia replicação geográfica.

Nada parecido com um GDPS moderno.

Quando o prédio desapareceu, boa parte daquele trabalho pioneiro desapareceu junto.

Hoje falamos em Disaster Recovery.

Na década de 1940, o desastre era real.

E frequentemente irreversível.


☕ Café com Naftalina

Imagine um Sysprog ouvindo que seu único datacenter foi completamente destruído.

Sem cópia de segurança.

Sem outro site.

Sem storage espelhado.

Sem nuvem.

Foi exatamente isso que aconteceu com o Z3.

A computação corporativa moderna aprendeu, muitas vezes da forma mais difícil, que disponibilidade começa muito antes da tecnologia.

Começa no planejamento.


O Projeto Não Morreu

Se há algo que diferencia grandes engenheiros é a capacidade de recomeçar.

A destruição do Z3 não significou o fim da visão de Konrad Zuse.

Muito antes do bombardeio, ele já trabalhava em um sucessor.

Esse novo computador deveria corrigir limitações observadas nos projetos anteriores.

Mais memória.

Mais estabilidade.

Maior flexibilidade.

Mais recursos para cálculos científicos.

Assim nasceu o projeto do Z4.


Um Computador em Tempos de Escassez

Construir um computador em plena guerra exigia criatividade.

Componentes eletrônicos eram raros.

Relés eram disputados pela indústria militar.

Materiais metálicos tinham prioridade para armamentos.

Nada era simples.

Cada componente precisava ser reaproveitado.

Cada peça exigia planejamento.

Hoje reclamamos quando um fornecedor atrasa um SSD.

Konrad Zuse precisava convencer autoridades a liberar pequenas quantidades de relés.

Era outra realidade.


A Arquitetura Evolui

Embora mantivesse muitas ideias do Z3, o Z4 representava um importante amadurecimento.

A máquina foi projetada para oferecer maior confiabilidade e ampliar o conjunto de operações disponíveis para cálculos científicos.

Seu foco continuava sendo a engenharia.

Pontes.

Estruturas.

Aerodinâmica.

Matemática aplicada.

Mas agora havia também uma preocupação crescente com produtividade.

Quanto menos tempo um pesquisador gastasse calculando manualmente, mais tempo teria para pensar.

É uma filosofia que permanece viva na automação moderna.


🔧 Oficina do Engenheiro

Quando falamos em evolução arquitetural, não devemos imaginar apenas aumento de velocidade.

Arquitetura também significa:

  • facilidade de operação;

  • confiabilidade;

  • manutenção;

  • expansão;

  • organização lógica dos componentes.

Esses princípios continuam norteando o desenvolvimento dos atuais processadores IBM Z.


Um Computador em Fuga

À medida que a guerra se aproximava do fim, tornava-se evidente que Berlim não era mais um lugar seguro para um equipamento tão valioso.

O Z4 precisava desaparecer.

Literalmente.

Sua trajetória tornou-se quase cinematográfica.

O computador foi desmontado.

Transportado em partes.

Escondido em diferentes locais.

Protegido sempre que possível.

Durante meses, permaneceu longe dos grandes centros urbanos para escapar da destruição.

Cada relé salvo representava anos de trabalho.

Cada módulo preservado aumentava a esperança de que aquele projeto sobrevivesse ao conflito.

Hoje movimentamos uma imagem virtual entre LPARs em poucos segundos.

Na década de 1940, mover um computador significava carregar centenas de quilos de equipamentos por estradas precárias, sob o risco constante da guerra.


A Guerra Acaba

Quando o conflito terminou em 1945, a Europa encontrava-se devastada.

Mas o Z4 havia sobrevivido.

Essa simples frase já seria suficiente para colocá-lo entre as máquinas mais extraordinárias da história.

Entretanto, sua jornada estava apenas começando.

Konrad Zuse compreendeu que o futuro da computação dependeria menos de demonstrações experimentais e mais da utilização prática dessas máquinas.

Era preciso encontrar usuários.

Pesquisadores.

Universidades.

Instituições dispostas a investir nessa nova tecnologia.


Uma Nova Casa: ETH Zürich

Em 1950, o Z4 encontrou seu destino definitivo.

Foi instalado na ETH Zürich (Instituto Federal de Tecnologia de Zurique), na Suíça.

Não foi uma escolha qualquer.

A ETH já era uma das mais respeitadas instituições científicas da Europa.

Albert Einstein havia estudado ali décadas antes.

Agora seria a vez de outro protagonista da ciência deixar sua marca.

O Z4 tornou-se uma poderosa ferramenta para pesquisadores que precisavam resolver problemas matemáticos complexos.

Pela primeira vez, um computador programável europeu deixava definitivamente a condição de experimento para assumir papel relevante na produção científica.


📦 Baú do Sysprog

Muito antes dos contratos de outsourcing, dos ambientes compartilhados e do conceito de Computing as a Service, o Z4 já representava algo semelhante.

Em vez de cada pesquisador construir sua própria máquina, diversos grupos utilizavam um único computador para resolver problemas diferentes.

A ideia de compartilhar recursos computacionais começava a nascer.

Décadas depois, ela evoluiria para os mainframes IBM, onde milhares de usuários compartilham simultaneamente o mesmo sistema físico por meio de LPARs, z/VM e outras tecnologias de virtualização.


O Primeiro Computador Comercial da Europa?

Os historiadores costumam discutir essa afirmação com cuidado.

Mas há um consenso importante.

O Z4 foi um dos primeiros computadores programáveis efetivamente comercializados e utilizados por clientes reais na Europa.

Isso muda completamente sua posição histórica.

Ele deixou de ser apenas uma curiosidade de laboratório.

Transformou-se em um produto.

Hoje parece natural comprar servidores.

Na década de 1950, vender um computador era algo quase inimaginável.


Enquanto Isso, a IBM Observava Outro Mercado

É interessante comparar esse momento com a trajetória da IBM.

Enquanto Zuse desenvolvia computadores científicos programáveis, a IBM consolidava sua liderança com equipamentos baseados em cartões perfurados.

Os clientes eram diferentes.

As necessidades também.

A IBM dominava:

  • censos;

  • bancos;

  • seguradoras;

  • governos;

  • contabilidade.

Zuse concentrava-se em:

  • universidades;

  • engenharia;

  • pesquisa científica.

Décadas depois, essas duas correntes tecnológicas convergiriam para formar a indústria da computação moderna.


O Que um Sysprog Aprende com o Z4?

Talvez a maior lição do Z4 seja que tecnologia só muda o mundo quando encontra usuários.

Não basta construir uma máquina extraordinária.

É preciso que alguém a utilize para resolver problemas reais.

Esse princípio continua absolutamente válido.

Não importa se estamos falando de IA generativa, OpenTelemetry, Zowe, DevOps ou IBM Z.

Tecnologia sem aplicação prática é apenas demonstração.

Tecnologia utilizada diariamente transforma empresas, economias e sociedades.

O Z4 foi uma das primeiras máquinas a provar isso.


A Semente da Computação Moderna

O sucesso do Z4 demonstrou que computadores programáveis não eram apenas curiosidades acadêmicas.

Eles poderiam tornar-se ferramentas permanentes de pesquisa.

Poderiam acelerar descobertas científicas.

Poderiam justificar investimentos.

Poderiam evoluir continuamente.

Esse talvez seja seu maior legado.

Mostrar que a computação possuía um futuro.

E que esse futuro seria construído por gerações de engenheiros.


No Próximo Café...

Até agora falamos sobre máquinas.

Na próxima parte conheceremos algo ainda mais revolucionário.

Uma ideia.

Uma linguagem.

Enquanto boa parte do mundo ainda discutia como construir computadores, Konrad Zuse já pensava em como conversar com eles.

Nascia o Plankalkül, considerado por muitos a primeira linguagem de programação de alto nível da história.

Muito antes de FORTRAN.

Muito antes de ALGOL.

Muito antes de COBOL.

Uma linguagem tão avançada que o mundo levaria décadas para entender o que seu criador havia imaginado.

Prepare o café.

Na próxima viagem, descobriremos que Konrad Zuse não inventou apenas computadores.

Ele também ajudou a inventar a forma como programamos.

☕ Um Café no Bellacosa Mainframe

Histórias com Cheiro de Naftalina

O Guia do Viajante do Tempo

Muito Antes do IBM Z Existia Outro “Z”

Viaje pelas origens da computação, conhecendo Konrad Zuse, Herman Hollerith, Tommy Flowers, John von Neumann, o Colossus, o EDVAC, o IBM System/360 e os pioneiros que construíram o caminho até o IBM Z.

ARTIGO SELECIONADO

O Guia do Viajante do Tempo

Abrir em nova guia ↗
Preparando a máquina do tempo...

Caso o navegador impeça a exibição incorporada, utilize o botão Abrir em nova guia.

☕ Quem não conhece o passado não entende o código do futuro.

Bellacosa Mainframe — tecnologia, história, COBOL, IBM Z e memória.

sexta-feira, 6 de maio de 2016

El Jefe vai as compras

Duque de Caixas e a lojas de artigos para motocicletas.


Chegando a Sampa para mais um dia de trampo, aquele bate papo com o amigo motorista, aquela pessoa a quem confiamos nossas vidas todos os dias, de manha e a tarde ele vela pela nossa segurança e nos leva em Direcção ao nosso ganha pão.



Nesta sexta aviso que não vou retornar a casa, desta vez tenho planos diferentes, vou dormir na casa de um amigo e sábado partir para o centrao.

Tinha que comprar acessórios para a moto e na região da duque de Caxias estão centralizadas as melhores lojas do ramo com os melhores preços. Próximo as ruas Auroras e Guaianazes, na famosa boca do luxo, voce encontra inúmeras lojas de acessório, tudo o que precisa para sua moto encontrara por la.

Carregadissimo parti para Campinas para mais um final de semana com a Galadriel... foi bem intenso estes dias.

quinta-feira, 5 de maio de 2016

Engenharia Militar : Apêndice A — Correspondências Históricas e Técnicas

Bellacosa Mainframe e a engenharia militar apendica A

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Apêndice A — Correspondências Históricas e Técnicas

Quando um Programador COBOL Descobre que um Data Center Funciona Muito Mais Como um Castelo Medieval do que Como um Simples Conjunto de Computadores


Introdução

Ao longo deste livro, utilizamos uma ideia central: os princípios da engenharia mudam muito menos do que as tecnologias.

Durante milhares de anos, engenheiros militares precisaram responder às mesmas perguntas que hoje desafiam arquitetos de sistemas IBM Z.

Como proteger recursos?

Como garantir continuidade?

Como distribuir trabalho?

Como transportar informações?

Como impedir invasões?

Como recuperar uma fortaleza após um ataque?

As respostas mudaram de forma.

Mas quase nunca mudaram de princípio.

Este apêndice reúne essas correspondências para servir como um "tradutor" entre o mundo das fortalezas medievais e o universo do Mainframe IBM Z.


A Grande Correspondência

Engenharia MilitarIBM Z / MainframeFunção em Comum
ReinoEmpresaOrganização protegida
CapitalData Center PrincipalCentro das operações
FortalezaData CenterEstrutura protegida
CasteloIBM ZNúcleo operacional
Torre de VigiaConsole de MonitoramentoObservação contínua
MuralhasRACF + FirewallsControle de acesso
Ponte LevadiçaLogin / AutenticaçãoEntrada controlada
Chaves do CasteloCredenciaisAutorização
Guarda RealRACFControle de identidade
SentinelasOperadoresVigilância permanente
GeneralWLMDefinição de prioridades
Conselho de GuerraArquitetura CorporativaDecisões estratégicas
Quartel-GeneralSala de OperaçõesCoordenação
EscribaSMFRegistro histórico
MensageirosMQComunicação segura
Estradas ReaisRedeTransporte de informações
CeleiroStorageArmazenamento
ArsenalBibliotecas APFRecursos privilegiados
TesouroDb2Dados mais valiosos
Arquivo RealVSAMInformações permanentes
BibliotecaPDS / PDSERepositório de programas
Oficina dos FerreirosCompilador COBOLConstrução de ferramentas
Mapa MilitarJCLPlano de execução
Campanha MilitarJob BatchMissão completa
Ordem do GeneralStep JCLEtapa da missão
SoldadoPrograma COBOLUnidade operacional
PatrulhaJob SchedulerMissões recorrentes
Campo de TreinamentoAmbiente de TestesPreparação
Campo de BatalhaProduçãoAmbiente real
CidadeUsuáriosPopulação atendida
EspiãoAuditoriaInvestigação
PrisioneiroDataset bloqueadoRecurso indisponível
Hospital MilitarRecoveryRecuperação
Reserva EstratégicaBackupContinuidade
Muralha InternaSegmentaçãoDefesa em profundidade
Torre do ComandantePainel ExecutivoVisão estratégica

Organização Hierárquica

Reino

Na Idade Média:

O reino era composto por diversas cidades, castelos e fortalezas.

No Mainframe:

A empresa possui:

  • diversos Data Centers

  • aplicações

  • bancos

  • integrações

  • ambientes

Tudo forma um único ecossistema.


Castelo

O castelo concentra:

  • comando

  • recursos

  • documentos

  • armas

  • soldados

O IBM Z concentra:

  • processamento

  • dados

  • segurança

  • continuidade

  • integração

É literalmente o coração da infraestrutura.


Muralhas

Uma muralha não impede completamente ataques.

Ela:

retarda.

filtra.

desgasta.

identifica.

Da mesma forma, o RACF não existe apenas para bloquear usuários.

Ele controla:

quem.

quando.

como.

até onde.


Ponte Levadiça

O portão de um castelo nunca permanecia totalmente aberto.

Cada visitante precisava ser identificado.

Hoje acontece exatamente igual.

Login.

Senha.

MFA.

Certificados.

Tokens.

Tudo representa a moderna ponte levadiça.


Guarda Real

No castelo:

os guardas conheciam cada pessoa autorizada.

No Mainframe:

o RACF conhece:

usuários.

grupos.

recursos.

perfis.

autorizações.

A missão permanece idêntica.


Correspondências Operacionais

Mensageiros

Na fortaleza:

um mensageiro levava ordens entre castelos.

No IBM Z:

quem faz isso é o MQ.

Ele entrega mensagens.

Não importa quando.

Nem onde.

Nem quantas.

Apenas garante que cheguem.


Estradas

Os romanos descobriram que exércitos rápidos venciam guerras.

Hoje...

redes rápidas vencem gargalos.

Uma excelente aplicação sobre uma rede ruim produz exatamente o mesmo resultado que um excelente exército preso em uma estrada destruída.


Celeiros

Toda fortaleza possuía enormes depósitos.

Sem eles...

não havia sobrevivência.

Hoje chamamos isso de:

Storage.

FlashSystem.

DASD.

Fitas.

Cloud Storage.


Tesouro

O ouro sustentava o reino.

Hoje...

os dados sustentam empresas.

Por isso o Db2 ocupa posição tão importante.


Correspondências de Engenharia

Ferreiros

Os ferreiros produziam:

espadas.

escudos.

armaduras.

Hoje os compiladores produzem:

programas.

Executáveis.

Módulos.

Bibliotecas.

O processo continua sendo fabricação.


Pedreiros

Construíam muralhas.

O equivalente moderno?

Desenvolvedores.

Cada linha de código representa uma pedra da fortaleza.


Engenheiro Militar

Projetava:

pontes.

muros.

torres.

aquedutos.

Hoje encontramos:

Sysprogs.

Arquitetos.

Especialistas IBM Z.

Todos trabalham para manter a estrutura íntegra.


Correspondências Logísticas

Comboios

Levavam:

alimentos.

madeira.

armas.

Hoje...

os Jobs Batch movimentam:

arquivos.

dados.

transações.

relatórios.

É logística.

Mudaram apenas as mercadorias.


Armazéns

VSAM.

Db2.

Storage.

São os depósitos modernos.


Inventário

Os antigos castelos controlavam:

espadas.

flechas.

cavalos.

Hoje controlamos:

datasets.

volumes.

catálogos.

objetos Db2.

O princípio continua exatamente igual.


Correspondências Estratégicas

Conselho Militar

Discutia:

prioridades.

recursos.

campanhas.

Hoje chamamos isso de:

Architecture Board.

CAB.

Comitê Técnico.

Comitê de Mudanças.


General

Um bom general nunca enviava todos os soldados para a mesma batalha.

O WLM também não.

Ele distribui recursos.

Prioriza.

Equilibra.

Protege.


Reserva Estratégica

Castelos possuíam:

alimentos.

armas.

água.

Hoje temos:

backup.

site alternativo.

DR.

fitas.

snapshots.


Correspondências de Segurança

Espião

Na Idade Média:

procurava informações.

Hoje:

SIEM.

Auditoria.

SMF.

RMF.

Logs.


Sabotador

Antigamente:

abria portões.

Hoje:

credenciais comprometidas.

scripts inseguros.

configurações incorretas.


Cerco

Antes:

bloqueio prolongado.

Hoje:

DDoS.

ransomware.

consumo crescente.

capacity exhaustion.


Correspondências Humanas

Aprendiz

Escudeiro.

Hoje:

Programador Júnior.


Cavaleiro

Especialista.


Mestre de Obras

Arquiteto.


Cronista

Documentação.


Bibliotecário

Administrador de Configuração.


Monge Copista

Gestão do Conhecimento.


Correspondências Filosóficas

HistóriaEngenharia Moderna
PedraCódigo
ArgamassaArquitetura
MuralhaSegurança
TorreMonitoramento
BandeiraGovernança
ChaveCredencial
LivroDocumentação
PergaminhoManual Técnico
Selo RealCertificado Digital
MensageiroMQ
EstradaRede
CeleiroStorage
OuroDados
ReinoEmpresa
PovoUsuários
GeneralArquiteto
SoldadoPrograma COBOL
ExércitoEcossistema de Aplicações
VitóriaDisponibilidade
PazOperação Normal

Curiosidade Histórica

Os maiores engenheiros militares da História raramente eram lembrados apenas por suas muralhas.

Eram lembrados porque conseguiam integrar dezenas de disciplinas diferentes:

arquitetura.

hidráulica.

metalurgia.

logística.

administração.

cartografia.

organização.

O mesmo acontece com os grandes profissionais IBM Z.

Os melhores Sysprogs e Arquitetos dificilmente dominam apenas um produto.

Eles compreendem como COBOL, CICS, Db2, MQ, RACF, z/OS, WLM, Storage, redes, segurança, observabilidade e continuidade de negócios trabalham como um único organismo.

Essa visão sistêmica é o verdadeiro diferencial de um engenheiro.


Easter Egg

Conta uma antiga lenda que um rei perguntou ao engenheiro responsável pela construção de sua fortaleza:

— Qual é a pedra mais importante desta muralha?

O engenheiro respondeu:

— A que ninguém percebe.

O rei ficou confuso.

Então o mestre explicou:

— A pedra escondida no alicerce nunca aparecerá nas pinturas do castelo.

Mas se ela falhar...

todas as outras também cairão.

Séculos depois...

um estagiário perguntou ao Sysprog:

— Qual é o programa COBOL mais importante do banco?

O veterano sorriu.

— Aquele cujo nome você nunca ouviu.

Porque, se um dia todo mundo souber o nome dele...

provavelmente será porque ele parou de funcionar.


Conclusão

Ao terminar este apêndice, talvez você perceba que este livro nunca tentou comparar castelos com computadores apenas por diversão.

A intenção sempre foi mostrar que engenharia é uma disciplina atemporal.

Mudam as ferramentas.

Mudam os materiais.

Mudam as linguagens.

Mudam os processadores.

Mas continuam existindo fortalezas que precisam ser protegidas, recursos que precisam ser administrados, pessoas que precisam confiar na infraestrutura e engenheiros que assumem, todos os dias, a responsabilidade de manter essa fortaleza invisível em funcionamento.

Talvez seja essa a maior lição desta obra.

O IBM Z não é apenas um computador.

Assim como um castelo nunca foi apenas um conjunto de pedras.

Ambos representam a mesma ideia.

Confiança construída por gerações.

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

  1. Engenharia Militar sem Mistérios para Programadores COBOL
  2. Prólogo — O Chamado do Guardião
  3. Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar
  4. Capítulo II — Estratégia, Operação e Tática
  5. Capítulo III — A Cadeia de Comando
  6. Capítulo IV — Logística
  7. Capítulo V — As Muralhas Invisíveis
  8. Capítulo VI — Inteligência, Reconhecimento e Espionagem
  9. Capítulo VII — A Arte da Guerra Aplicada ao Mainframe
  10. Capítulo VIII — Liderança, Moral e Disciplina
  11. Capítulo IX — Inovação, Evolução e o Futuro
  12. Capítulo X — O Legado do Engenheiro
  13. Capítulo XI — O Guardião Invisível
  14. Capítulo XII — A Fortaleza Invisível
  15. Capítulo XIII — Os Sentinelas da Madrugada
  16. Capítulo XIV — A Civilização Invisível
  17. Capítulo XV — Engenharia de Cerco
  18. Glossário IBM Z + Engenharia Militar
  19. Apêndice A — Correspondências Históricas e Técnicas
  20. Os 10 Animes Mais Emblemáticos Sobre Engenharia Militar
  21. Os 10 Animes Mais Emblemáticos Sobre Logística Militar
  22. Os 10 Animes Mais Emblemáticos Sobre Tática Militar
  23. Os 10 Animes Mais Emblemáticos Sobre Estratégia Militar
  24. Especial — Guerrilha Urbana
  25. Especial — Guerrilha no Campo e na Floresta
Bellacosa Mainframe — Arquivo de Engenharia Militar

Estratégia, disciplina, conhecimento, resiliência e continuidade aplicados aos sistemas que não podem parar.

quarta-feira, 4 de maio de 2016

Neblina na estrada

Bellacosa Mainframe e a neblina na estrada

☕ Um Café no Bellacosa Mainframe

🌫️ Neblina na Estrada

A corrida pelo fretado, a pista molhada e mais um dia atravessando São Paulo para trabalhar

Este é um daqueles pequenos momentos do cotidiano que, quando aconteceram, provavelmente não pareciam merecer mais do que algumas fotografias e poucas linhas.

Era apenas mais um dia de trabalho.

Mas, olhando tantos anos depois, percebo que aquela neblina também registrou uma rotina inteira.

Morar em Itatiba e trabalhar na Vila Olímpia significava começar o expediente muito antes de chegar ao escritório. Havia a hora de levantar, preparar as coisas e, principalmente, a corrida para não perder o fretado.

Perder alguns minutos não significava simplesmente chegar alguns minutos atrasado.

Podia significar perder o transporte inteiro.

Naquela manhã, havia ainda outro personagem esperando na estrada: a neblina.



🌫️ A Terra da Garoa

São Paulo nem sempre era aquela cidade bonita de céu azul que aparece nas fotografias.

Também havia manhãs frias, cinzentas e úmidas.

A pista molhada aumentava os riscos. A neblina diminuía a visibilidade. E cada quilômetro lembrava silenciosamente que aquela viagem aparentemente banal nos expunha diariamente a uma enorme quantidade de variáveis.

Automóveis mudando de faixa.

Caminhões.

Freios repentinos.

Acidentes.

Congestionamentos.

E motociclistas surgindo entre os carros quase sem aviso.

Dentro do fretado, porém, havia pouco a fazer além de observar.

São Paulo aparecia lentamente através da névoa.

E então chegava o cheiro do Rio Pinheiros.

Não precisava nem olhar pela janela para saber exatamente onde estávamos.

O rio, durante muitos anos transformado praticamente em um esgoto a céu aberto, fazia parte daquela experiência sensorial nada turística de chegar à Vila Olímpia.

Era São Paulo dizendo:

— Bom dia. Você chegou.

🚌 O escritório era apenas metade da viagem

Daqui a alguns minutos eu estaria no escritório.

Computador ligado.

E-mails.

Problemas.

Reuniões.

Sistemas.

Telefonemas.

Mais uma jornada cheia.

Mas havia uma diferença fundamental entre quem morava relativamente perto do trabalho e quem precisava voltar para outra cidade.

Para mim, o expediente possuía horário de encerramento físico.

Não era uma abstração corporativa.

Tinha quatro rodas.

Chamava-se fretado.

E ia embora sem mim.

Por isso existia uma regra quase inviolável:

17:59 — fechar tudo e vazar.

Não era preguiça.

Era logística.

Porque sempre existia a possibilidade de aparecer, justamente naquele momento, alguém com a frase mais assustadora do escritório:

— Podemos fazer uma reunião rapidinha?

Rapidinha.

Claro.

Duas horas depois, alguém que morava a quinze minutos dali simplesmente pegaria seu carro e iria para casa.

Eu estaria calculando rotas de contingência.



⚠️ ABEND no plano de retorno

Perder o fretado significava iniciar uma verdadeira operação de recuperação de desastre.

Primeiro seria necessário atravessar São Paulo até a Rodoviária do Tietê.

Só isso já poderia consumir um tempo absurdo.

Depois ainda seria preciso encontrar o ônibus intermunicipal para Itatiba.

E havia outro problema.

O ônibus não ficaria esperando porque alguém resolveu marcar uma reunião importantíssima às 18 horas.

Se o trânsito estivesse particularmente infernal, existia até a possibilidade de perder também esse ônibus.

Uma pequena reunião no final do expediente podia transformar uma volta relativamente organizada para casa numa peregrinação através de São Paulo.

Por isso 17:59 não era simplesmente um horário.

Era meu SLA de evacuação.

Às 17:58 começava o shutdown.

Às 17:59:

LOGOFF.

Disconnect.

Vagner has left the building.

😄

🚗 A curiosa vantagem de sair mais tarde

Existe ainda uma das grandes ironias de trabalhar em São Paulo.

Quem mora na própria cidade muitas vezes descobre que não vale a pena sair às 18 horas.

É justamente quando milhares de pessoas fazem a mesma coisa.

As ruas enchem.

As avenidas travam.

As marginais tornam-se enormes estacionamentos.

Então aparece aquele cruel incentivo:

continue trabalhando.

Às 19 horas, boa parte daquela primeira onda de veículos já estará no meio do caminho.

O trânsito começa a respirar.

Para determinadas pessoas, ficar mais uma hora no escritório pode significar chegar praticamente no mesmo horário que chegariam saindo antes.

Mas esse privilégio logístico não existia para mim.

Meu transporte tinha horário.

Minha cidade estava dezenas de quilômetros distante.

Meu dia não terminava quando eu desligava o computador.

Ainda havia uma estrada inteira pela frente.

☕ Apenas mais uma manhã

E talvez seja justamente isso que torne aquela fotografia da neblina interessante tantos anos depois.

Não aconteceu nenhuma grande aventura.

Não houve nenhum acontecimento histórico.

Não ganhei na loteria.

Não encontrei uma celebridade.

Não aconteceu nada extraordinário.

Eu estava simplesmente indo trabalhar.

Mas nossa vida é formada principalmente por esses dias.

A neblina.

A pista molhada.

O vidro do fretado.

Os prédios desaparecendo entre as nuvens baixas.

O trânsito.

O cheiro desagradável do Pinheiros.

A Vila Olímpia se aproximando.

A preocupação silenciosa com os riscos da estrada.

E a certeza de que, dentro de alguns minutos, eu entraria no escritório e começaria outra jornada.

Horas depois, às 17:59, começaria outra corrida.

Desta vez no sentido contrário.

Porque trabalhar em São Paulo morando em Itatiba significava aprender uma coisa que nenhum contrato de trabalho explicava:

o caminho também fazia parte do expediente.

E, algumas vezes, a neblina estava lá apenas para nos lembrar disso.


🥚 Easter egg do Bellacosa Mainframe

Se um mainframe controlasse minha saída da Vila Olímpia, provavelmente existiria um job mais ou menos assim:

17:58:00 SHUTDOWN IN PROGRESS

17:58:30 SAVE ALL

17:58:45 LOGOFF

17:59:00 RUN VAGNER RUN

18:00:00 FRETADO DEPARTED

Porque certos ABENDs a gente simplesmente não quer descobrir em produção.

-----------------------------------------------------------------------------------------------------------------------------

Um dia cheio de névoa.


Para completar nosso registro fotográfico das viagens a Sampa, temos uma chegada com neblina. Vejam o alto dos prédios, a serração que a tudo cobre, diminuindo a visibilidade e deixando a pista escorregadia como um sabão.



Tirando os riscos que todos corremos devido a ma visibilidade, fica um registro bonito e poético ver a cidade toda cheia de névoa.

Delicia de momento que antecede mais uma jornada de trabalho.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...