☕ 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

Mostrar mensagens com a etiqueta 64 bits. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta 64 bits. Mostrar todas as mensagens

sábado, 21 de fevereiro de 2026

📊 Da Era dos 16MB ao Infinito: A Linha do Tempo que Explica 24 → 31 → 64 bits no Mainframe

 

Bellacosa Mainframe explica o endereçamento de memoria no IBM Mainframe 24 31 e 64 bits

📊 “Da Era dos 16MB ao Infinito: A Linha do Tempo que Explica 24 → 31 → 64 bits no Mainframe”

Prepare-se, padawan… agora você vai enxergar a evolução do mainframe como um verdadeiro mapa de poder computacional — cada salto não foi só técnico… foi uma jogada estratégica digna de xadrez. ♟️


🟢 1. Era 24 bits — O Mundo Cabia em 16MB

🔹 Contexto

  • Arquitetura do OS/360
  • Endereçamento: 24 bits
  • Limite: 16 MB

🧠 O que isso significava?

  • Tudo precisava caber em um espaço minúsculo
  • Programas eram ultra otimizados
  • Overlays eram comuns (carregar partes do programa sob demanda)

💬 Bellacosa insight:

“Aqui nasceu o DNA da eficiência — cada byte valia ouro.”


🟡 2. Era 31 bits — O Hack Mais Elegante da História

🔹 Contexto

  • Evolução para o MVS
  • Introdução da System/370-XA

⚙️ O que mudou?

  • Endereçamento: 31 bits (não 32!)
  • Limite: 2 GB
  • 1 bit reservado (bit 0) para controle

🔥 O pulo do gato:

  • Compatibilidade TOTAL com 24 bits
  • Mistura de modos (24 + 31)
  • Controle inteligente via bit mais significativo

🧪 Conceito-chave:

O endereço não é só endereço — ele carrega “intenção”

💬 Bellacosa insight:

“Enquanto o mundo queria mais bits… o mainframe queria mais inteligência.”


🔵 3. Era 64 bits — O Universo Expandido

🔹 Contexto

  • Arquitetura moderna: z/Architecture
  • Sistemas como z/OS

🚀 O que mudou?

  • Endereçamento: 64 bits
  • Limite teórico: exabytes
  • Espaço virtual gigantesco

🧠 Novos conceitos:

  • Above the bar / below the bar
  • Memory objects
  • Large memory exploitation

💬 Bellacosa insight:

“Agora não é mais sobre caber… é sobre escalar sem limites.”


📊 Timeline Simplificada (Estilo Raiz)

1970s ───────────────► 24 bits (16 MB)
OS/360

1980s ───────────────► 31 bits (2 GB)
MVS / System/370-XA
(bit 0 reservado 👀)

2000+ ───────────────► 64 bits (exabytes)
z/Architecture / z/OS

🧬 Conexão Evolutiva (O Segredo por Trás)

EraProblemaSoluçãoFilosofia
24 bitsMemória limitadaOtimização extrema“Faça caber”
31 bitsCrescer sem quebrarBit de controle“Evolua com legado”
64 bitsEscalabilidadeEspaço massivo“Expanda sem limites”

🐣 Easter Egg de Mestre

Mesmo no mundo 64 bits…

👉 O conceito de “compatibilidade com legado” continua vivo
👉 E o espírito do bit 0 ainda ecoa nas decisões de design

💥 Ou seja:

O passado do mainframe nunca foi descartado — ele foi incorporado


⚡ Fechamento Estilo Bellacosa

Se você entendeu essa timeline, você desbloqueou algo raro:

🧠 Você não vê mais bits… você vê decisões arquiteturais

Porque no mainframe:

Cada bit tem história
Cada limitação vira estratégia
E cada evolução respeita o passado

 

quarta-feira, 13 de agosto de 2014

🧙 JACK-OF-ALL-TRADES E A DUNGEON DOS 64 BITS — QUANDO O COBOL DESCOBRIU QUE 4 GB NÃO ERAM QUATRO BILHÕES DE GAVETAS

 

Bellacosa Mainframe fala sobre memorias de computador

☕ Um Café no Bellacosa Mainframe

🧙 JACK-OF-ALL-TRADES E A DUNGEON DOS 64 BITS — QUANDO O COBOL DESCOBRIU QUE 4 GB NÃO ERAM QUATRO BILHÕES DE GAVETAS

RAM, ROM, PROM, EPROM, Flash, SRAM, DRAM, cache, memória virtual, SIMM, DIMM, 8, 16, 24, 31, 32 e 64 bits — e o dia em que um programador COBOL descobriu que a memória do computador tinha mais níveis que uma dungeon.



🎬 PRÓLOGO — PRECISAMOS DE MAIS MEMÓRIA!

O jovem programador COBOL entrou na War Room carregando uma folha impressa.

Era um daqueles textos antigos sobre computadores.

Na primeira página estava escrito:

“É normal encontrar nos computadores de hoje 32 a 64 MB de memória.”

Ele olhou para aquilo.

Olhou para o notebook.

Olhou novamente para o papel.

— Mestre... isso está errado!

Jack, de Jack-of-All-Trades, Party of None, examinou o documento como quem recebe um mapa antigo encontrado no fundo de uma dungeon.

— Não necessariamente.

— Mas 64 MB?

— Você está cometendo o primeiro erro do arqueólogo de tecnologia: julgar uma máquina de 1997 usando a régua de 2026.

O texto falava de DIP, SIPP, SIMM de 30 pinos, SIMM de 72 pinos, DIMM de 168 pinos, 80386, 80486 e Pentium.

Aquilo não era apenas documentação técnica antiga.

Era um fóssil.

E fósseis contam histórias.

Jack puxou uma cadeira.

— Hoje você não vai simplesmente aprender RAM. Vai descobrir por que um processador de 8 bits podia acessar 64 KB, por que um processador de 16 bits chegou a 16 MB, por que o IBM System/360 usava 24 bits, por que o mainframe resolveu inventar 31 bits, de onde surgiram os 4 GB dos PCs de 32 bits e por que uma máquina de 64 bits não significa automaticamente 16 exabytes de RAM.

O Padawan COBOL arregalou os olhos.

— Isso tudo é memória?

— Não. Isso tudo são as consequências de termos memória.



🧠 CAPÍTULO 1 — CPU RÁPIDA COM MEMÓRIA LENTA CONTINUA ESPERANDO

Comecemos pelo fundamento.

Um computador precisa essencialmente manipular instruções e dados.

A CPU executa instruções, mas essas instruções e os dados utilizados por elas precisam estar em algum lugar.

Imagine um cozinheiro absurdamente rápido.

Ele consegue preparar um prato em dez segundos.

Existe apenas um problema: os ingredientes chegam da despensa a cada cinco minutos.

Não adianta contratar um cozinheiro duas vezes mais rápido.

Ele continuará esperando o tomate.

Com processadores ocorre algo semelhante.

Podemos representar uma hierarquia simplificada assim:

CPU
 │
 ├── Registradores
 │
 ├── Cache L1
 │
 ├── Cache L2
 │
 ├── Cache L3
 │
 ├── RAM
 │
 ├── SSD / NVMe
 │
 └── armazenamento mais distante

Quanto mais próximo da CPU, normalmente encontramos memória:

  • mais rápida;

  • menor;

  • mais cara por byte.

Quanto mais distante:

  • maior;

  • mais barata por byte;

  • mais lenta.

Esse é um dos grandes compromissos da engenharia de computadores.

Queremos tudo ao mesmo tempo:

MUITA capacidade
+
MUITA velocidade
+
BAIXÍSSIMA latência
+
BAIXO consumo
+
persistência
+
BAIXO custo

Infelizmente, o vendedor dessa memória perfeita ainda não apareceu.



🏰 CAPÍTULO 2 — RAM NÃO É UMA COISA SÓ

RAM significa Random Access Memory.

“Acesso aleatório” não quer dizer que o computador escolhe posições aleatoriamente.

Significa que podemos acessar diferentes posições diretamente sem precisar percorrer sequencialmente tudo o que existe antes delas.

Existem diferentes tecnologias de RAM.

Duas são fundamentais para entender nossa história:

DRAM e SRAM.



💧 CAPÍTULO 3 — DRAM: A MEMÓRIA QUE PRECISA SER LEMBRADA DE NÃO ESQUECER

DRAM significa Dynamic Random Access Memory.

A ideia clássica de uma célula DRAM envolve essencialmente:

1 transistor
+
1 capacitor

O capacitor armazena carga elétrica.

O problema?

Capacitores não mantêm essa carga eternamente.

Ela vaza.

Portanto, a informação precisa ser periodicamente restaurada.

Esse processo chama-se:

refresh.

Imagine milhares de milhões de pequenos baldes furados.

Você coloca água neles.

Antes que esvaziem completamente, precisa verificar e restaurar os níveis correspondentes aos dados armazenados.

É uma analogia imperfeita, mas ajuda a visualizar a ideia.

A grande vantagem da DRAM é sua densidade.

Podemos colocar enorme quantidade de células numa determinada área de silício.

Consequentemente, ela se tornou excelente candidata para a memória principal dos computadores.



⚡ CAPÍTULO 4 — SRAM: CARA, RÁPIDA E PERTO DO CHEFE

SRAM significa Static Random Access Memory.

Ela não depende do mesmo mecanismo periódico de refresh da DRAM enquanto permanece energizada.

Uma célula SRAM tradicional pode utilizar uma estrutura com vários transistores, frequentemente associada ao modelo 6T, de seis transistores.

Isso significa mais componentes por bit.

Resultado:

SRAM
mais rápida
mais cara
menos densa

DRAM
mais lenta
mais barata
mais densa

Então alguém teve uma excelente ideia:

— E se colocarmos pequenas quantidades de SRAM muito rápida perto da CPU e grandes quantidades de DRAM como memória principal?

Bem-vindo ao mundo do cache.


🏎️ CAPÍTULO 5 — CACHE: NÃO MANDE JACK VOLTAR À CIDADE PARA BUSCAR UMA POÇÃO

Imagine Jack dentro de uma dungeon.

Ele utiliza constantemente:

  • espada;

  • poção;

  • mapa;

  • ferramentas.

Seria absurdo voltar à cidade cada vez que precisasse de uma poção.

Então ele carrega perto dele aquilo que provavelmente utilizará.

Cache funciona sob uma filosofia semelhante.

Processadores modernos possuem diferentes níveis:

CPU
 │
 ├─ L1
 │
 ├─ L2
 │
 └─ L3
      │
      RAM

Entram aqui dois conceitos importantíssimos.

Localidade temporal

Se usamos determinado dado agora, existe boa chance de utilizá-lo novamente em breve.

Localidade espacial

Se acessamos determinado endereço, existe boa chance de acessarmos dados próximos.

Considere:

PERFORM VARYING WS-I FROM 1 BY 1
        UNTIL WS-I > 1000
    ADD WS-VALOR(WS-I) TO WS-TOTAL
END-PERFORM

Percorrer estruturas de maneira previsível pode colaborar com mecanismos de cache e prefetch.

Essa é uma das razões pelas quais estruturas de dados não são apenas abstrações de programação.

Elas também possuem consequências físicas.

Seu COBOL vive muito acima dos transistores.

Mas os transistores continuam pagando a conta.


🏺 CAPÍTULO 6 — ROM: A BIBLIOTECA QUE SOBREVIVE AO POWER OFF

ROM significa Read Only Memory.

Historicamente, ROM descrevia memória não volátil cujo conteúdo permanecia armazenado mesmo sem alimentação.

Nas tradicionais Mask ROMs, o conteúdo era determinado durante a fabricação.

Isso funcionava muito bem para produtos produzidos em enorme escala.

Depois apareceram outras tecnologias.


🔥 CAPÍTULO 7 — PROM: QUEIME UMA VEZ

PROM significa:

Programmable Read Only Memory.

Ela podia ser programada depois da fabricação.

Porém, normalmente apenas uma vez.

Daí nasceu uma expressão clássica:

“queimar uma PROM”.

Depois de programada, não havia um confortável:

CTRL+Z

O hardware não conhecia arrependimento.


☀️ CAPÍTULO 8 — EPROM: COLOQUE O CHIP NO SOL... NÃO, NÃO FAÇA ISSO

EPROM significa:

Erasable Programmable Read Only Memory.

Ela podia ser apagada e novamente programada.

E aqui aparece uma das imagens mais famosas da eletrônica antiga: o chip com uma pequena janela de quartzo.

Através dela, luz ultravioleta apropriada podia ser utilizada para apagar a memória.

O processo era aproximadamente:

gravar
  ↓
testar
  ↓
deu errado
  ↓
retirar chip
  ↓
apagar com UV
  ↓
programar novamente

Muitos chips tinham um adesivo cobrindo aquela janela.

Não era decoração vintage.

A cobertura ajudava a evitar exposição indesejada.

Para um programador moderno acostumado a clicar em Update Firmware, isso parece arqueologia alienígena.

Mas foi revolucionário.


⚡ CAPÍTULO 9 — EEPROM E FLASH: FINALMENTE PARARAMOS DE PEGAR A LÂMPADA UV

EEPROM trouxe a possibilidade de apagar eletricamente a memória programável.

Flash desenvolveu essa família tecnológica em direção a maior densidade e operações adequadas ao armazenamento moderno.

É essa evolução que tornou perfeitamente normal atualizar firmware eletronicamente.

Daí chegamos aos sistemas modernos nos quais firmware pode ser atualizado sem retirar um chip da placa.

E aqui cabe uma correção histórica importante.

Dizer simplesmente:

“BIOS é uma ROM”

pode funcionar numa introdução histórica, mas é simplificação para máquinas modernas.

Hoje firmware é normalmente armazenado em memória Flash apropriada.

Além disso, PCs modernos utilizam predominantemente UEFI, sucessor arquitetural do BIOS tradicional.


🔋 CAPÍTULO 10 — CMOS NÃO É EXATAMENTE AQUILO QUE VOCÊ PENSA

Outro fóssil linguístico.

Muita gente aprendeu:

“CMOS é uma memória.”

CMOS significa:

Complementary Metal-Oxide-Semiconductor.

É fundamentalmente uma tecnologia de circuitos.

Nos PCs, memória e circuitos associados à configuração do firmware ficaram popularmente conhecidos como “CMOS”.

Daí expressões como:

CMOS Setup
CMOS Battery
Clear CMOS

Quando retiramos a bateria da placa-mãe, não estamos simplesmente “apagando o BIOS”.

Estamos interferindo na manutenção de configurações e no circuito RTC associado, conforme a implementação.

Essa diferença parece pequena.

Mas arquitetura de computadores é justamente a ciência de descobrir que todas as diferenças pequenas voltam para cobrar juros vinte anos depois.


🦕 CAPÍTULO 11 — DIP, SIPP, SIMM E DIMM: O JURASSIC PARK DA MEMÓRIA

Nas primeiras gerações de micros, chips DRAM podiam aparecer individualmente em encapsulamentos DIP.

Depois alguém percebeu:

— Talvez instalar um monte de chips individualmente não seja a melhor ideia do universo.

Surgiram módulos.

A evolução histórica passou por tecnologias como:

DIP
 ↓
SIPP
 ↓
SIMM
 ↓
DIMM

SIPP tinha pequenos pinos.

SIMM passou a utilizar contatos na borda do módulo.

Então tivemos os famosos SIMMs de 30 pinos.

Muitos deles forneciam caminho de dados de 8 bits.

Um 80386 com barramento de dados de 32 bits precisava de:

8 + 8 + 8 + 8 = 32

Logo:

quatro módulos.

Não era superstição da placa-mãe.

Era arquitetura.


🧮 CAPÍTULO 12 — POR QUE O PENTIUM QUERIA DOIS SIMMS?

SIMMs de 72 pinos normalmente ofereciam caminho de dados de 32 bits.

O Pentium clássico possuía barramento externo de dados de 64 bits.

Então:

32 + 32 = 64

Dois módulos.

Quando chegamos aos DIMMs com caminho de dados de 64 bits:

1 × 64 = 64

um único módulo podia satisfazer aquela largura.

Perceba a lição:

a forma física da memória acompanha a evolução da arquitetura.

O pente conta uma história.

Você só precisa saber lê-la.


🚀 CAPÍTULO 13 — SDRAM, DDR, DDR2, DDR3, DDR4, DDR5

A história obviamente não parou no DIMM de 168 pinos.

Vieram diferentes gerações:

SDRAM
  ↓
DDR
  ↓
DDR2
  ↓
DDR3
  ↓
DDR4
  ↓
DDR5

DDR significa Double Data Rate.

Com o passar das gerações, aumentaram dramaticamente largura de banda, densidade e sofisticação dos controladores.

Por isso aquela antiga comparação baseada apenas em:

60 ns
70 ns
80 ns

não descreve adequadamente a memória moderna.

Hoje precisamos considerar também:

  • MT/s;

  • latência;

  • timings;

  • canais;

  • ranks;

  • banks;

  • controladores;

  • padrão de acesso.

“Memória mais rápida” deixou de ser uma pergunta simples.

Mais rápida para fazer o quê?


🚚 CAPÍTULO 14 — LATÊNCIA NÃO É LARGURA DE BANDA

Imagine duas estradas.

Na primeira, o primeiro caminhão chega rapidamente, mas só passa um caminhão por vez.

Na segunda, o primeiro demora um pouco mais, mas depois chegam cem caminhões simultaneamente.

Temos duas propriedades diferentes.

Latência: quanto demoramos para começar a receber aquilo que pedimos.

Largura de banda: quanto conseguimos transportar por unidade de tempo.

Uma aplicação pode ser sensível a uma.

Outra, à outra.

E algumas conseguem sofrer com as duas.

Parabéns.

Você acaba de entrar oficialmente na engenharia de performance.


🐌 CAPÍTULO 15 — “ACABOU A RAM, USA O DISCO”

Essa frase é didaticamente útil, mas tecnicamente merece expansão.

Sistemas operacionais modernos trabalham com memória virtual.

Um processo trabalha com endereços virtuais.

Existe tradução desses endereços para recursos físicos.

Simplificando brutalmente:

Programa
   ↓
endereço virtual
   ↓
MMU
   ↓
tabelas de páginas
   ↓
memória física

Quando uma página necessária não está residente na memória física, pode ocorrer um page fault.

O sistema operacional toma as providências necessárias.

Em determinadas situações, dados precisam ser trazidos do armazenamento auxiliar.

O problema aparece quando isso ocorre excessivamente.

Temos o famoso:

thrashing.

A máquina trabalha freneticamente para administrar memória em vez de executar trabalho útil.

É como Jack passar a aventura inteira reorganizando a mochila.

Tecnicamente ocupado.

Heroicamente inútil.


🧙 CAPÍTULO 16 — “8 BITS SÓ ENDEREÇAM 256 BYTES”, CERTO?

Errado.

E esta é provavelmente a armadilha mais importante desta aula.

Se tivermos N bits de endereço, podemos representar:

2N2^N

posições.

Se cada posição identifica um byte:

2N bytes2^N\ bytes

Mas “CPU de 8 bits” não significa necessariamente “endereço de 8 bits”.

Processadores como Z80 e 6502 eram considerados de 8 bits, mas utilizavam endereçamento de 16 bits.

Logo:

216=65.5362^{16}=65.536

64 KB.

Portanto:

CPU: 8 bits
Endereço: 16 bits
Espaço: 64 KB

É por isso que máquinas de 8 bits podiam possuir dezenas de KB.


⚔️ CAPÍTULO 17 — 16 BITS: O 8086 E O REINO DE 1 MB

O Intel 8086 era uma CPU de 16 bits.

Mas possuía capacidade de produzir endereços físicos de 20 bits.

Então:

220=1.048.5762^{20}=1.048.576

1 MB.

Para conseguir isso utilizando seus registradores e sua arquitetura segmentada, o x86 utilizava pares segmento:offset.

Simplificadamente:

endereço físico =
segmento × 16 + offset

E daí nasceu uma quantidade impressionante de diversão arquitetural que futuras gerações tiveram o privilégio de herdar.


🧱 CAPÍTULO 18 — OS 640 KB QUE ASSOMBRARAM O DOS

O IBM PC e seus descendentes organizaram o espaço inferior de 1 MB reservando regiões para diferentes finalidades.

De maneira extremamente simplificada:

0 KB
│
│ memória convencional
│
640 KB
│
│ vídeo
│ hardware
│ ROMs
│ BIOS
│
1 MB

Daí surgiram termos lendários:

Conventional Memory
Upper Memory
EMS
XMS
HIMEM.SYS
EMM386

Quem configurou CONFIG.SYS e AUTOEXEC.BAT para liberar memória para jogos conhece um tipo de sofrimento que deveria valer créditos acadêmicos.


🏹 CAPÍTULO 19 — 80286: 16 BITS E 16 MB

Agora Jack colocou outra armadilha sobre a mesa.

O 80286 continuava sendo uma CPU fundamentalmente de 16 bits.

Mas seu endereçamento físico chegava a 24 bits.

Logo:

224=16.777.2162^{24}=16.777.216

16 MB.

Compare:

8086
CPU 16-bit
endereço 20-bit
1 MB

80286
CPU 16-bit
endereço 24-bit
16 MB

Conclusão:

o rótulo “16-bit” sozinho não determina a quantidade máxima de memória.

Guarde isso.

Vamos precisar dessa chave para abrir a dungeon do mainframe.


🏛️ CAPÍTULO 20 — IBM SYSTEM/360 E OS 24 BITS

Em 1964, a IBM apresentou a família System/360.

Aqui temos uma das decisões arquiteturais mais importantes da história da computação empresarial.

Embora seus registradores gerais tivessem 32 bits, o endereçamento original utilizava 24 bits.

Logo:

224=16MB2^{24}=16MB

Dezesseis megabytes.

Em 2026 isso parece quase uma piada.

Em 1964 era um espaço arquitetural gigantesco.

E mais importante:

essa decisão deixaria marcas que sobreviveriam por décadas.


👻 CAPÍTULO 21 — O FANTASMA DOS 16 MB AINDA VIVE

No universo IBM mainframe aparecem expressões como:

below the line

e

above the line.

A famosa 16 MB line é herança do endereçamento de 24 bits.

Visualmente:

0
│
│ BELOW THE LINE
│
16 MB
──────────────────
│
│ ABOVE THE LINE
│

Isso é arqueologia computacional viva.

Você pode estar estudando um ambiente moderno e encontrar terminologia originada em limitações arquiteturais de muitas décadas atrás.


🤨 CAPÍTULO 22 — IBM, POR QUE 31 BITS?

Depois do universo de 24 bits, a arquitetura IBM evoluiu para endereçamento de 31 bits.

Não 32.

Trinta e um.

O Padawan COBOL levantou a mão.

— Mestre Jack, alguém perdeu um bit?

— Não. Encontraram compatibilidade.

Historicamente, o bit mais significativo tinha implicações herdadas relacionadas ao modo de endereçamento e convenções de software.

A IBM precisava ampliar o espaço preservando compatibilidade.

Com 31 bits:

231=2.147.483.6482^{31}=2.147.483.648

2 GB.

Daí surge outra fronteira famosa:

2 GB Bar.


🍺 CAPÍTULO 23 — BELOW THE BAR E ABOVE THE BAR

Agora nosso mapa fica:

0
│
│ BELOW THE LINE
│
16 MB
────────────────── LINE
│
│ ABOVE THE LINE
│
│
2 GB
══════════════════ BAR
│
│ ABOVE THE BAR
│

A terminologia começa a fazer sentido.

Line: 16 MB.

Bar: 2 GB.

Não são nomes inventados apenas para atormentar o aluno.

São marcas da evolução da arquitetura.


🧭 CAPÍTULO 24 — AMODE 24, AMODE 31 E AMODE 64

No mainframe encontramos o conceito de Addressing Mode, ou AMODE.

Você pode encontrar referências a:

AMODE 24
AMODE 31
AMODE 64

Simplificando:

AMODE 24

O programa trabalha com endereçamento compatível com o universo de 24 bits.

Limite conceitual:

16 MB.

AMODE 31

Endereçamento de 31 bits.

Limite:

2 GB.

AMODE 64

Entramos no universo de endereçamento de 64 bits da z/Architecture.

O espaço potencial torna-se colossal.

E aqui Jack colocou uma placa na parede:

NÃO CONFUNDA ESPAÇO VIRTUAL COM RAM INSTALADA.

Voltaremos a ela.


💻 CAPÍTULO 25 — 80386 E O UNIVERSO DOS 4 GB

Nos PCs, o Intel 80386 marcou a consolidação do x86 de 32 bits.

Com 32 bits de endereço:

232=4.294.967.2962^{32}=4.294.967.296

aproximadamente:

4 GB.

É daí que vem o famoso limite associado aos sistemas x86 de 32 bits.

Mas novamente existe uma pegadinha.

Parte do espaço físico pode precisar ser utilizada para mapear dispositivos e regiões de hardware.

Por isso alguém podia instalar 4 GB e encontrar algo como:

3,x GB utilizáveis

em determinadas configurações e sistemas de 32 bits.

A RAM não tinha desaparecido misteriosamente.

O espaço de endereçamento estava sendo disputado.


🪄 CAPÍTULO 26 — PAE: 32 BITS COM MAIS DE 4 GB?

Sim.

Physical Address Extension, ou PAE, permitiu a determinados sistemas x86 de 32 bits utilizar endereçamento físico maior.

Com 36 bits físicos:

236=64GB2^{36}=64GB

Isso possibilitava administrar até 64 GB de memória física em implementações clássicas.

Mas atenção:

isso não transformava magicamente cada ponteiro de uma aplicação 32-bit num ponteiro linear de 36 bits.

O sistema operacional podia administrar memória física maior enquanto processos individuais continuavam sujeitos às características do espaço virtual da arquitetura.

Outra lição:

memória física e espaço virtual não são a mesma coisa.


🌌 CAPÍTULO 27 — 64 BITS: CHEGAMOS A 16 EXABYTES?

Matematicamente:

264=18.446.744.073.709.551.6162^{64}=18.446.744.073.709.551.616

bytes.

Isso equivale a aproximadamente:

16 exabytes, usando unidades binárias.

Então meu notebook 64-bit aceita 16 EB de RAM?

Não.

Calma, Padawan.

“Arquitetura de 64 bits” não significa que todos os 64 bits possíveis sejam necessariamente implementados para endereçamento físico em determinada CPU.

Existem vários limites:

arquitetura
     ↓
CPU implementada
     ↓
controlador de memória
     ↓
plataforma
     ↓
placa-mãe
     ↓
firmware
     ↓
sistema operacional
     ↓
processo

O menor limite aplicável vence.


🧮 CAPÍTULO 28 — A TABELA QUE O PADAWAN DEVE GUARDAR

A matemática fundamental é:

Bits de endereçoEspaço teórico
8256 bytes
1664 KB
201 MB
2416 MB
312 GB
324 GB
3664 GB
6416 EB

Mas NÃO leia isso como:

CPU 8-bit = 256 bytes
CPU 16-bit = 64 KB
CPU 32-bit = 4 GB

Isso seria errado.

Leia como:

N bits efetivamente utilizados como endereço byte-addressable oferecem 2^N bytes de espaço.

Essa pequena diferença separa decorar tabela de compreender arquitetura.


🏦 CAPÍTULO 29 — COBOL NÃO QUER SABER EM QUAL CAPACITOR ESTÁ WS-SALDO

Considere:

01 WS-CLIENTE.
   05 WS-CONTA        PIC 9(10).
   05 WS-SALDO        PIC S9(13)V99 COMP-3.

Você trabalha com:

WS-CONTA
WS-SALDO

Você não pergunta:

“Em qual chip DRAM está o nibble correspondente ao terceiro dígito do COMP-3?”

Ainda bem.

Existem várias camadas entre seu programa e a eletrônica.

Simplificadamente:

Programa COBOL
      ↓
linguagem / runtime
      ↓
Address Space
      ↓
endereço virtual
      ↓
tradução
      ↓
memória real
      ↓
hardware

No z/OS, um conceito fundamental nessa história é DAT — Dynamic Address Translation.

Ela participa da tradução entre os mundos virtual e real.

Isso permite uma abstração poderosa:

seu programa trabalha com endereços sem precisar conhecer a posição física dos componentes de memória.


🛡️ CAPÍTULO 30 — ECC: QUANDO UM BIT ERRADO PODE CUSTAR DINHEIRO

Memória física não é perfeita.

Erros podem acontecer.

Em ambientes corporativos, um bit errado pode ser muito mais sério do que uma tela azul num computador doméstico.

Imagine:

0000000000001000

sofrendo alteração indevida.

Dependendo do contexto, aquele bit pode representar parte de:

  • saldo;

  • índice;

  • ponteiro;

  • instrução;

  • registro;

  • estrutura interna.

Por isso servidores utilizam sofisticados mecanismos de detecção e correção de erros, incluindo tecnologias baseadas em ECC — Error Correcting Code.

No universo mainframe, confiabilidade de memória faz parte de uma filosofia muito maior de RAS:

Reliability, Availability and Serviceability.

Porque num sistema bancário:

“reinicia aí para ver se volta”

não é uma estratégia arquitetural particularmente elegante.


👻 CAPÍTULO 31 — ROWHAMMER: QUANDO A FÍSICA VIRA SEGURANÇA

Existe uma curiosidade fascinante envolvendo DRAM.

Pesquisadores descobriram que acessos repetidos e cuidadosamente organizados a determinadas linhas de memória poderiam, em certas tecnologias e circunstâncias, influenciar células próximas e provocar alterações de bits.

O fenômeno ficou conhecido como:

Rowhammer.

Observe a cadeia:

física
 ↓
transistores
 ↓
DRAM
 ↓
arquitetura
 ↓
sistema operacional
 ↓
segurança

Isso ensina algo precioso.

Cybersecurity não termina no código.

Às vezes o problema está vários andares abaixo dele.


🎮 CAPÍTULO 32 — VRAM NÃO É MAIS “A MEMÓRIA DA TELA”

Outro conceito que evoluiu dramaticamente.

Antigamente era relativamente razoável explicar memória de vídeo como a memória utilizada para representar aquilo que aparecia no monitor.

Hoje GPUs armazenam e manipulam:

framebuffers
texturas
geometria
shaders
buffers
modelos
dados computacionais
estruturas de IA

Tecnologias como GDDR e HBM atendem necessidades específicas de enorme largura de banda.

GPU deixou há muito tempo de ser simplesmente “a coisa que desenha pixels”.

E a memória acompanhou essa transformação.


🧪 CAPÍTULO 33 — PASSO A PASSO: COMO ANALISAR UM LIMITE DE MEMÓRIA

Quando alguém perguntar:

“Qual é o máximo de RAM desse sistema?”

não responda imediatamente.

Faça a investigação de Jack.

Passo 1 — Descubra a arquitetura

É:

8-bit?
16-bit?
32-bit?
64-bit?

Mas não pare aí.

Passo 2 — Descubra quantos bits de endereço são efetivamente implementados

Essa informação é muito mais importante para determinar o espaço endereçável.

Passo 3 — Separe virtual de físico

Pergunte:

Estamos falando de espaço virtual de um processo ou memória física instalada?

Passo 4 — Verifique o processador

A CPU pode implementar menos endereço físico do que o limite matemático da arquitetura sugere.

Passo 5 — Verifique a plataforma

Placa-mãe, chipset/controlador, sockets e slots impõem limites.

Passo 6 — Verifique o sistema operacional

O SO pode impor limites adicionais.

Passo 7 — Verifique a aplicação

Uma aplicação pode ter restrições próprias.

No mainframe, pergunte também sobre:

AMODE
RMODE
Address Space
Below/Above the Line
Below/Above the Bar

Agora você está fazendo arquitetura.

Não simplesmente lendo “64-bit” na embalagem.


📜 CAPÍTULO 34 — DUAS LINHAS DO TEMPO SE ENCONTRAM

Nos microcomputadores tivemos aproximadamente:

8-bit
 ↓
16-bit
 ↓
386 / 32-bit
 ↓
x86-64

Enquanto no universo IBM mainframe:

24-bit
 ↓
31-bit
 ↓
64-bit

Os caminhos são diferentes.

Os problemas fundamentais são semelhantes.

Precisamos:

  • representar endereços;

  • traduzir endereços;

  • proteger memória;

  • compartilhar recursos;

  • entregar dados rapidamente à CPU;

  • manter compatibilidade;

  • aumentar capacidade sem destruir o passado.

E talvez essa última característica seja especialmente importante no mainframe.


🏺 CAPÍTULO 35 — O MAINFRAME É UMA CIDADE CONSTRUÍDA SOBRE OUTRAS CIDADES

Essa é uma das melhores maneiras de compreender IBM Z.

Não imagine apenas uma máquina nova substituindo completamente a anterior.

Imagine Roma.

Você cava.

Encontra uma construção medieval.

Cava novamente.

Encontra Roma Imperial.

Mais fundo.

República.

No mainframe:

z/Architecture
      ↓
ESA
      ↓
370-XA
      ↓
System/370
      ↓
System/360

Conceitos modernos convivem com decisões históricas.

Daí encontramos:

24 bits
31 bits
64 bits

16 MB Line
2 GB Bar

AMODE 24
AMODE 31
AMODE 64

Não é bagunça.

É evolução com compatibilidade.


🥚 CAPÍTULO 36 — EASTER EGG: 03:17 NA WAR ROOM

Às 03:17 da madrugada, Jack encontrou o jovem programador COBOL olhando fixamente para o dump.

— O que aconteceu?

— Storage problem.

— Quanto storage?

— Não sei.

— Real ou virtual?

Silêncio.

— Below ou above the bar?

Silêncio maior.

— Qual AMODE?

O Padawan abriu outra tela.

Jack pegou o café.

— Então não temos um problema de storage.

— Não?

— Temos um problema de vocabulário.

Primeira regra da War Room:

dar nome correto ao problema reduz metade da dungeon.

A segunda regra é não executar restart antes de coletar evidências.

Mas essa fica para outro café.


☕ CAPÍTULO 37 — O QUE UM PROGRAMADOR COBOL DEVE REALMENTE APRENDER DISSO?

Você não precisa projetar uma célula DRAM para escrever COBOL.

Também não precisa decorar quantos pinos tinha cada SIMM fabricado em 1994.

Mas compreender essa história muda sua percepção do sistema.

Quando você vê:

STORAGE
ADDRESS
POINTER
AMODE
RMODE
PAGE
FRAME
CACHE
BUFFER

essas palavras deixam de ser feitiços encontrados num manual IBM.

Elas passam a fazer parte de um modelo mental.

E esse modelo começa muito abaixo do COBOL.


🧙 EPÍLOGO — JACK ENCONTROU O VERDADEIRO MONSTRO DA DUNGEON

O Padawan fechou o velho manual.

Agora a frase:

“Computadores atuais possuem normalmente 32 a 64 MB”

não parecia mais ridícula.

Parecia histórica.

Aquele texto havia atravessado uma era na qual:

386
486
Pentium
SIMM
DIMM
EPROM
BIOS
DRAM de dezenas de ns

representavam o estado da arte ou sua transição.

Depois vieram:

SDRAM
DDR
DDR2
DDR3
DDR4
DDR5
UEFI
NVMe
multicore
NUMA
virtualização
HBM
IA

Mas Jack apontou para a primeira frase do velho documento:

“Uma CPU veloz só terá eficiência se a memória for também veloz.”

Décadas depois, a batalha continuava.

Mudamos os processadores.

Mudamos os módulos.

Mudamos os barramentos.

Passamos de KB para MB, de MB para GB e de GB para TB.

Construímos cache sobre cache.

Criamos memória virtual.

Criamos prefetch.

Inventamos controladores inteligentes.

Saímos de 24 bits para 31.

De 31 para 64.

E mesmo assim, no fundo da máquina, o processador continua fazendo a mesma pergunta:

Cadê o meu dado?

Jack levantou a caneca.

— Agora você entendeu memória.

O Padawan sorriu.

— Entendi.

— Ótimo.

— Posso otimizar o programa?

Jack quase derrubou o café.

— Não.

— Por quê?

— Porque primeiro você mede.

Na tela da War Room apareceu:

03:17:00

CPU WAITING
CACHE MISS
PAGE FAULT

Jack apontou para o monitor.

— Está vendo?

— Sim.

— O computador mais moderno do mundo continua praticando a tradição mais antiga da informática.

— Qual?

Jack tomou o último gole.

Esperar alguém buscar o dado.

☕💾

Bellacosa Mainframe — porque antes de otimizar o COBOL, descubra em qual andar da dungeon está o gargalo.

sábado, 1 de março de 2008

📉 COBOL 3.xx vs COBOL 4.00 Clássico maduro vs clássico turbinado

 

Bellacosa Mainframe e o cobol 4.00

📉 COBOL 3.xx vs COBOL 4.00

Clássico maduro vs clássico turbinado


🕰️ Linha do tempo rápida

VersãoAnoContexto
COBOL 3.xx~2001Consolidação do LE
COBOL 4.00~2009Performance, Unicode, modernização

📌 COBOL 4 não foi ruptura — foi evolução com faca nos dentes.


🧠 Filosofia de cada versão

🧓 COBOL 3.xx

“Se está rodando, não mexe.”

  • Estável

  • Conservador

  • Performance previsível

  • Muito usado em batch crítico

🧑‍🚀 COBOL 4.00

“Roda igual, mas gasta menos MIPS.”

  • Otimizações agressivas

  • Melhor uso de hardware

  • Preparação para mundo moderno

  • Base para COBOL 5



⚙️ Runtime e arquitetura

ItemCOBOL 3.xxCOBOL 4.00
Language EnvironmentSimSim (mais maduro)
31 bitsDominanteAinda forte
64 bitsNãoPreparado
UnicodeLimitadoNativo (USAGE DISPLAY-1)
XMLBásicoMuito melhor

🥚 Easter egg:

COBOL 4 já pensa em 64 bits mesmo rodando em 31.


🚀 Performance e MIPS

📉 Onde o COBOL 4 ganha

  • Loop intensivo

  • Cálculos COMP/COMP-3

  • Manipulação de strings

  • I/O sequencial

📊 Média de ganho real:

5% a 25% menos MIPS
(depende do código e dos PARMs)

⚠ Onde não muda quase nada

  • Código ruim continua ruim

  • Lógica desorganizada

  • SORT mal usado


🧪 Parâmetros de compilação

COBOL 3.xx (clássico seguro)

DATA(31) OPTIMIZE(2) TRUNC(BIN) ARITH(EXTEND) MAP LIST

COBOL 4.00 (modo adulto)

DATA(31) OPTIMIZE(2) TRUNC(BIN) ARCH(8) ARITH(EXTEND) MAP LIST

🥚 Fofoquinha:

ARCH(8) é onde começa a economia de MIPS sem reescrever código.


🧟 Abends e problemas comuns

TipoCOBOL 3.xxCOBOL 4.00
S0C7Muito comumMenos frequente
S0C4ClássicoIgual
S878Configuração LEConfiguração LE
Performance ruimCódigoCódigo 😈

💬 Spoiler:

Migrar para COBOL 4 não corrige lógica ruim.


🧠 Diagnóstico e debug

ItemCOBOL 3COBOL 4
LIST/MAPSimSim
Debug LEBásicoMelhor
FerramentasLimitadasMais integração
RastreamentoManualMais amigável

🖥️ Hardware indicado

VersãoMainframes típicos
COBOL 3z900, z990
COBOL 4z9, z10, z196

📌 COBOL 4 começa a explorar melhor o silício.


🧬 Curiosidades Bellacosa™

  • COBOL 4 foi ignorado por anos por medo de mudança

  • Quem migrou cedo economizou MIPS silenciosamente

  • Muitos shops pularam direto do 3 para o 5 (e sofreram)

🥚 Easter egg clássico:

COBOL 4 é o “melhor custo-benefício” da história do COBOL.


🧑‍🎓 Padawan: quando migrar?

Migre para COBOL 4 se:

✔ Está em 3.xx
✔ Quer reduzir MIPS
✔ Não quer risco alto
✔ Quer preparar o terreno

Não espere milagres se:

❌ Código é caótico
❌ JCL é desleixado
❌ LE é default


🧠 Resumo executivo (para levar ao chefe)

CritérioVencedor
EstabilidadeEmpate
PerformanceCOBOL 4
ModernizaçãoCOBOL 4
RiscoEmpate
Base para futuroCOBOL 4

🏁 Conclusão Bellacosa™

“COBOL 3 é confiável.
COBOL 4 é confiável e mais barato.”


https://eljefemidnightlunch.blogspot.com/2007/01/o-que-e-logica-de-programacao-em.html

 

 

quarta-feira, 26 de dezembro de 2007

🟦 IBM Mainframe & COBOL 4.00

 


🟦 IBM Mainframe & COBOL 4.00

O elo entre o COBOL clássico e o mundo moderno

“COBOL 4 não é ruptura.
É a IBM dizendo: ‘vamos modernizar… sem quebrar nada’.”

— Bellacosa, depois de recompilar 3 milhões de linhas


🧬 Contexto histórico: onde o COBOL 4.00 se encaixa

O Enterprise COBOL for z/OS 4.0 faz parte da família COBOL 4.x, que surgiu no início da década de 2010, num momento crítico:

  • Mainframes mais poderosos (z10, z196)

  • Arquitetura 64 bits amadurecendo

  • Pressão por performance, modernização e integração

  • COBOL 3 ainda dominante… mas envelhecendo

👉 O COBOL 4 não veio para “mudar a linguagem”.
Veio para mudar o compilador.


📅 Data de lançamento (contexto realista)

  • Enterprise COBOL for z/OS 4.0: final de 2007 e primordios da primeira década de 2010.

  • Consolidação real aconteceu nas versões 4.1 / 4.2

  • Foi o degrau obrigatório antes do COBOL 5.x

💡 Tradução Bellacosa:

Se você saiu do COBOL 3 direto para o 5, o 4 foi o “meio do caminho” que você pulou… e pagou depois.



🖥️ Equipamentos mainframe indicados

COBOL 4 foi feito para explorar hardware moderno da IBM:

Mainframes ideais:

  • IBM z10

  • IBM z196

  • IBM zEC12

  • Totalmente compatível com zEnterprise

Por quê?

Porque o COBOL 4:

  • Gera código mais otimizado

  • Explora melhor o pipeline do processador

  • Se beneficia de novas instruções de CPU

🥚 Easter-egg:

Recompilar COBOL antigo em COBOL 4 sem mudar uma linha já dava ganho de performance.


🔄 O que muda em relação ao COBOL 3.x?

🧠 1️⃣ Compilador totalmente redesenhado

  • Novo backend

  • Melhor otimização de código

  • Melhor uso de registradores

👉 O código fonte parece igual.
👉 O código objeto não é.


⚙️ 2️⃣ Melhor suporte a arquitetura moderna

  • Preparação para 64 bits

  • Melhor alinhamento de dados

  • Base para o futuro COBOL 5 (LE-only)


📊 3️⃣ Performance real

  • Redução de CPU em batch

  • Melhor performance em loops

  • Melhor otimização de PERFORM

🥚 Easter-egg:

Muitos shops recompilaram só para economizar MIPS.


🧨 4️⃣ Mais rigor (menos permissividade)

Alguns “pecados antigos” começaram a ser cobrados:

  • Dados mal definidos

  • Uso implícito perigoso

  • Código que “sempre funcionou” 😅

👉 COBOL 4 começa a expor bugs escondidos há 20 anos.


🧪 Exemplo simples (nada muda… mas muda tudo)

IDENTIFICATION DIVISION. PROGRAM-ID. EXEMPLO4. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS-TOTAL PIC 9(9) VALUE 0. PROCEDURE DIVISION. PERFORM 10 TIMES ADD 1 TO WS-TOTAL END-PERFORM DISPLAY WS-TOTAL STOP RUN.

➡ Em COBOL 3: funciona
➡ Em COBOL 4: funciona mais rápido

💡 O ganho está no objeto gerado, não no código.


🛠️ Dicas técnicas Bellacosa Approved™

✔ Recompile, mesmo sem modernizar

  • COBOL 4 já entrega valor só na recompilação

✔ Use parâmetros certos:

  • OPTIMIZE

  • ARCH

  • SSRANGE (para pegar erro escondido)

✔ Teste batch crítico

  • Principalmente cálculos

  • Principalmente datas

  • Principalmente arredondamentos

✔ Compare CPU antes/depois

  • Você vai se surpreender


⚠️ Armadilhas clássicas

🚨 Código que dependia de comportamento indefinido
🚨 Campos mal alinhados
🚨 MOVE CORRESPONDING em estruturas duvidosas
🚨 Arredondamento implícito não documentado

🥚 Easter-egg cruel:

COBOL 4 não cria bug.
Ele revela.


🧠 Curiosidades de bastidor

  • COBOL 4 foi o primeiro passo sério rumo ao LE-only

  • Muitas empresas ficaram “presas” no 4 por anos

  • Ele é visto como a versão mais estável da transição

  • Serviu de base para o radical COBOL 5


🧘 Primeiros passos para o Padawan

Se você está começando agora:

1️⃣ Entenda COBOL clássico primeiro
2️⃣ Saiba compilar e linkar
3️⃣ Entenda parâmetros de compilação
4️⃣ Recompile código antigo e observe
5️⃣ Leia o listing — ele ensina mais que o código

“Quem lê o listing, domina o mainframe.”


🧠 Visão Bellacosa Final™

O COBOL 4.00 não é famoso.
Não é revolucionário.
Não é hype.

Mas ele é:

  • Estável

  • Inteligente

  • O verdadeiro ponto de virada técnico do COBOL moderno

Se o COBOL fosse uma saga:

  • COBOL 3 = trilogia clássica

  • COBOL 4 = o episódio de transição

  • COBOL 5 = o reboot corajoso

E lembre-se, Padawan:

“Modernizar não é reescrever.
É entender o que funciona… e deixar melhor.”

 

segunda-feira, 15 de janeiro de 2007

O que é “Acima da Linha”, “Acima da Barra” e Endereçamento de Memória 24, 31 e 64 bits no Mainframe?

 

Bellacosa Mainframe e a memoria em mainframe

O que é “Acima da Linha”, “Acima da Barra” e Endereçamento de Memória 24, 31 e 64 bits no Mainframe?

Esse é um dos temas mais importantes — e mais misteriosos — do mundo z/OS.

Quando alguém começa a estudar:

  • JES2;

  • CICS;

  • DB2;

  • storage;

  • performance;

  • programação assembler;

rapidamente encontra frases como:

  • “rodando acima da linha”;

  • “storage abaixo da linha”;

  • “memória acima da barra”.

No começo parece extremamente confuso.

Mas tudo gira em torno de:

como o mainframe organiza memória.


Primeiro: o que é memória no mainframe?

Memória é o espaço usado para:

  • programas;

  • variáveis;

  • buffers;

  • controle do sistema;

  • áreas de trabalho.

O z/OS gerencia isso de forma extremamente organizada.


O problema histórico

Os primeiros mainframes possuíam pouca memória.

Então a IBM criou limites de endereçamento.

Com o tempo:

  • mais memória surgiu;

  • novos limites foram criados;

  • o z/OS evoluiu mantendo compatibilidade histórica.

Resultado:
existem vários “níveis” de memória.


O que significa “endereçamento”?

Endereçamento é:

a capacidade de localizar posições de memória.

Quanto mais bits:

  • maior espaço de memória acessável.


Analogia simples

Imagine memória como:

uma cidade cheia de casas.

O endereço informa:

  • qual casa acessar.

Quanto mais dígitos no endereço:

  • mais casas podem existir.


Endereçamento de 24 bits

Foi um dos primeiros modelos do mainframe.


Quanto consegue endereçar?

2^{24}=16.777.216

Aproximadamente:

16 MB


Isso criou a famosa:

Linha dos 16 MB


O que é “abaixo da linha”?

Toda memória:

abaixo de 16 MB.


O que é “acima da linha”?

Toda memória:

acima de 16 MB.


Visualmente

0 MB
│
├── Abaixo da linha
│
16 MB  ← A LINHA
│
├── Acima da linha
│

Por que isso é importante?

Muitos programas antigos foram escritos para:

memória de 24 bits.

Eles só conseguem trabalhar:

  • abaixo da linha.


Problema clássico

A região abaixo da linha virou:

extremamente disputada.

Porque:

  • sistema;

  • CICS;

  • buffers;

  • programas antigos;

todos queriam espaço ali.


Então surgiu o endereçamento 31 bits

A IBM expandiu o espaço de memória.


Quanto consegue endereçar?

2^{31}=2.147.483.648

Aproximadamente:

2 GB


Mas por que não 32 bits?

Porque 1 bit era usado para controle interno.

Então o z/OS adotou:

31 bits efetivos.


Resultado

Agora existia:

  • memória abaixo da linha;

  • memória acima da linha.

Muito mais espaço disponível.


Visualmente

0 MB
│
├── Abaixo da linha
│
16 MB ← Linha
│
├── Acima da linha
│
2 GB

Então nasceu a “barra”

Quando o z/OS evoluiu novamente para 64 bits, surgiu:

a barra dos 2 GB.


Acima da barra

Tudo acima de:

2 GB.


Visualmente

0 MB
│
├── Abaixo da linha
│
16 MB ← Linha
│
├── Acima da linha
│
2 GB ← Barra
│
├── Acima da barra
│

Endereçamento 64 bits

Com 64 bits, o espaço cresce absurdamente.


Quantidade teórica

2^{64}=18.446.744.073.709.551.616

Quantidade gigantesca de memória.


Resultado prático

O z/OS moderno consegue trabalhar com:

  • enormes caches;

  • gigantescos bancos de dados;

  • workloads massivos;

  • analytics;

  • Java;

  • Linux on Z.


Então resumindo

ConceitoLimite
24 bits16 MB
31 bits2 GB
64 bitsmemória gigantesca

O que é “abaixo da linha”?

Memória:

abaixo de 16 MB.

Muito usada por:

  • programas antigos;

  • áreas críticas do sistema.


O que é “acima da linha”?

Memória:

entre 16 MB e 2 GB.

Usada por:

  • aplicações modernas 31 bits;

  • CICS;

  • DB2;

  • subsistemas.


O que é “acima da barra”?

Memória:

acima de 2 GB.

Usada por:

  • Java;

  • grandes caches;

  • DB2 moderno;

  • aplicações 64 bits.


O que significa storage constraint?

Problema de falta de memória.

Muito comum:

abaixo da linha.


Por que abaixo da linha é crítico?

Porque:

  • espaço pequeno;

  • muitos componentes disputam memória.

16 MB hoje parece minúsculo.


Exemplo clássico

CICS antigos sofriam muito com:

storage below the line.


Como isso aparece no dia a dia?

Mensagens como:

  • SOS;

  • storage shortage;

  • below the line exhausted.


O que é AMODE?

Addressing Mode

Define:
como o programa trabalha com memória.


Exemplos


AMODE 24

Programa trabalha em:
24 bits.


AMODE 31

Programa usa:
31 bits.


AMODE 64

Programa moderno usa:
64 bits.


O que é RMODE?

Residency Mode

Define:
onde o programa deve residir.


Exemplo

RMODE 24

Programa precisa ficar:
abaixo da linha.


Isso ainda existe?

Muito.

Principalmente em:

  • sistemas legados;

  • assembler;

  • módulos antigos.


Curiosidades incríveis

1. Muitos sistemas críticos ainda possuem código 24 bits

Décadas depois.


2. O z/OS mantém compatibilidade histórica absurda

Programas antigos ainda funcionam.


3. “Abaixo da linha” virou expressão clássica no mainframe


4. O endereçamento 64 bits revolucionou o z/OS moderno

Especialmente DB2 e Java.


Erros comuns de iniciantes


1. Pensar que “linha” é física

Ela é apenas:

um limite lógico de memória.


2. Confundir linha e barra

Linha:
16 MB.

Barra:
2 GB.


3. Achar que 24 bits morreu

Ainda existe muito software legado.


4. Ignorar AMODE/RMODE

Isso pode causar erros graves em assembler e linkedição.


Como isso aparece no JCL e programas?

Em:

  • binder;

  • assembler;

  • parâmetros LE;

  • CICS;

  • DB2;

  • dumps;

  • performance tuning.


Por que aprender isso?

Porque isso explica:

  • arquitetura do z/OS;

  • compatibilidade histórica;

  • gestão de memória;

  • performance;

  • problemas clássicos do mainframe.


Resumo rápido

TermoSignificado
Abaixo da linha< 16 MB
Acima da linha16 MB até 2 GB
Acima da barra> 2 GB
24 bitsaté 16 MB
31 bitsaté 2 GB
64 bitsenorme espaço
AMODEmodo de endereçamento
RMODEonde o programa reside

Conclusão

Os conceitos de:

  • abaixo da linha;

  • acima da linha;

  • acima da barra;

  • endereçamento 24, 31 e 64 bits

fazem parte da evolução histórica da memória no z/OS.

Eles mostram como o mainframe IBM conseguiu evoluir durante décadas mantendo compatibilidade com aplicações antigas enquanto expandia capacidade para workloads modernos gigantescos.


segunda-feira, 16 de setembro de 2002

☕ Bellacosa Mainframe Blog — z/OS 1.4: A Consolidação da Era 64 bits e a Maturidade da z/Architecture

 





☕ Bellacosa Mainframe Blog — z/OS 1.4: A Consolidação da Era 64 bits e a Maturidade da z/Architecture
Por Vagner Bellacosa — Café quente, spool limpo e memória virtual de sobra


🕰️ z/OS 1.4 – O equilíbrio entre estabilidade e inovação

O z/OS 1.4, lançado oficialmente em outubro de 2003, marcou o fechamento do primeiro ciclo de maturação do novo sistema operacional da IBM.
Se o z/OS 1.0 (2000) foi o nascimento da z/Architecture, o 1.4 foi o momento em que o mainframe se estabilizou em 64 bits, ganhou robustez corporativa, e começou a se integrar de forma mais natural com o mundo distribuído — redes, Java, web e segurança digital.

Essa versão estreou junto com o IBM z990 (System z9 “T-Rex”), trazendo uma combinação de força bruta e refinamento técnico que consolidou o mainframe como plataforma universal de TI corporativa.


⚙️ Ficha técnica — z/OS 1.4

CategoriaDetalhes
Lançamento oficialOutubro de 2003
Hardware de referênciaIBM z990 (System z9 EC)
Arquiteturaz/Architecture 64 bits madura
Versões JESJES2 1.13 / JES3 1.13
Modo de endereçamento24, 31 e 64 bits simultâneos
Kernel / Base MVSMVS núcleo estabilizado com z/OS UNIX Services aprimorado
Firmware PR/SMNível 70.x – com suporte a Dynamic LPAR Resource Management
Gerenciamento de CPUCréditos dinâmicos com balanceamento automático via WLM
Uso de memóriaExpansão plena de real storage 64-bit com suporte a “Large Pages”
SegurançaRACF 1.9 e z/OS Security Server
Rede / TCP/IPIPv4 otimizado, início do suporte a IPv6
Subsistemas chaveDB2 V8, CICS TS 2.3, IMS 8, WebSphere 5.0, MQSeries 5.3
Ambiente UNIXHFS consolidado e início da transição para zFS

🚀 O que mudou em relação ao z/OS 1.3

O z/OS 1.3 (2002) já tinha estabilizado o modo 64-bit, mas ainda dependia de ajustes na performance e integração com workloads mistos.
O 1.4 trouxe grandes mudanças no núcleo e nos serviços de sistema, como:

  1. Melhorias em gerenciamento de memória 64-bit

    • Introdução de Large Pages (1MB), reduzindo page faults e aumentando a eficiência em aplicações Java e DB2.

    • Novos algoritmos de Real Storage Manager (RSM) para cache em memória expandida.

  2. PR/SM aprimorado (Processor Resource/System Manager)

    • Agora com Dynamic LPAR Resource Management, permitindo redistribuição automática de CPUs e memória entre partições sem reinicialização.

    • Implementação de LPAR groups e políticas de CPU weight dinâmico — o embrião do que seria o Shared Processor Pools no z10.

  3. Suporte a novas instruções de máquina z990

    • Instruções avançadas para criptografia AES, compressão, e inteiros de 64 bits otimizados.

    • Introdução do HiperDispatch experimental, melhorando a afinidade CPU-thread.

    • Melhoria em instruções de E/S para FICON e OSA-Express2 (rede gigabit).

  4. Nova camada de segurança

    • O RACF 1.9 passou a integrar o LDAP nativamente, facilitando autenticação unificada.

    • Introdução do z/OS Security Server como produto-base.

    • Criptografia SSL acelerada via CPACF (Crypto Processor Assist Facility) do z990.

  5. Otimização de Workload Manager (WLM)

    • Novo modo Goal Mode adaptativo, com redistribuição automática de recursos por performance class.

    • Integração nativa com Sysplex Distributor, abrindo caminho para balanceamento de cargas TCP/IP em larga escala.


🧠 Avanços em memória e performance

O z/OS 1.4 trouxe uma das maiores evoluções em real storage management desde o MVS/ESA.
A IBM aprimorou o RSM (Real Storage Manager) e introduziu o conceito de dataspaces expandidos em 64 bits, permitindo:

  • Maior isolamento entre aplicações batch, CICS e USS;

  • Cache persistente para DB2 e VSAM em memória real;

  • Redução drástica de page swapping;

  • Uso de hiperspaces 64-bit para armazenar tabelas de alta frequência.

O impacto disso foi enorme: aplicações como DB2 V8 e CICS TS 2.3 atingiram ganhos de 20 a 35% de throughput em relação à versão anterior, apenas pela nova forma de gestão de memória.


🔌 Integração e aplicações internas

O z/OS 1.4 trouxe a maturidade das camadas de integração corporativa:

  • UNIX System Services (USS) mais estável e rápido, com suporte pleno a threads POSIX 64-bit;

  • Java SDK 1.4.1 integrado com suporte a Just-In-Time (JIT) otimizado para Telum e CPACF;

  • WebSphere Application Server V5 nativo;

  • z/OSMF ainda não existia, mas o RMF Monitor III ganhou interface mais amigável e ferramentas de diagnóstico refinadas.

No backend, DB2 V8 ganhou suporte total a Unicode e 64-bit buffers, e o IMS 8 evoluiu para melhor desempenho em message queues.


🔐 Segurança, rede e conectividade

O z/OS 1.4 consolidou a IBM como líder em segurança corporativa:

  • Introdução do Integrated Cryptographic Service Facility (ICSF) compatível com novos processadores cripto do z990.

  • Melhorias em SSL/TLS e RACF Digital Certificate Management.

  • TCP/IP Stack revisada — melhor throughput, NAT, IPv6 experimental, e melhor integração com Sysplex Distributor.

A pilha de rede já operava em modo multi-stack, o que significava que uma única LPAR podia servir múltiplos contextos TCP/IP, algo essencial para ambientes com múltiplos clientes.


⚙️ Firmware PR/SM e créditos de CPU

O PR/SM (hypervisor de hardware) passou a operar com Dynamic Resource Balancing, alocando CPU e memória com base no workload WLM.
Foi aqui que surgiram os créditos dinâmicos de CPU, mecanismo que mede o “crédito” de uso de partições e ajusta o peso de cada uma sem interrupção — o ancestral do Dynamic Capacity Upgrade on Demand (CUoD).

Isso trouxe dois ganhos imediatos:

  • Melhor aproveitamento da CPU física (menos idle time).

  • Redução de custos de licenciamento (LPARs mais equilibradas).


☕ Curiosidades e bastidores Bellacosa

  • O z/OS 1.4 foi a última versão da linha 1.x antes da chegada do z/OS 1.5, que seria o precursor direto do z/OS 2.1.

  • Internamente na IBM, essa versão era apelidada de “Rock Solid Release”, devido à sua estabilidade absurda — muitas empresas permaneceram nela por mais de uma década.

  • Foi também o primeiro z/OS amplamente adotado em bancos e seguradoras como plataforma de e-business.

  • O WebSphere 5.0 foi o primeiro middleware certificado para rodar 100% dentro do USS em produção crítica.

  • Alguns programadores veteranos brincavam:

    “No z/OS 1.4, você liga o café, e o IPL termina antes de esfriar.”


🔍 Resumo técnico comparativo

Itemz/OS 1.3z/OS 1.4
Arquitetura64 bits (inicial)64 bits madura
PR/SMEstático com updatesDinâmico (realocação sem IPL)
WLMGoal Mode básicoGoal Mode adaptativo
MemóriaPadrão 4K pagesSuporte a Large Pages (1MB)
RACFv1.8v1.9 + LDAP
CriptografiaCPACF inicialCPACF AES + SSL integrado
Java1.31.4.1 + JIT
TCP/IPIPv4IPv4 + IPv6 parcial
USSThreads limitadasMulti-thread 64-bit

🧭 Conclusão Bellacosa

O z/OS 1.4 foi o ponto de inflexão que transformou o mainframe moderno em uma plataforma realmente integrada, segura e escalável.
Foi ali que o casamento entre hardware (z990) e software (z/OS) atingiu maturidade plena, pavimentando o caminho para a automação e virtualização avançada que conhecemos hoje.

“Enquanto o mercado falava de servidores Linux, o z/OS 1.4 já entregava uptime de 99,999%, criptografia em hardware e Java nativo em 2003. O resto do mundo ainda estava acordando; o mainframe já estava tomando o segundo café.” ☕


 

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