Contexto histórico

1. O problema antes do Systema 360

Antes de 1964, cada computador era praticamente um mundo separado.

Se uma empresa comprasse dois computadores do mesmo fabricante, podia acontecer de:

• o software não rodar em ambos
• o assembler ser diferente
• o sistema operacional ser diferente
• os periféricos serem incompatíveis

Ou seja:

cada máquina = arquitetura diferente

Isso tornava o crescimento extremamente caro.

2. A revolução do System/360

A IBM fez algo extremamente ousado.

Criou uma única arquitetura para toda uma família de máquinas.

Isso significava:

mesmo instruction set
mesma organização de registradores
mesmo modelo de memória
mesma interface de I/O

Mas com potências muito diferentes.

Exemplo simplificado:

modelo pequeno → barato
modelo médio   → mais rápido
modelo grande  → enorme capacidade

Mas o software era o mesmo.

Esse foi o nascimento do conceito moderno de:

compatibilidade arquitetural

3. A consequência gigantesca

Uma empresa podia:

comprar máquina pequena
↓
crescer
↓
trocar por máquina maior
↓
continuar usando o mesmo software

Isso foi revolucionário para bancos, governo e grandes empresas.

4. Por que a arquitetura sobrevive até hoje

A arquitetura evoluiu:

System/360
↓
System/370
↓
ESA/370
↓
ESA/390
↓
IBM Z

Mas manteve algo fundamental:

compatibilidade para trás

Ou seja, programas escritos décadas atrás ainda podem rodar.

Isso é uma das razões pelas quais, por ex., sistemas bancários, seguradoras, etc., continuam usando mainframes.

5. Um ponto muito importante: segurança arquitetural

Aqui entra algo que realmente diferencia essas máquinas.

Nos sistemas derivados do 360/370 existem mecanismos arquiteturais fortes de proteção, como:

proteção de memória

cada região de memória tem controle de acesso.

estados de privilégio

problem state
supervisor state

Programas normais não podem executar instruções privilegiadas.

chaves de armazenamento (storage keys)

cada bloco de memória tem uma chave que define quem pode acessá-lo.

virtualização segura

máquinas virtuais completamente isoladas.

Esses conceitos existem desde cedo nessas arquiteturas.

6. Por que vírus são muito mais difíceis nesses sistemas

A arquitetura foi projetada para ambientes multiusuário e críticos desde o início.

Então existem camadas fortes de isolamento:

programa
↓
sistema operacional
↓
controle de hardware

Um programa não pode simplesmente:

• sobrescrever o sistema
• acessar memória arbitrária
• executar instruções privilegiadas.

Por isso vírus tradicionais — como os comuns em PCs — são extremamente raros nesses sistemas.

7. O que aconteceu com os PCs

Os PCs nasceram com uma filosofia completamente diferente.

O IBM PC e seus sucessores priorizavam:

simplicidade
baixo custo
compatibilidade rápida

No começo eles tinham:

• praticamente nenhum isolamento de memória
• acesso direto ao hardware
• ausência de proteção real entre programas

Isso abriu espaço para:

vírus
malware
worms

E até hoje o ecossistema de PCs luta com esse problema.

8. A ironia histórica

Os mainframes resolveram muitos desses problemas décadas antes.

Mas o mundo da computação pessoal evoluiu de forma diferente e depois tentou corrigir essas limitações com software.

Hoje vemos coisas como:

• antivírus
• sandbox
• hypervisors
• secure boot

tentando compensar decisões iniciais da arquitetura de PCs.

9. Por que mainframes continuam existindo

Apesar de toda a mudança tecnológica, máquinas como as IBM Z architecture, são uma evolução da arquitetura 360 e continuam sendo usadas para:

• bancos
• sistemas de pagamento
• governos
• grandes transações

Porque oferecem algo muito difícil de replicar:

segurança
confiabilidade
compatibilidade histórica

10. Uma frase que resume bem o System/360

Se eu tivesse que resumir o impacto dessa arquitetura:

O System/360 transformou computadores de máquinas isoladas em uma plataforma estável sobre a qual décadas de software puderam ser construídas.

E o fato de que essa arquitetura ainda está viva mais de 60 anos depois mostra o quão bem ela foi projetada.

Vejamos em detalhes como se liga ao que eu fazia.

1. O começo: lógica hardwired

Quando os computadores surgiram, as instruções eram hard wired, isto é, inicialmente com válvulas, depois com transistores, os circuitos eram a lógica da máquina, em suas instruções, registros, etc.

A paratir do uso de transistores, a forma do empacotamento, dentro da IBM, passou a ser conhecida por siglas e a sigla inicial do cartão acima, era SMS Standard Modular System

A geração que o Sistema 360 substituiu era de maquinas totalmente diferentes uma das outras e não conversavam entre si, sendo que cada uma tinha que rodar seus póprios problemas. A 1401 foi o que o Ford modelo T foi para os automoveis: primeiro computador de produçao em masse e o hardware dele, era com cartões como mostrado acima, sendo as instruções hardwired nestes cartões. Cada cartão tinha:

• transistores
• resistores
• capacitores
• diodos

Eles implementavam funções lógicas como:

AND
OR
flip-flop
adder slice
multiplexer

O processador era basicamente um conjunto de:

registradores
ALU
shifter
barramentos internos
controle hardwired

Tudo isso era literalmente um circuito físico contínuo.

2. As instruções eram caminhos físicos

Quando uma instrução de máquina era executada, ela ativava diretamente esses circuitos.

Por exemplo, uma instrução simples:

AR R1,R2

significava fisicamente:

registrador R1
↓
ALU adder
↑
registrador R2
↓
resultado volta para R1

Ou seja:

dados percorriam fios e transistores específicos

A instrução definia o caminho elétrico dentro da CPU.

3. Diagnósticos exploravam exatamente isso

Os diagnósticos eram programas que executavam instruções específicas para forçar os dados a percorrer caminhos particulares do hardware.

Exemplo de lógica de diagnóstico:

carregar padrão de bits
executar operação
verificar resultado

Se um transistor, capacitor ou porta lógica falhasse, o resultado mudava.

Então o programa sabia:

este datapath está com defeito

E como a documentação do hardware era precisa, o programa podia apontar:

cartão SMS específico

4. O princípio fundamental

O que tornava isso possível era a seguinte equivalência:

instrução de máquina
=
ativação de circuitos físicos específicos

Portanto:

executar instruções
=
testar hardware

O software era literalmente uma ferramenta de teste eletrônico.

Sistema IBM 360

Ela aplicava um desenho que combinava o hardwre e o software de forma totalmente difetente de todas as maquinas que a IBM tinha feito até então. A nivel de máquina, a tecnologia evoluiu e começou a miniaturização em chips que continham as instruções da mesma forma que a tecnologia anterior, porém, para uma linguagem daquela maquina especificamente. Esta tecnologia era conhecida como SLT (Solid Logic Technology). Com esta linguagem, era escrito o que se conhece como microcode, que na verdade, implementa os comandos do sistema que realmente roda a maquina, as instruções de assembler (gren & yellow card), o sistema operacional e todo o software do sistema 360 aque era desenhado com os comandos que o microcode rodava, no nosso velho conhecido green card, que virou o yellow card e que constitui o Assembler 360.

Para a geração Z, o principio continua o mesmo, mas como ampliou muito a capacidade, aumentou muito o que é possivel fazer modernamente e para consultar o que está implementado no microcode da geração Z, a IBM publica o Principles of Operation para o z/Architecture — mas é um documento PDF de mais de 1.500 páginas. Não cabe em nenhum cartão.

Existe o z/Architecture Quick Reference — que tenta replicar a filosofia do Green Card em formato condensado. A IBM ainda o distribui fisicamente em alguns contextos, mas a versão principal é digital.

5. O que mudou nos anos 70: LSI

Quando surgiram máquinas como o IBM 4341, o hardware passou a usar LSI (Large Scale Integration). Ou seja, recapitulando, antes, quando passou do 1401 para o sitemas 360

cartões SLT com transistores e componentes discretos

depois

chips contendo milhares de transistores

No 4341, a Large Scale Integration continuou na mesma direção, aumentando a densidade dentro do chip. Mas a arquitetura não mudou. O datapath lógico continuava sendo:

registradores
ALU
shifter
barramentos

A diferença era apenas física:

componentes discretos
→
transistores dentro do chip

6. Consequência importante

Mesmo com LSI, as instruções continuavam acionando os mesmos caminhos lógicos. Portanto:

diagnósticos escritos em assembler
ainda conseguiam exercitar
todos os circuitos internos

Em outras palavras:

Executando as instruções certas, você fazia os dados passarem por todos os transistores, diodos, capacitores, etc, da CPU — mesmo quando eles estavam dentro de um chip.

7. Como isso aparecia para o técnico

Quando um diagnóstico falhava, o console podia indicar algo como:

ALU datapath error
board K17

O técnico então:

1. removia o cartão
2. substituía por outro

Mesmo na era LSI, o nível de manutenção ainda era board-level.

8. A frase que resume toda a filosofia

Nos computadores IBM daquela época, as instruções da máquina eram praticamente o mapa elétrico da CPU.
Executando as instruções certas, e relacinando dentro delas qual era a posição onde o chip que executava estava, era possível fazer os dados percorrerem todos os circuitos internos e descobrir exatamente qual componente estava defeituoso — mesmo depois que esses componentes passaram a estar escondidos dentro de chips.

Como a arquitetura Z entrou na historia e existe hoje sem nenhuma previsão de ser substituida

A arquitetura Z, é o VM 370 glorificado.

1. O problema que apareceu depois do Systema 360

Quando a arquitetura IBM System/360 foi lançada em 1964, ela foi um sucesso enorme. Muitas empresas começaram a usar essas máquinas para aplicações comerciais e científicas. as logo apareceu um problema prático. Os clientes queriam:

• desenvolver software
• testar programas
• rodar produção

tudo ao mesmo tempo.

Em uma máquina cara e centralizada, isso criava conflitos.

2. A ideia revolucionária do Model 67

Alguns engenheiros da IBM começaram a trabalhar em uma solução baseada em memória virtual e virtualização completa. Isto é, era possivel criar varias maquinas virtuais dentro de uma maquina adequadamente programada. Isso apareceu primeiro no:

IBM System/360 Model 67

A ideia era simples e ao mesmo tempo radical:

cada usuário teria a ilusão de possuir seu próprio computador.

Isso era feito criando máquinas virtuais completas. Cada máquina virtual podia rodar:

• seu próprio sistema operacional
• seus próprios programas
• seu próprio ambiente.

3. O nascimento do CP-67

Este pequeno grupo de engenheiros desenvolveu um sistema chamado Control Program 67 (CP-67). Ele criava múltiplas máquinas virtuais sob o mesmo hardware. Cada usuário via algo assim:

sua própria CPU
sua própria memória
seus próprios discos

Mas tudo era simulado pelo sistema. Para a época (final dos anos 60), isso era algo quase mágico.

4. O problema interno na IBM

Curiosamente, a própria IBM não ficou entusiasmada. A estratégia oficial da empresa era outra: o sistema operacional principal chamado OS/360. Alguns executivos pensavam que virtualização:

• confundiria os clientes
• competiria com o OS/360
• complicaria a linha de produtos.

Então o projeto foi visto como experimental.

5. O projeto quase morre

CP-67 continuou existindo principalmente porque alguns laboratórios da IBM e alguns clientes adoraram a ideia. Usuários perceberam que a virtualização resolvia vários problemas:

• desenvolvimento seguro
• isolamento entre usuários
• testes sem afetar produção.

Mesmo sem grande apoio corporativo, o sistema continuou sendo usado.

6. O reconhecimento tardio

No início dos anos 1970 a IBM finalmente percebeu o valor da ideia. O CP evoluiu para o sistema: VM/370 Ele permitia algo extraordinário:

um mainframe
↓
centenas de máquinas virtuais
↓
cada uma rodando seu próprio sistema

Universidades e centros de pesquisa adotaram isso rapidamente.

7. A ironia histórica

Hoje o mundo inteiro usa conceitos como:

• virtual machines
• hypervisors
• cloud computing

Mas a ideia fundamental já estava ali no VM/370 nos anos 70.

A diferença é que os mainframes foram projetados para isso desde o início.

8. Por que isso foi tão influente

A virtualização resolveu vários problemas importantes:

• isolamento de usuários
• segurança
• melhor uso do hardware
• desenvolvimento mais seguro.

E abriu caminho para algo que hoje parece óbvio:

um computador físico
=
muitos computadores virtuais

9. Uma curiosidade que poucos sabem

Durante anos, dentro da própria IBM, havia duas “culturas” técnicas:

1️⃣ o mundo do OS/360 e sistemas de produção
2️⃣ o mundo do VM e virtualização

Muitos engenheiros que trabalharam com VM acreditavam que ele representava uma forma mais elegante de usar grandes computadores.Com o tempo, a indústria inteira acabou adotando ideias muito parecidas.

A titulo de curiosidade, para desenhar os diagnósticos, você tinha que primeiro dominar o VM, que continha as ferramentas, editores do assembler, o hardware virtual representando o 4341, etc. e demorava uns 6 meses para ficar on board.

O VM, uma vez dominado, era uma maravilha, com o CMS eliminando aquela confusão que eram os sets de cartões para processamento em batch, a facilidade de exportar e importar qualquer tipo de arquivo, entre maquinas, mesmo que estivessem do outro lado do planeta.

Era como voce tivesse sob seu controle uma máquina que se fosse em hardware, custava milhões de dólares.

A IBM, assim que as comunicações se assentaram com os satélites e era possivel comprar canais de voz e falar com o mundo todo, ela tinha por norna instalar em todas sua fábricas, antenas de satélites para ficar inserida na grade, que era o mundo todo.

Nunca vou me esquecer quando da primeira vez conversei, desde Sumaré, SP, Brasil, onde esta a fábrica dos 4341, com alguém em Tela Viv, Israel, não sei bem onde e, embora fosse apenas com texto, sem imagem. Isto ocorreu nos fins da década de 70 e, hoje, penso, como foi possível ter tudo isto na mão e não ver o que ia acontecer?

Adeus ficar carregando fitas de 3420, ou pior, caixas decks de cartões perfurados, para carregar na unha em alguma maquina quando era necessário. Você fazia o down load, para sua maquina virtual ou física e, pronto!

A bem da verdade, uma das coisas que impediram a IBM ver no que o PC se transformaria, era que as pessoas que se sentavam para desenhar e propor um computador de uso doméstico, sempre o imaginavam uma miniaturização dos main frames, rodando VM, que nunca iria vingar, porque sempre batia no custo: quando um carro bom zero custava uns 2500 dólares, as maquinas propostras custavam 10 000 e o obstáculo de ter que aprender o VM era insuperavel.

Fora a arrogância de questionar para que se haveria de querer um computador doméstico…

10. A conclusão curiosa

A virtualização do VM era diferente da virtualização inicial que era obtida pelo microcode que implementava o green/yellow card originalmente, e o que o grupo que criou o VM percebeu, foi uma coisa que hoje é taken for granted, isto é, você pode criar imagens virtuais do que você quiser, embora que a virtualização que o sistema 360 introduziu fosse centrada apenas nas máquinas dos vários tamanhos para rodar os programas que eram desenhados nas linguagens padrão da época.
Na verdade, essa sempre foi uma das ideias centrais da arquitetura que começou com o System/360.
E o mais curioso é que muitas tecnologias consideradas modernas hoje são, em essência, redescobertas de conceitos que já existiam nos mainframes há cinquenta anos.
A arquitetura de nuvem, a internet, as máquinas virtuais, tudo apareceu com o VM 370 e modernamente, isto é a base do que existe e os aspectos de eficiência, automação e escalabilidade, não são inovações, são aperfeiçoamentos do VM 370, que agora se chama Servidores da geração Z;
Acho incrível a IBM ter tido tudo isto na mão já nos anos 70/80 e não ter conseguido fazer o que fizeram os donos das soluções computadorizadas atuais e a IBM praticamente ter sumido.

A maior ironia disto tudo, é que a nuvem, onde tudo ocorre hoje, fisicamente ela esta grounded, no chão, em algum mainframe rodando arquitetura 360 glorificada, como é o caso da geração Z.

Quando alguém hoje diz que um mainframe moderno é “um grande sistema de virtualização”, isso não está totalmente errado. Na verdade, essa sempre foi uma das ideias centrais da arquitetura que começou com o System/360. E o mais curioso é que muitas tecnologias consideradas modernas hoje são, em essência, redescobertas de conceitos que já existiam nos mainframes há cinquenta anos.

A arquitetura de nuvem, a internet, as maquinas virtuais, tudo apareceu com o VM 370 e modernamente, isto é a base do que existe e os aspectos de eficiência, automação e escalabilidade, não são inovações, são aperfeiçoamentos do VM 270, que agora se chama Z;

Acho incrivel a IBM ter tido tudo isto na mão já nos anos 70/80 e não ter conseguido fazer o que fizeram os donos das soluções computadorizadas atuais e a IBM praticamente ter sumido.

______________________________________________________________________________________________________

Um pouco do que eu fiz com computadores

Escrevo estas linhas para deixar registrado para meus filhos e netos um pouco do trabalho que fiz quando era jovem trabalhando com computadores. Hoje a tecnologia evoluiu enormemente, mas muitos dos conceitos fundamentais que usamos naquela época continuam presentes nos sistemas modernos.

Entre 1976 e 1983 tive a oportunidade de trabalhar em Endicott, no estado de Nova York, nos Estados Unidos. Endicott foi um dos lugares históricos da IBM e dali saíram muitos dos computadores que rodaram no mundo nas décadas de 1960, 1970 e parte da década de 1980.

Fui para lá porque o Brasil iria produzir um computador da família IBM chamado 4341 para atender parte da região da Ásia e do Extremo Oriente. Naquela época era prática da IBM envolver as equipes que iriam fabricar uma máquina no desenvolvimento de partes do sistema. Assim o conhecimento técnico não ficava concentrado em apenas um lugar.

Parte desse trabalho consistia em escrever programas de diagnóstico de hardware, e foi nisso que trabalhei durante esse período.

Um pouco sobre Endicott

Endicott, Nova York, é considerada por muitos como “O Berço da IBM”. Os moradores ficaram desapontados quando um museu local decidiu devolver as centenas de itens históricos que haviam sido emprestados pela empresa. Este vídeo é do Dia da Mudança – 8 de janeiro de 2024. Os esforços para encontrar um novo local para a icônica exposição continuam em Endicott. Leia a matéria da WNBF News .

Endicott tem um papel especial na história da computação. Foi ali que nasceu uma grande parte da engenharia da IBM durante o século XX.
Durante décadas, muitos dos computadores que equiparam bancos, governos e grandes empresas do mundo inteiro foram projetados e produzidos naquela região.
Trabalhar ali significava estar no meio de um dos centros mais importantes da engenharia de computadores da época.

A arquitetura dos computadores

Os computadores com que trabalhei pertenciam à família iniciada pela arquitetura IBM System/360 e depois continuada pelo System/370, que ainda hoje nas maquinas Z são usadas. Essa arquitetura foi uma das grandes revoluções da história da computação porque introduziu uma ideia extremamente poderosa: uma única arquitetura para uma família inteira de máquinas, desde modelos menores até sistemas muito grandes.

Expliquei esta arquitetura no contexto histórico e vejamos como se ligava ao que eu fazia.

Essa arquittetura significava que o conjunto de instruções, registradores e modelo de programação eram essencialmente os mesmos para todas as maquinas, independentemente do tamnho. Um programa escrito para uma máquina menor podia continuar funcionando em uma máquina maior muitos anos depois.

Esse conceito de compatibilidade arquitetural ainda é um dos pilares da computação moderna.

O tipo de trabalho que eu fazia

Meu trabalho era escrever programas de diagnóstico de hardware.
Naquela época os computadores eram construídos com módulos eletrônicos montados em cartões. Esses cartões continham circuitos lógicos — inicialmente com transistores discretos e depois com circuitos integrados de larga escala (LSI).
Quando um defeito ocorria, não se consertava um transistor individual. Substituía-se o cartão inteiro, que era considerado uma unidade de manutenção.
Para tornar isso possível, os computadores eram projetados de forma que programas pudessem exercitar sistematicamente todos os caminhos lógicos do hardware.

O shifter — a parte pela qual fiquei responsável

Dentro da CPU existiam vários blocos lógicos. Um deles era o shifter, responsável por deslocar ou rotacionar bits dentro de uma palavra.
Essas operações parecem simples, mas são fundamentais para muitas instruções e para diversas operações internas do processador.
No período em que trabalhei nesses diagnósticos, fiquei especificamente envolvido com testes ligados a esse circuito.
Um caminho simplificado dentro da CPU podia ser representado assim:

Registrador → Barramento interno → ALU
             → Shifter → Barramento de resultado → Registrador

Quando um diagnóstico executava certas instruções, os dados eram obrigados a percorrer esse caminho.Se qualquer parte desse circuito estivesse defeituosa, o resultado da operação não seria o esperado.

Por que o shifter era importante para os diagnósticos

Os diagnósticos usavam padrões específicos de bits para forçar o hardware a trabalhar em todas as suas condições possíveis. Alguns exemplos de padrões usados eram:

• um único bit “andando” pela palavra
• padrões alternados como 10101010…
• todos os bits em 1 ou todos em 0

Esses padrões faziam os sinais passarem por diferentes partes do circuito lógico. Se algum estágio do circuito estivesse defeituoso, o erro aparecia imediatamente no resultado.

A alma dos MAPs

Os resultados desses diagnósticos eram interpretados através de procedimentos chamados MAPs (Maintenance Analysis Procedures). Os MAPs eram essencialmente árvores de decisão que guiavam o técnico até a peça defeituosa.

A ideia era simples:

Executar teste
      │
      ▼
Resultado correto?
      │
   ┌──┴──┐
   │     │
  NÃO   SIM
   │
   ▼
Executar teste adicional
   │
   ▼
Identificar módulo defeituoso

A verdadeira “alma” desses MAPs era justamente o fato de que os diagnósticos exercitavam os circuitos internos de maneira controlada.Isso permitia algo muito importante: consertar a máquina sem precisar entender como ela funcionava.
O técnico no campo não precisava conhecer toda a arquitetura do computador. Bastava seguir o procedimento, executar os testes e substituir o módulo indicado.
Essa era uma filosofia muito clara da engenharia da IBM: máquinas complexas deveriam ser projetadas de forma que pudessem ser mantidas em funcionamento através de procedimentos bem definidos.

O que mudou nos computadores modernos

Hoje os computadores são muito mais complexos. Nos sistemas daquela época, a execução de instruções era relativamente direta. Era possível imaginar claramente o caminho que os dados percorriam dentro da máquina. Nos processadores atuais existem mecanismos como:

• pipelines profundos
• execução fora de ordem
• múltiplos níveis de memória cache
• paralelismo interno muito sofisticado

Isso tornou os computadores incrivelmente rápidos, mas também muito mais difíceis de compreender completamente. Na época em que trabalhei, era possível imaginar literalmente os bits caminhando pelos circuitos.

Uma última reflexão

Se eu estivesse começando minha carreira hoje, provavelmente trabalharia na área de inteligência artificial. Essa parece ser a nova grande fronteira da computação.
Mas continuo achando fascinante lembrar de uma época em que era possível entender a máquina quase completamente e escrever programas que testavam diretamente o hardware.
Deixo este pequeno relato para que vocês saibam um pouco do que fiz e da parte da história da computação em que tive a sorte de partic