Bellacosa Mainframe e fundamentos da informatica

☕ Um Café no Bellacosa Mainframe

🧪 SENKU E A DUNGEON DOS FUNDAMENTOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE O IF TINHA BILHÕES DE TRANSISTORES ESCONDIDOS

CPU, ALU, registradores, memória, cache, binário, hexadecimal, EBCDIC, sistemas operacionais, redes, bancos de dados, SQL, virtualização, cloud, containers — e o dia em que Senku Ishigami decidiu reconstruir a Ciência da Computação, uma abstração de cada vez.

---

🎬 PRÓLOGO — DEZ BILHÕES POR CENTO CERTEZA DE QUE NÃO É MAGIA

Imagine a situação.

Você acabou de entrar no mundo do mainframe.

Aprendeu seus primeiros comandos COBOL:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PEDRA001.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-SALDO       PIC 9(7)V99 VALUE 1000.00.
       01 WS-COMPRA      PIC 9(7)V99 VALUE 150.00.

       PROCEDURE DIVISION.

           IF WS-SALDO >= WS-COMPRA
               DISPLAY 'COMPRA AUTORIZADA'
           ELSE
               DISPLAY 'SALDO INSUFICIENTE'
           END-IF.

           STOP RUN.

Compilou.

Executou.

Funcionou.

Você olha para a tela e pensa:

“Entendi. O computador comparou dois números.”

Nesse momento, Senku Ishigami, de Dr. Stone, provavelmente apareceria carregando alguma engenhoca feita com pedras, fios, ácido sulfúrico e uma quantidade suspeita de confiança científica.

— Errado!

Não porque o programa esteja errado.

Mas porque entre:

IF WS-SALDO >= WS-COMPRA

e:

COMPRA AUTORIZADA

existe uma civilização inteira.

CPU.

Registradores.

Cache.

RAM.

Sistema operacional.

Memória virtual.

Encoding.

Storage.

Compilador.

Instruções de máquina.

Talvez Db2.

Talvez CICS.

Talvez MQ.

Talvez TCP/IP.

Talvez uma API.

Talvez outro computador do outro lado do planeta.

A melhor maneira de entender fundamentos de computação, portanto, não é decorar vinte definições para uma prova.

É fazer algo muito mais próximo da filosofia de Dr. Stone:

reconstruir o computador conceitualmente, camada por camada.

Pegue uma pedra.

Depois outra.

Depois eletricidade.

Depois lógica.

Depois memória.

Depois software.

Quando terminarmos nossa dungeon, aquela pequena instrução COBOL nunca mais parecerá tão pequena.

---

🪨 CAPÍTULO 1 — ANTES DO COBOL EXISTIA A PEDRA

Vamos começar do absoluto zero.

O que é um computador?

Uma definição introdutória bastante útil seria:

Um computador é uma máquina eletrônica programável capaz de receber dados, processá-los, armazená-los e produzir resultados.

Temos então:

INPUT
  ↓
PROCESSING
  ↓
OUTPUT
  ↓
STORAGE

Um teclado fornece entrada.

A CPU processa.

Um monitor apresenta saída.

Um dispositivo de armazenamento preserva dados.

Essa explicação funciona.

Mas Senku provavelmente perguntaria:

— O que significa processar?

E aí começa nossa aventura.

Processar significa transformar um estado em outro seguindo regras.

Considere:

SALDO = 1000
COMPRA = 150

O computador recebe esses valores e executa determinada transformação.

Depois:

SALDO = 850

Nada disso possui significado financeiro para a CPU.

Para ela não existem:

clientes, salários, boletos, cartões, parcelas ou financiamento.

Existem representações.

Nós, humanos, construímos significado em cima delas.

Essa diferença entre dado e informação é importante.

Considere:

80
90
70

São dados.

Quando aplicamos uma regra:

(80 + 90 + 70) / 3 = 80

produzimos algo interpretável:

MÉDIA = 80

O processamento transformou dados em informação útil dentro de determinado contexto.

É exatamente isso que sistemas empresariais fazem bilhões de vezes.

---

⚡ CAPÍTULO 2 — SENKU DESCOBRE O BIT

Precisamos agora construir nosso computador.

Infelizmente ainda não temos COBOL.

Nem Windows.

Nem z/OS.

Nem sequer uma CPU.

Temos eletricidade.

Precisamos representar informação fisicamente.

Uma solução extraordinariamente poderosa é trabalhar com dois estados.

Conceitualmente:

0
1

Nasce o bit, abreviação de binary digit.

Um bit pode representar duas possibilidades.

Com dois bits:

00
01
10
11

temos quatro combinações.

Com três:

000
001
010
011
100
101
110
111

oito combinações.

A fórmula geral é:

2ⁿ

Com 8 bits:

2⁸ = 256

combinações possíveis.

Oito bits formam convencionalmente um byte.

Agora já podemos representar números.

---

🔢 CAPÍTULO 3 — O PROGRAMADOR COBOL ENTRA NA DUNGEON DO BINÁRIO

Nós utilizamos normalmente base decimal:

347

Na verdade isso significa:

3 × 10² +
4 × 10¹ +
7 × 10⁰

ou:

300 + 40 + 7

Binário funciona exatamente da mesma maneira, apenas utilizando base 2.

Considere:

1011₂

Temos:

1 × 2³ = 8
0 × 2² = 0
1 × 2¹ = 2
1 × 2⁰ = 1

Portanto:

1011₂ = 11₁₀

Não há magia.

É apenas um sistema posicional com outra base.

---

🧙 CAPÍTULO 4 — SURGE O HEXADECIMAL

Imagine analisar:

110101101101101111101111

Depois de algumas horas, até Senku pediria café.

Por isso hexadecimal é tão conveniente.

Ele utiliza base 16:

0 1 2 3 4 5 6 7 8 9 A B C D E F

A grande vantagem é:

um dígito hexadecimal representa exatamente quatro bits.

Assim:

1111₂ = F₁₆

E:

11111111₂ = FF₁₆

Para um programador mainframe, hexadecimal não é apenas matéria escolar.

Quando começamos a analisar dumps, campos, bytes e problemas de dados, ele pode se transformar numa ferramenta cotidiana.

Dica de Padawan COBOL:

aprenda hexadecimal antes de precisar dele em produção às 03:17.

Sim, 03:17.

Guarde esse horário.

Toda dungeon precisa de um easter egg.

---

🧪 CAPÍTULO 5 — CPU: O LABORATÓRIO DE SENKU

Agora precisamos de algo capaz de executar operações.

Chegamos à CPU — Central Processing Unit.

Materiais introdutórios normalmente apresentam três componentes conceituais:

CPU
├── ALU
├── Control Unit
└── Registers

A ALU — Arithmetic and Logic Unit executa operações aritméticas e lógicas.

Exemplos:

+
-
*
/
AND
OR
NOT
>
<
=

A Control Unit coordena a execução das instruções.

Os registradores são pequenas áreas de armazenamento extremamente rápidas dentro do processador.

Podemos imaginar o ciclo clássico:

FETCH
 ↓
DECODE
 ↓
EXECUTE
 ↓
FETCH...

Primeiro a CPU busca uma instrução.

Depois descobre o que aquela instrução significa.

Finalmente executa a operação correspondente.

É uma simplificação, naturalmente.

Processadores modernos possuem pipelines, múltiplas unidades de execução, predição de desvios, execução especulativa e inúmeros outros mecanismos.

Mas nosso modelo é excelente para começar.

---

🧮 CAPÍTULO 6 — A ALU NÃO SABE O QUE É DINHEIRO

Aqui aparece algo fascinante para quem vem do COBOL.

Considere:

01 WS-PRECO PIC S9(7)V99 COMP-3.

COMP-3 indica uma representação decimal compactada (packed decimal).

Por que isso interessa?

Porque computadores são naturalmente excelentes em binário, enquanto aplicações comerciais frequentemente precisam lidar cuidadosamente com decimal.

Dinheiro é o exemplo clássico.

Em algumas representações de ponto flutuante binário, valores decimais aparentemente simples não possuem representação exata.

Para aplicações científicas isso pode ser perfeitamente administrável.

Mas:

R$ 1.000.000,00

não é o tipo de número no qual o banco gostaria de descobrir um centavo filosófico surgido por aproximação.

A computação empresarial desenvolveu durante décadas mecanismos especializados para aritmética decimal.

COBOL está profundamente ligado a essa história.

---

🏎️ CAPÍTULO 7 — REGISTRADORES, CACHE, RAM E A CORRIDA PELA MEMÓRIA

A CPU é extremamente rápida.

Mas existe um problema:

buscar dados custa tempo.

Por isso computadores possuem uma hierarquia de memória.

Simplificando:

        REGISTRADORES
             ↓
            L1
             ↓
            L2
             ↓
            L3
             ↓
            RAM
             ↓
         SSD / DASD
             ↓
      armazenamento remoto

Quanto mais próximo da CPU, normalmente temos:

mais velocidade
menos capacidade
maior custo por byte

Quanto mais distante:

mais capacidade
maior latência
menor custo relativo

A cache explora principalmente duas propriedades muito interessantes dos programas.

Localidade temporal

Se você acabou de utilizar determinado dado, talvez precise dele novamente.

Localidade espacial

Se acessou determinado endereço, provavelmente poderá acessar dados próximos.

Considere:

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

O acesso sequencial pode apresentar comportamento bastante favorável à hierarquia de memória.

Isso nos ensina algo importante:

performance não depende somente do número de linhas do programa.

O modo como acessamos memória e dados importa.

---

💾 CAPÍTULO 8 — RAM NÃO É DISCO

Outra confusão comum entre iniciantes:

“Meu computador tem 16 GB de memória e 1 TB de memória.”

Não exatamente.

Os 16 GB provavelmente são RAM.

O 1 TB provavelmente corresponde ao armazenamento persistente.

RAM é memória de trabalho, normalmente volátil.

SSD, HDD ou armazenamento empresarial preservam dados de maneira persistente.

No mundo mainframe podemos pensar em:

DASD
  ↓
DATASET
  ↓
BUFFER
  ↓
MEMÓRIA
  ↓
CACHE
  ↓
CPU

Quando seu COBOL escreve:

READ ARQ-CLIENTES

parece que o programa simplesmente “leu o arquivo”.

Mas entre a instrução e o dado podem existir várias camadas de software, memória, buffers, cache, canais e armazenamento.

A simplicidade do COBOL é construída sobre uma enorme complexidade escondida.

---

🏰 CAPÍTULO 9 — SISTEMA OPERACIONAL: O SENKU DOS RECURSOS

Chegamos ao sistema operacional.

Ele administra recursos como:

CPU
memória
processos
arquivos
dispositivos
segurança
usuários
I/O

Mas sua função intelectualmente mais interessante talvez seja outra:

criar abstrações.

Você diz:

ARQUIVO

O sistema operacional esconde inúmeros detalhes físicos.

Você diz:

PROCESSO

Ele administra execução, memória e recursos.

Você pensa:

MEMÓRIA

Por baixo podem existir mecanismos sofisticados de memória virtual e tradução de endereços.

É como se o sistema operacional dissesse:

“Programador, cuide do seu problema. Eu cuido desta dungeon.”

No universo IBM Z encontramos um caso extraordinariamente rico:

IBM Z
 │
PR/SM
 │
LPAR
 │
z/OS

E podemos ter múltiplas partições executando diferentes workloads e sistemas.

A virtualização não nasceu com a cloud.

O universo mainframe possui uma história de virtualização que antecede em décadas boa parte da terminologia moderna de infraestrutura.

---

👻 CAPÍTULO 10 — SENKU ENCONTRA O FANTASMA DO EBCDIC

Agora precisamos representar letras.

Um computador não armazena conceitualmente a letra:

A

Ele armazena uma representação numérica interpretada segundo determinada codificação.

Em ASCII:

A = 0x41

Em páginas EBCDIC comuns:

A = 0xC1

E aqui encontramos uma criatura muito conhecida da dungeon mainframe:

EBCDIC

Extended Binary Coded Decimal Interchange Code.

Quem trabalha apenas com sistemas distribuídos modernos pode passar anos praticamente sem pensar nele.

Quem integra mainframe com outros ambientes eventualmente descobre sua existência.

Imagine:

COBOL / EBCDIC
       ↓
      MQ
       ↓
 integração
       ↓
 JSON / UTF-8
       ↓
 aplicação web

Se as conversões forem incorretas, aparecem caracteres aparentemente misteriosos.

Não foi um espírito.

Não foi RACF.

Não foi CICS possuído.

Pode simplesmente ser encoding.

Dica prática:

quando dados textuais atravessarem plataformas diferentes, pergunte sempre qual é a codificação na origem e qual é a codificação no destino.

---

🌐 CAPÍTULO 11 — SENKU INVENTA A REDE

Temos computadores.

Agora queremos conectá-los.

Podemos encontrar classificações tradicionais:

PAN
LAN
MAN
WAN

Mas compreender redes exige ir além da distância geográfica.

Imagine camadas:

APLICAÇÃO
HTTP / DNS
────────────
TRANSPORTE
TCP / UDP
────────────
REDE
IP
────────────
ENLACE
Ethernet
────────────
FÍSICA
sinais

Quando alguém escreve:

https://exemplo.com

pode ocorrer uma cadeia aproximadamente assim:

nome
 ↓
DNS
 ↓
endereço IP
 ↓
roteamento
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
aplicação

Agora imagine um programa COBOL CICS expondo funcionalidade por uma API.

De repente:

COBOL

está conversando conceitualmente com:

HTTP
JSON
TLS
TCP/IP

O programa de 30 anos não precisou necessariamente virar JavaScript para participar da Internet.

Essa é uma lição importantíssima sobre modernização:

integrar não significa obrigatoriamente reescrever.

---

🗄️ CAPÍTULO 12 — O REINO DOS BANCOS DE DADOS

Precisamos armazenar dados organizadamente.

Chegamos aos bancos de dados.

Primeira distinção:

DATABASE ≠ DBMS

O banco contém dados organizados.

O DBMS — Database Management System é o software responsável por gerenciá-los.

Em um banco relacional encontramos conceitos como:

TABLE
ROW
COLUMN
PRIMARY KEY
FOREIGN KEY

Mas um DBMS moderno faz muito mais:

transações
locking
logging
recovery
índices
buffers
segurança
concorrência
otimização
integridade

No mundo mainframe, Db2 é um personagem importantíssimo dessa história.

---

💰 CAPÍTULO 13 — SENKU TENTA FAZER UMA TRANSFERÊNCIA BANCÁRIA

Suponha:

CONTA A = 1000
CONTA B = 500

Queremos transferir 100.

Precisamos:

A = A - 100
B = B + 100

Mas imagine:

A = A - 100

*** SISTEMA CAI ***

E a segunda operação nunca acontece.

Parabéns.

Inventamos uma máquina de desaparecer dinheiro.

Por isso sistemas transacionais precisam de propriedades robustas.

Surge a famosa ideia de ACID:

Atomicity
Consistency
Isolation
Durability

Atomicidade significa, de forma simplificada:

a transação deve ser tratada como uma unidade — não queremos metade lógica da operação confirmada e metade perdida.

Isso é central para compreender sistemas empresariais.

CICS, Db2 e outros componentes do ecossistema transacional não existem apenas para tornar a arquitetura mais bonita em PowerPoint.

Eles existem porque dinheiro, estoque, reservas e pagamentos não toleram facilmente:

“quase funcionou”.

---

📜 CAPÍTULO 14 — SQL DESCOBRE UMA MAGIA DIFERENTE DO COBOL

COBOL é predominantemente procedural.

Você escreve uma sequência de ações.

SQL possui natureza declarativa.

Considere:

SELECT NOME, SALDO
FROM CLIENTES
WHERE CIDADE = 'ITATIBA';

Você informou o resultado desejado.

Não necessariamente determinou fisicamente:

abra o arquivo
leia registro
compare cidade
avance
leia novamente
...

O DBMS possui um otimizador.

Ele pode escolher diferentes estratégias.

Por exemplo:

table scan
index access
join
sort

Essa é uma mudança profunda de pensamento.

COBOL frequentemente pergunta:

COMO devo fazer?

SQL frequentemente permite dizer:

O QUE quero obter?

O DBMS procura uma estratégia.

Essa diferença entre programação procedural e declarativa reaparece em muitos outros lugares da computação moderna.

---

☁️ CAPÍTULO 15 — SENKU OLHA PARA O CÉU E NÃO ENCONTRA A CLOUD

Cloud computing é frequentemente explicada como:

recursos computacionais disponíveis pela Internet.

É um começo.

Mas se fosse somente isso, qualquer servidor remoto dos anos 1990 poderia receber retroativamente um adesivo escrito CLOUD.

O conceito moderno envolve características operacionais importantes:

provisionamento sob demanda
automação
elasticidade
resource pooling
medição de consumo
self-service

Portanto:

CLOUD ≠ COMPUTADOR DE OUTRA PESSOA

Essa piada possui alguma utilidade, mas é insuficiente tecnicamente.

Cloud é também um modelo operacional.

Isso nos leva a uma conexão interessante com mainframe.

Mainframes já praticavam há décadas ideias relacionadas a:

compartilhamento de recursos
virtualização
isolamento
gestão de workload
alta utilização
automação

Cloud não transformou o mainframe numa relíquia.

Na realidade, estudar mainframe ajuda a perceber que várias ideias consideradas modernas possuem ancestrais bastante antigos.

---

📦 CAPÍTULO 16 — CONTAINER NÃO É UMA VM EMAGRECIDA

Outra confusão clássica.

Máquinas virtuais e containers trabalham com isolamento, mas em níveis diferentes.

Simplificando uma VM:

APLICAÇÃO
   ↓
GUEST OS
   ↓
HYPERVISOR
   ↓
HARDWARE

Agora um container:

APLICAÇÃO
DEPENDÊNCIAS
   ↓
CONTAINER RUNTIME
   ↓
HOST OS
   ↓
HARDWARE

Containers normalmente compartilham recursos do kernel do host em vez de carregar necessariamente um sistema operacional convidado completo para cada instância.

Por isso podem ser leves e rápidos de iniciar.

Mas existe um detalhe importante:

containers e VMs podem coexistir.

Podemos ter:

HARDWARE
   ↓
VIRTUAL MACHINE
   ↓
LINUX
   ↓
CONTAINER RUNTIME
   ↓
CONTAINER

Tecnologia raramente é simplesmente:

VELHO ❌
NOVO ✅

Muito mais frequentemente encontramos:

camada
sobre
camada
sobre
camada.

---

🧠 CAPÍTULO 17 — SENKU DESCOBRE O VERDADEIRO SEGREDO: ABSTRAÇÃO

Finalmente chegamos ao conceito que une praticamente tudo.

Abstração.

Observe:

APLICAÇÃO
     ↓
COBOL
     ↓
COMPILADOR / RUNTIME
     ↓
MIDDLEWARE
     ↓
SISTEMA OPERACIONAL
     ↓
MEMÓRIA
     ↓
CPU
     ↓
MICROARQUITETURA
     ↓
CIRCUITOS
     ↓
TRANSISTORES
     ↓
FÍSICA

Cada camada permite esquecer temporariamente detalhes da camada inferior.

Sem isso seria praticamente impossível desenvolver sistemas modernos.

Imagine escrever:

DISPLAY 'BOM DIA'.

e precisar manualmente definir:

pixels
buffers
endereços físicos
sinais elétricos
registradores
temporização
I/O

Nunca terminaríamos o sistema.

Abstração é o mecanismo pelo qual transformamos complexidade inadministrável em conceitos utilizáveis.

Mas existe uma regra que todo profissional experiente aprende:

quando a abstração quebra, desça uma camada.

---

⚔️ CAPÍTULO 18 — O JOB LEVAVA 4 MINUTOS. AGORA LEVA 38.

Chegamos à War Room.

Produção informa:

ONTEM: 4 minutos
HOJE: 38 minutos

O programador iniciante abre imediatamente o COBOL.

Isso não é absurdo.

Pode realmente existir algum problema no programa.

Mas o profissional mais experiente constrói hipóteses.

O volume aumentou?

Mudou o access path do Db2?

Existe mais I/O?

Algum índice mudou?

Há contenção?

Existe locking?

O SORT cresceu?

Mudou o workload concorrente?

Há pressão de CPU?

A memória está pressionada?

Storage está respondendo diferente?

Alguma alteração foi implantada?

O programa está esperando alguma coisa?

Observe a mudança.

O iniciante pensa:

PROGRAMA → PROBLEMA

O engenheiro pensa:

SISTEMA
├── aplicação
├── dados
├── banco
├── middleware
├── sistema operacional
├── rede
├── CPU
├── memória
└── storage

Isso não significa investigar tudo indiscriminadamente.

Significa formular hipóteses e procurar evidências.

Senku aprovaria.

Ciência antes de superstição.

---

🏛️ CAPÍTULO 19 — O IBM Z COMO LABORATÓRIO DE FUNDAMENTOS

Agora podemos reunir nossa dungeon.

Imagine:

                    IBM Z
                      │
                    PR/SM
                      │
                    LPAR
                      │
                    z/OS
                      │
          ┌───────────┼───────────┐
          │           │           │
         JES         WLM         RACF
          │           │           │
          └───────────┼───────────┘
                      │
          ┌───────────┼───────────┐
          │           │           │
        CICS         Db2          MQ
          │           │           │
          └───────────┼───────────┘
                      │
                    COBOL

Essa representação é propositalmente simplificada, mas revela algo fundamental.

COBOL não é uma ilha.

Quando você aprende apenas sintaxe COBOL, aprende uma camada.

Quando entende:

JCL
datasets
VSAM
Db2
CICS
MQ
JES
RACF
WLM
TCP/IP
z/OS
storage
CPU

começa a enxergar o sistema.

E existe uma enorme diferença entre:

saber escrever um programa

e:

entender o sistema no qual o programa vive.

---

🧭 CAPÍTULO 20 — ROTEIRO DO PADAWAN: COMO ESTUDAR TUDO ISSO SEM ENLOUQUECER

Não tente aprender tudo simultaneamente.

Construa a civilização como Senku.

Etapa 1 — representação

Aprenda:

bit
byte
binário
hexadecimal
caracteres
ASCII
EBCDIC
Unicode
UTF-8

Faça conversões simples à mão.

Entenda por que:

41

pode significar coisas completamente diferentes dependendo de como interpretamos os bits.

Etapa 2 — hardware

Estude:

CPU
ALU
registradores
cache
RAM
storage
I/O

Não precisa projetar um processador.

Precisa entender onde os dados estão e por que movimentá-los custa tempo.

Etapa 3 — sistema operacional

Entenda:

processo
memória
arquivo
I/O
segurança
virtualização

Depois traduza isso para z/OS.

Etapa 4 — COBOL

Agora:

PIC
MOVE
COMPUTE
IF
EVALUATE
PERFORM
READ
WRITE
CALL

começam a ganhar contexto.

Etapa 5 — dados

Estude:

QSAM
VSAM
Db2
SQL
transações
índices
commit
rollback

Etapa 6 — processamento empresarial

Entre em:

batch
JCL
JES
CICS
Db2
MQ

Etapa 7 — integração

Finalmente:

TCP/IP
HTTP
REST
JSON
APIs
mensageria
cloud
containers

Agora o mainframe deixa de parecer uma máquina isolada e passa a aparecer como aquilo que realmente é:

uma plataforma participante de arquiteturas empresariais muito maiores.

---

🔬 CAPÍTULO 21 — TRÊS EXPERIMENTOS DE SENKU PARA O PROGRAMADOR COBOL

Faça estes pequenos laboratórios.

Experimento 1 — Hexadecimal. Pegue caracteres como A, 0, espaço e compare suas representações em ASCII e EBCDIC. Depois imagine o que aconteceria se um sistema interpretasse bytes EBCDIC como ASCII.

Você compreenderá encoding melhor do que decorando definições.

Experimento 2 — SQL. Compare mentalmente:

PERFORM UNTIL EOF
    READ CLIENTES
    IF CIDADE = 'ITATIBA'
       DISPLAY NOME
    END-IF
END-PERFORM

com:

SELECT NOME
FROM CLIENTES
WHERE CIDADE = 'ITATIBA';

Pergunte:

quem decidiu como encontrar os registros?

A resposta revela a diferença entre procedural e declarativo.

Experimento 3 — performance. Quando um programa estiver lento, não pergunte imediatamente:

“Qual linha está lenta?”

Pergunte primeiro:

“Onde o tempo está sendo gasto?”

Essas duas perguntas parecem semelhantes.

Não são.

---

🗿 CAPÍTULO 22 — A CURIOSIDADE ESCONDIDA NA PEDRA

Existe uma ironia histórica deliciosa.

Cada geração acredita ter inventado completamente o futuro.

Virtualização parece moderna.

Computação distribuída parece moderna.

Cloud parece moderna.

Containers parecem modernos.

Inteligência Artificial parece ter surgido ontem.

Mas a computação é uma enorme árvore genealógica.

Ideias reaparecem modificadas.

Problemas antigos recebem novas abstrações.

Tecnologias desaparecem e seus conceitos sobrevivem.

É exatamente por isso que estudar fundamentos continua valendo a pena.

Uma ferramenta pode desaparecer.

Um framework pode desaparecer.

Uma linguagem pode perder popularidade.

Mas conceitos como:

estado
memória
I/O
transação
concorrência
representação
abstração
algoritmo
protocolo
persistência

continuam retornando com roupas diferentes.

---

☕ EPÍLOGO — O IF DE DUAS LINHAS QUE CARREGA UM SÉCULO DE CIÊNCIA

Voltamos finalmente ao nosso pequeno programa:

IF WS-SALDO >= WS-COMPRA
    DISPLAY 'COMPRA AUTORIZADA'
END-IF.

Agora você sabe que essas duas linhas escondem uma cadeia extraordinária.

O fonte COBOL precisa ser representado por caracteres.

Os caracteres precisam possuir encoding.

O compilador precisa compreender a linguagem.

O programa precisa transformar-se em algo executável pela arquitetura.

O sistema operacional precisa fornecer recursos.

Dados precisam ocupar memória.

A CPU precisa executar instruções.

Registradores e caches participam do processamento.

Talvez o saldo venha do Db2.

Talvez a transação esteja sob CICS.

Talvez uma mensagem atravesse MQ.

Talvez outra plataforma participe pela rede.

Talvez o resultado seja entregue por uma API para um smartphone a milhares de quilômetros do datacenter.

O usuário toca:

COMPRAR

e espera talvez dois segundos.

Ele não quer saber de:

CPU
cache
RAM
EBCDIC
SQL
Db2
CICS
TCP/IP
TLS
MQ
storage

E está certo.

Essa complexidade é problema nosso.

Essa é a beleza da engenharia.

Construímos uma camada para que a próxima possa esquecer a anterior.

Até que um dia algo quebra.

Às 03:17.

O telefone toca.

A aplicação não responde.

O programador olha para o COBOL e diz:

“Mas meu IF está correto!”

Então Senku aparece imaginariamente na War Room, pega o café abandonado ao lado do terminal 3270 e responde:

Então formule outra hipótese.

Esse talvez seja o ensinamento mais importante de todos os fundamentos de computação.

Não decore simplesmente que CPU significa Central Processing Unit.

Não decore que RAM é volátil.

Não decore que DNS converte nomes em endereços.

Não decore que SQL consulta bancos.

Não decore que cloud fornece recursos.

Pergunte por quê.

Pergunte o que existe abaixo.

Pergunte qual abstração está escondendo qual complexidade.

Pergunte onde o dado nasceu, como foi representado, onde foi armazenado, como chegou até a CPU, quem o modificou, como foi persistido e como atravessou a rede.

Porque o dia em que um programador COBOL começa a enxergar:

COBOL
   ↓
CICS / Db2 / MQ
   ↓
z/OS
   ↓
virtualização
   ↓
CPU / memória / I/O
   ↓
hardware

é o dia em que deixa de enxergar somente programas.

Começa a enxergar sistemas.

E esse é um upgrade que nenhum MOVE, PERFORM ou certificado consegue fornecer sozinho.

Senku começou sua reconstrução com pedras, ciência e perguntas.

Nosso Padawan começa com:

IDENTIFICATION DIVISION.

O destino, porém, é muito parecido:

entender como as coisas realmente funcionam.

E quando alguém perguntar se precisamos mesmo conhecer binário, hexadecimal, CPU, memória, sistema operacional, banco de dados, redes, virtualização e cloud para programar COBOL, já temos a resposta.

Para escrever:

DISPLAY 'HELLO'.

provavelmente não.

Para descobrir por que o HELLO não apareceu às 03:17 da madrugada?

Aí começa a verdadeira Ciência da Computação.

Dez bilhões por cento.