☕ 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

quinta-feira, 10 de março de 2016

Mainframe History : Capítulo III O Z2: Quando os Bits Pararam de Ranger

 

Bellacosa Mainframe e o outro computador z parte iii

☕ Um Café no Bellacosa Mainframe

Histórias com Cheiro de Naftalina – Capítulo III

O Z2: Quando os Bits Pararam de Ranger

"Toda grande invenção passa por uma fase em que seu criador percebe que a ideia funciona... mas a tecnologia ainda não está pronta para acompanhá-la."

Depois de construir o Z1, Konrad Zuse tinha motivos para comemorar. Ele havia criado uma máquina binária programável em pleno final da década de 1930, algo que parecia ficção científica para a época.

Mas havia um problema.

Na verdade, milhares deles.

Cada operação do Z1 dependia do movimento sincronizado de pequenas peças metálicas. Barras, hastes, alavancas e engrenagens precisavam deslizar exatamente no momento certo para representar zeros e uns. Bastava uma pequena deformação, poeira, desalinhamento ou atrito para que todo o cálculo falhasse.

Era uma obra-prima da engenharia mecânica.

Também era um pesadelo de manutenção.

Konrad Zuse percebeu que, se quisesse levar sua visão adiante, precisaria abandonar parte da mecânica e buscar uma solução mais confiável.

Foi assim que nasceu o Z2.


Quando o Telefone Ensinou a Construir Computadores

Na década de 1930, as centrais telefônicas já utilizavam milhares de relés eletromecânicos para estabelecer ligações automaticamente.

Um relé era, essencialmente, um interruptor acionado por um eletroímã. Quando recebia corrente elétrica, fechava ou abria um circuito. Simples, robusto e repetitivo.

Para Zuse, aquilo era perfeito.

Em vez de depender apenas de peças mecânicas deslizando umas sobre as outras, ele poderia usar relés para representar estados binários.

Ligado.

Desligado.

Pela primeira vez, eletricidade e lógica começavam a trabalhar juntas.


O Que Era o Z2?

Concluído por volta de 1939, o Z2 foi um computador híbrido.

Ele aproveitava componentes do Z1, mas substituía sua unidade lógica por cerca de 600 relés telefônicos, tornando a execução muito mais estável.

A memória continuava baseada em princípios mecânicos, mas a CPU agora respondia com muito mais precisão.

Era um enorme salto tecnológico.

Embora não fosse tão conhecido quanto o Z3, o Z2 foi o verdadeiro laboratório onde Zuse comprovou que sua arquitetura podia evoluir.


Como Funciona um Relé?

Imagine um interruptor de luz.

Agora imagine que ninguém precisa apertá-lo com a mão.

Uma pequena corrente elétrica aciona uma bobina, que atrai uma peça metálica e fecha o contato automaticamente.

Esse movimento acontece em milissegundos.

Cada relé representa um estado lógico:

  • Aberto = 0

  • Fechado = 1

Ao combinar centenas deles, era possível construir portas lógicas como AND, OR e NOT, os mesmos blocos fundamentais que ainda existem nos processadores atuais.

Hoje usamos bilhões de transistores.

Naquela época, centenas de relés já eram uma revolução.


🔧 Oficina do Engenheiro

Relés × Transistores

Os relés tinham vantagens importantes:

  • Maior confiabilidade que mecanismos puramente mecânicos.

  • Facilidade de manutenção.

  • Boa resistência para operações repetitivas.

Mas também apresentavam limitações:

  • Eram lentos, pois dependiam de movimento físico.

  • Produziam um característico "clique" a cada operação.

  • Consumiam mais energia.

  • Sofriam desgaste mecânico ao longo do tempo.

Os transistores, inventados anos depois, eliminariam praticamente todos esses problemas.

Mesmo assim, os relés foram a ponte indispensável entre a mecânica e a eletrônica.


A Primeira Demonstração Pública

Em 1940, Zuse apresentou o Z2 a representantes da Deutsche Versuchsanstalt für Luftfahrt (DVL), instituto alemão de pesquisas aeronáuticas.

A máquina chamou atenção justamente por demonstrar que cálculos complexos podiam ser automatizados de forma muito mais eficiente do que os métodos manuais.

Esse reconhecimento foi importante porque garantiu apoio para o desenvolvimento do próximo projeto.

Sem o sucesso do Z2, talvez o Z3 jamais tivesse existido.


☕ Café com Naftalina

É curioso imaginar que muitos dos relés usados por Zuse eram semelhantes aos empregados nas redes telefônicas da época.

Enquanto milhões de pessoas utilizavam esses dispositivos apenas para completar chamadas, Zuse enxergou neles algo completamente diferente: os blocos de construção de uma máquina capaz de pensar em termos matemáticos.

Grandes revoluções muitas vezes começam quando alguém olha para uma tecnologia comum e faz uma pergunta simples:

"E se ela pudesse servir para outra coisa?"


O Primeiro Passo Rumo à Computação Confiável

O Z1 havia provado que a ideia era possível.

O Z2 provou que ela poderia funcionar de maneira prática.

Essa diferença parece pequena.

Na verdade, mudou tudo.

A engenharia não vive apenas de invenções brilhantes. Ela depende de confiabilidade, repetibilidade e manutenção.

Esses princípios continuam sendo a base de qualquer sistema crítico, dos computadores embarcados em aviões aos grandes mainframes bancários.


📦 Baú do Sysprog

Há uma lição interessante para quem administra ambientes IBM Z.

Muitas vezes, a inovação não consiste em trocar toda a arquitetura, mas em substituir o componente que mais compromete a confiabilidade.

Foi exatamente isso que Zuse fez.

Ele não descartou seu projeto.

Apenas identificou seu maior gargalo e o resolveu.

Em ambientes z/OS, fazemos algo semelhante ao ajustar parâmetros de WLM, substituir dispositivos antigos, atualizar canais de I/O ou modernizar subsistemas sem alterar toda a aplicação.

A evolução sustentável quase sempre acontece por melhorias graduais.


O Legado do Z2

Hoje o Z2 raramente recebe o mesmo destaque do Z1 ou do Z3.

No entanto, ele ocupa um lugar fundamental na história.

Foi nele que Konrad Zuse comprovou que a lógica binária podia deixar de ser apenas uma experiência mecânica e tornar-se uma arquitetura confiável.

Sem o Z2, dificilmente existiria o Z3.

Sem o Z3, a computação programável talvez tivesse seguido um caminho completamente diferente.

Às vezes, os maiores heróis da engenharia não são as máquinas mais famosas, mas aquelas que servem de ponte entre uma ideia brilhante e sua realização definitiva.

E o Z2 foi exatamente essa ponte.

No próximo capítulo conheceremos o Z3, a máquina que consolidou a visão de Konrad Zuse e entrou definitivamente para a história como um dos maiores marcos da computação mundial.

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

sábado, 5 de março de 2016

Engenharia Militar : Capítulo XV — Engenharia de Cerco

Bellacosa Mainframe e a engenharia militar parte xv

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Capítulo XV — Engenharia de Cerco

Quando um Programador COBOL Descobre que os Sistemas Críticos Raramente Morrem de Uma Só Vez... Eles São Cercados Lentamente

A névoa cobria o vale.

No alto da colina, a fortaleza permanecia imóvel.

As bandeiras ainda tremulavam.

As muralhas pareciam intactas.

Os soldados mantinham suas posições.

Quem observasse de longe concluiria rapidamente:

— Está tudo bem.

O velho engenheiro balançou a cabeça.

— Não.

O cerco começou há semanas.

O jovem comandante olhou novamente.

Não havia catapultas disparando.

Não existiam muralhas quebradas.

Nenhum portão havia sido derrubado.

— Mas onde está a batalha?

O mestre apontou para o horizonte.

— Você está procurando explosões.

Eu estou observando suprimentos.

Silêncio.

A água.

A comida.

O cansaço.

A disciplina.

A moral.

As pequenas rachaduras.

É assim que uma fortaleza costuma cair.

Nunca por causa do primeiro golpe.

Sempre pelo último.

Décadas depois...

09h17.

O painel de monitoramento mostrava tudo verde.

CPU em níveis normais.

Discos respondendo.

CICS ativo.

Db2 disponível.

MQ funcionando.

Os usuários continuavam trabalhando.

Mesmo assim...

o arquiteto chamou toda a equipe.

— Estamos sob ataque.

Os mais jovens estranharam.

— Mas nenhum sistema caiu.

O arquiteto respondeu calmamente.

— Ainda não.

O aumento de CPU começou há vinte dias.

As filas MQ cresceram lentamente.

O banco perdeu desempenho.

O espaço em disco diminuiu.

Os backups estão demorando mais.

Os jobs terminaram cinco minutos depois do normal.

Os usuários ainda não perceberam.

Mas o cerco começou.

Sirva mais um café.

Hoje aprenderemos que os maiores desastres raramente começam como desastres.

Começam como pequenos sinais ignorados.


1. O Cerco é uma Guerra de Paciência

Nas batalhas medievais, atacar muralhas era extremamente caro.

Perdiam-se homens.

Equipamentos.

Tempo.

Por isso, muitos comandantes preferiam outra estratégia.

Esperar.

Bloquear estradas.

Impedir alimentos.

Cortar água.

Interromper comunicações.

Enfraquecer lentamente a fortaleza.

Na tecnologia acontece exatamente igual.

Pouquíssimos ambientes entram em colapso instantaneamente.

Normalmente eles passam por um longo período de degradação.

O desastre apenas revela um problema que já existia havia muito tempo.


2. A Fome dos Sistemas

Uma fortaleza precisa de:

água.

comida.

madeira.

medicamentos.

Homens.

Um ambiente IBM Z também possui recursos essenciais.

CPU.

Memória.

Canal.

Disco.

Rede.

Locks.

Threads.

Buffers.

Storage.

Quando um desses recursos começa a faltar...

o cerco iniciou.


3. O Inimigo Invisível

Nem todo cerco possui um exército.

Alguns cercos são provocados por:

crescimento inesperado.

dados excessivos.

má indexação.

SQL ineficiente.

loops.

vazamentos de memória.

logs gigantescos.

jobs acumulados.

Mudanças aparentemente pequenas.

A maioria dos grandes incidentes nasce dessas pequenas decisões.


4. A Catapulta Moderna

Na Idade Média...

catapultas lançavam pedras.

Hoje...

os projéteis possuem outros nomes.

Ataques DDoS.

Ransomware.

Exploração de credenciais.

Carga inesperada.

Processamentos mal planejados.

Integrações descontroladas.

APIs sem limitação.

Cada um deles tenta romper uma parte diferente da muralha.


5. O Túnel Sob a Fortaleza

Os antigos sitiantes escavavam túneis.

Não atacavam o muro.

Atacavam seus alicerces.

No software ocorre algo semelhante.

Uma aplicação aparentemente saudável pode possuir:

Copybooks duplicados.

Regras contraditórias.

Dependências desconhecidas.

Interfaces abandonadas.

Bibliotecas antigas.

Tudo permanece funcionando...

até que alguém mexe justamente naquele ponto.

Então toda a estrutura treme.


6. O Cerco Psicológico

Uma fortaleza não era derrotada apenas pela fome.

Também pela exaustão.

Boatos.

Incertezas.

Medo.

Na engenharia existe equivalente.

Alarmes constantes.

Incidentes sucessivos.

Mudanças mal comunicadas.

Pressão.

Horas extras intermináveis.

A equipe cansada começa a cometer erros.

Às vezes...

o verdadeiro alvo nunca foi a infraestrutura.

Foi o fator humano.


7. O Espião Dentro das Muralhas

Muitos castelos caíram porque alguém abriu um portão.

Não por força.

Por confiança mal administrada.

Hoje encontramos equivalentes.

Senha compartilhada.

Conta privilegiada esquecida.

Permissão excessiva.

Token exposto.

Script automático sem controle.

A fortaleza continua robusta.

Mas alguém deixou a chave pendurada.


8. O Estoque Decide a Guerra

Durante um cerco...

o comandante calcula diariamente.

Quantos dias restam?

Quanto trigo?

Quanta água?

Quantas flechas?

No Mainframe fazemos exatamente igual.

Espaço em DASD.

Capacidade de fitas.

Buffers.

Storage.

Consumo de CPU.

Janela Batch.

Taxa de crescimento.

Capacity Planning não é luxo.

É logística de sobrevivência.


9. O Tempo Trabalha para os Dois Lados

Quem ataca também sofre.

Quem defende também.

O segredo está em administrar recursos melhor que o adversário.

Na produção isso significa:

priorizar.

adiar.

balancear.

redistribuir.

automatizar.

Eliminar desperdícios.

O WLM faz exatamente esse papel.

Ele é o estrategista silencioso do castelo.


10. Quando a Muralha Parece Perfeita

Existe um erro muito comum.

Pensar que segurança significa muralhas mais altas.

Na realidade...

uma fortaleza forte possui:

observação.

comunicação.

disciplina.

reserva.

planos alternativos.

Treinamento.

Na tecnologia chamamos isso de:

monitoramento.

observabilidade.

logs.

SMF.

RMF.

SIEM.

Alertas.

Automação.

Backup testado.

Plano de recuperação.


11. Goblin Slayer Nunca Invade Sem Estudar

Goblin Slayer raramente ataca imediatamente.

Primeiro observa.

Conta entradas.

Analisa saídas.

Estuda armadilhas.

Descobre horários.

Calcula riscos.

Somente depois age.

Essa metodologia é extremamente parecida com um troubleshooting eficiente.

Antes de alterar qualquer programa:

Observe.

Colete evidências.

Reproduza.

Confirme.

Documente.

Só então modifique.


12. Shogun e a Guerra de Resistência

Em Shogun, a vitória frequentemente pertence ao comandante mais paciente.

Não necessariamente ao mais agressivo.

A mesma lição vale para sistemas críticos.

Nem todo problema precisa de uma solução imediata.

Alguns exigem investigação cuidadosa.

Planejamento.

Execução controlada.

Validação.

A ansiedade costuma destruir mais ambientes do que o defeito original.


13. O Cerco Digital

Imagine um ambiente bancário.

Segunda-feira.

Tudo parece normal.

Mas...

Uma consulta SQL ficou 3% mais lenta.

Uma API recebeu 5% mais chamadas.

O disco cresceu 2%.

A fila MQ aumentou discretamente.

Os logs passaram a ocupar mais espaço.

Nenhum evento isolado preocupa.

Somados...

contam uma história.

A boa engenharia aprende a ler histórias antes que elas se transformem em tragédias.


14. Curiosidade Histórica

O cerco de Constantinopla, em 1453, demonstrou que nenhuma fortaleza é invulnerável. Durante semanas, os defensores resistiram graças à disciplina, ao planejamento e às reservas. O desfecho não ocorreu por um único fator, mas pela combinação de desgaste contínuo, inovação tecnológica, pressão logística e sucessivas decisões tomadas sob enorme tensão.

Nos ambientes IBM Z ocorre algo semelhante. Grandes incidentes raramente têm uma única causa. Investigações de produção costumam revelar uma cadeia de pequenos eventos: aumento gradual de carga, crescimento de dados, parametrizações inadequadas, mudanças recentes, recursos próximos do limite e dependências inesperadas. O papel da engenharia é interromper essa cadeia antes que ela se transforme em uma indisponibilidade.


15. Easter Egg — A Porta Nunca Trancada

Conta uma antiga história que uma fortaleza permaneceu invicta durante cento e vinte anos.

Depois caiu em uma única noite.

Os historiadores procuraram enormes falhas estruturais.

Não encontraram.

Descobriram apenas isto.

O responsável pelo fechamento do portão acreditava que outro soldado faria a inspeção final.

Ninguém fez.

Décadas depois...

um arquiteto encontrou um comentário esquecido em um PROC.

//* VERIFICAR ESPAÇO LIVRE ANTES DA EXECUÇÃO
//* IMPLEMENTAR DEPOIS

A observação havia sido escrita quinze anos antes.

Jamais foi implementada.

Naquela semana...

o volume atingiu 100%.

O ambiente parou.

Nenhuma tecnologia extraordinária causou o incidente.

Apenas uma pequena tarefa adiada repetidamente.


16. Checklist do Comandante Durante um Cerco

Antes que a produção entre em crise, pergunte:

✔ O consumo de CPU está crescendo?

✔ O espaço em disco acompanha o crescimento do negócio?

✔ As filas MQ aumentaram além do esperado?

✔ Os índices do Db2 continuam eficientes?

✔ Os backups ainda cabem na janela operacional?

✔ Existe monitoramento para recursos críticos?

✔ Os alertas são realmente analisados?

✔ O plano de recuperação foi testado?

✔ A documentação está atualizada?

✔ O conhecimento está distribuído entre a equipe?

✔ As mudanças recentes foram revisadas?

✔ Estamos reagindo aos sintomas ou tratando as causas?


Conclusão — A Vitória Antes da Batalha

O jovem comandante voltou a observar a fortaleza.

Agora compreendia.

A batalha nunca começava quando a primeira pedra atingia a muralha.

Ela começava semanas antes.

Quando alguém deixava de revisar os estoques.

Quando um relatório deixava de ser lido.

Quando pequenas rachaduras eram ignoradas.

Quando o excesso de confiança substituía a disciplina.

O velho engenheiro serviu mais uma xícara de café.

— Lembre-se sempre...

Os melhores comandantes não vencem porque lutam melhor.

Vencem porque percebem o cerco antes que os outros descubram que ele começou.

No Data Center acontece exatamente o mesmo.

Os maiores profissionais de Mainframe não são aqueles que resolvem os incidentes mais espetaculares.

São aqueles que impedem que eles aconteçam.

Porque toda fortaleza cai duas vezes.

Primeiro...

na atenção de seus guardiões.

Depois...

em suas muralhas.

E o verdadeiro engenheiro aprende a proteger ambas.

Ao terminar este capítulo, talvez você nunca mais veja um gráfico de CPU, uma fila MQ crescendo lentamente, um volume de disco próximo do limite ou um alerta aparentemente insignificante da mesma maneira.

Porque agora você sabe reconhecer o início de um cerco.

E quem identifica o cerco cedo o suficiente...

quase nunca precisa lutar a batalha final.

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

terça-feira, 1 de março de 2016

Brotas - Sessão Túnel do Tempo

Começava os preparativos para uma aventura.


Brotas a Cidade :


A caminhada leve para explorar a cidade e arredores : 





Playmobils e o Rafting no rio Jacare :





Cavalgando pelo Campo




Rapel na Cachoeira de Santa Eulalia





Arborismo, brincando de macaquinhos


Andando nas copas das arvores








Para saber mais




Wikipedia da cidade de Brotas
Site de promoção de turismo
Site da Prefeitura Municipal de Brotas


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