 |
| Bellacosa Mainframe e a pequena historia do profissional de informatica no Brasil |
☕ Um Café no Bellacosa Mainframe
Os Irmãos do Blues do Processamento de Dados
Quando os primeiros profissionais da informática brasileira receberam uma missão: atravessar calculadoras, telégrafos, cartões perfurados, mainframes e cinquenta anos de evolução sem deixar o processamento parar
Era noite.
Em algum lugar do Brasil industrial dos anos 1970, uma impressora de linha martelava milhares de caracteres por minuto. As unidades de fita giravam para frente e para trás como músicos esperando o momento exato de entrar na canção. Luzes piscavam no painel do computador. Um operador carregava um enorme disk pack com as duas mãos, quase como quem transportava um instrumento sagrado.
Do outro lado da parede de vidro, um programador examinava uma listagem contínua coberta de códigos, números de linha e mensagens do compilador.
O programa havia falhado.
Não existia Google.
Não existia Stack Overflow.
Não existia vídeo explicativo.
Não existia inteligência artificial para sugerir a correção.
Existiam apenas o manual, a experiência, o café, a lógica e uma equipe que sabia que precisava colocar aquele sistema novamente em funcionamento antes do amanhecer.
A missão era simples:
fazer o processamento rodar.
O prazo?
Antes que a empresa abrisse as portas.
Os recursos?
Poucos kilobytes de memória, cartões perfurados, fitas magnéticas e uma quantidade quase ilimitada de coragem.
Esta é a história da profissão de informático no Brasil. Uma história que começou muito antes do notebook, do computador pessoal e até mesmo do computador eletrônico. Ela nasceu entre calculadoras mecânicas, máquinas contábeis, telégrafos, ferrovias, fichários e departamentos Hollerith.
É também a história dos perfuradores, conferentes, operadores, programadores, analistas, técnicos de manutenção, administradores de dados e chefes de CPD que transformaram máquinas gigantescas em ferramentas essenciais para o funcionamento do país.
Eles usavam nomes diferentes.
Mas todos faziam parte da mesma banda.
1. Antes do computador, o Brasil já processava dados
Um programador COBOL iniciante pode imaginar que a história da informática começou quando alguém escreveu o primeiro IDENTIFICATION DIVISION.
Não começou.
Muito antes de existirem linguagens de programação, as empresas brasileiras já enfrentavam aquilo que hoje chamaríamos de um problema de escalabilidade.
Imagine uma grande ferrovia.
Ela precisava controlar:
milhares de empregados;
salários e benefícios;
locomotivas;
vagões;
horários;
cargas;
passagens;
oficinas;
ferramentas;
peças de reposição;
consumo de combustível;
manutenção;
acidentes;
receitas e despesas.
Enquanto uma empresa era pequena, livros contábeis e fichas manuais podiam resolver o problema. Entretanto, quando a organização crescia, o volume de informação tornava o processamento humano lento, caro e sujeito a erros.
O verdadeiro antepassado do profissional de informática não foi apenas o matemático.
Foi também o escriturário.
Era ele quem registrava, classificava, somava, conferia e arquivava informações. Em enormes salas administrativas, dezenas ou centenas de pessoas processavam dados manualmente.
O computador não surgiu primeiro para criar imagens, músicas ou mundos virtuais.
Ele surgiu para vencer filas de documentos.
2. Calculadoras mecânicas: a pré-história do processamento
Antes do computador eletrônico, existiram calculadoras mecânicas e eletromecânicas.
Elas realizavam somas, subtrações e, dependendo do modelo, multiplicações e divisões. Algumas funcionavam por manivelas. Outras utilizavam motores elétricos para movimentar engrenagens, rodas e registradores.
Não eram computadores de propósito geral, mas já introduziam uma ideia revolucionária:
Uma parte do trabalho intelectual poderia ser automatizada por uma máquina.
Para um jovem acostumado com processadores executando bilhões de operações por segundo, pode parecer pouco.
Mas considere o contexto.
Uma folha de pagamento com milhares de funcionários exigia inúmeros cálculos. Um erro poderia significar salário incorreto, imposto indevido ou total contábil incompatível.
A calculadora mecânica diminuía o esforço, mas ainda dependia intensamente do operador.
A pessoa digitava os valores.
A máquina calculava.
A pessoa anotava o resultado.
A informação precisava ser transportada manualmente de um documento para outro.
Era uma arquitetura com alto acoplamento humano.
O usuário funcionava como CPU, memória, barramento e interface.
3. O telégrafo e a primeira rede brasileira
Enquanto máquinas contábeis processavam números, o telégrafo conectava cidades, estações ferroviárias, portos e centros administrativos.
Ele foi uma das primeiras grandes infraestruturas de comunicação de dados.
Sim, caro padawan do COBOL: o telégrafo pode ser entendido como um ancestral distante das redes de computadores.
Uma mensagem era codificada.
Transmitida por um meio físico.
Recebida em outro ponto.
Decodificada.
Confirmada ou retransmitida.
Temos aí vários elementos conhecidos:
origem;
destino;
protocolo;
codificação;
transmissão;
recepção;
tratamento de erro;
operador.
Quando um telegrafista enviava uma mensagem para organizar a circulação de trens, ele participava de um sistema distribuído.
A diferença é que o middleware usava Código Morse e o operador humano fazia aquilo que hoje seria responsabilidade de um software de comunicação.
A ferrovia, portanto, não transportava apenas pessoas e mercadorias.
Transportava informações.
4. O Departamento Hollerith da Companhia Paulista
É nesse mundo de ferrovias, telégrafos, escrituração e mecanização administrativa que encontramos os departamentos Hollerith.
O nome vinha de Herman Hollerith, criador de sistemas de processamento baseados em cartões perfurados. Sua tecnologia ficou famosa pela utilização no censo norte-americano de 1890 e tornou-se a base de uma indústria de máquinas de tabulação.
No Brasil, grandes organizações passaram a empregar máquinas Hollerith para atividades administrativas. A Companhia Paulista de Estradas de Ferro está ligada a essa história de mecanização do processamento de informações ferroviárias.
O Departamento Hollerith era uma espécie de antepassado do CPD.
Não havia processador eletrônico central.
Havia um conjunto de máquinas especializadas.
Uma perfurava.
Outra conferia.
Outra classificava.
Outra intercalava.
Outra tabulava.
Outra imprimia.
O processamento era realizado como uma linha de montagem.
Observe como isso se aproxima de um pipeline:
Documento de origem
↓
Codificação dos dados
↓
Perfuração
↓
Conferência
↓
Classificação
↓
Tabulação
↓
Relatório
Hoje podemos substituir essas etapas por:
Formulário digital
↓
Validação
↓
API
↓
Fila
↓
Processamento
↓
Banco de dados
↓
Dashboard
A aparência mudou.
A lógica permaneceu.
5. O cartão perfurado: o banco de dados que cabia na mão
O cartão perfurado de 80 colunas tornou-se um dos maiores símbolos da informática corporativa.
Cada posição podia ser perfurada de acordo com um código. Letras, números e símbolos eram representados por combinações de furos.
Para um programador moderno, podemos imaginar um cartão como um registro físico.
Se o cartão representasse um funcionário, suas colunas poderiam ser organizadas assim:
01-06 Matrícula
07-36 Nome
37-44 Data de admissão
45-54 Salário
55-56 Código do departamento
57-80 Informações complementares
Isso é um arquivo de largura fixa.
Quem trabalha com COBOL reconhecerá imediatamente a filosofia.
01 REGISTRO-FUNCIONARIO.
05 MATRICULA PIC 9(06).
05 NOME PIC X(30).
05 DATA-ADMISSAO PIC 9(08).
05 SALARIO PIC 9(08)V99.
05 COD-DEPARTAMENTO PIC 9(02).
05 COMPLEMENTO PIC X(24).
O cartão perfurado não era apenas mídia.
Ele também influenciou a própria estrutura das linguagens e dos programas.
O formato tradicional do COBOL foi organizado considerando cartões de 80 colunas:
colunas 1 a 6: sequência;
coluna 7: indicador;
colunas 8 a 11: Área A;
colunas 12 a 72: Área B;
colunas 73 a 80: identificação.
Nada disso nasceu por acaso.
O formato fixo do COBOL é uma lembrança fossilizada do cartão perfurado.
Easter egg desbloqueado: sempre que você encontra um programa COBOL antigo usando colunas rígidas, está olhando para a sombra digital de uma máquina de perfuração.
6. A perfuradora não era uma simples digitadora
Uma das profissões fundamentais daquela época era a de perfurador ou perfuradora.
O programador escrevia o código em folhas de codificação.
Essas folhas eram encaminhadas ao setor de perfuração.
O profissional lia cada linha e a transferia para cartões.
A operação exigia velocidade, atenção e precisão.
Um furo errado poderia transformar:
ADD VALOR-VENDA TO TOTAL-VENDAS
em uma instrução inválida.
Pior: dependendo do erro, o programa poderia ser compilado e produzir um resultado incorreto.
Depois da perfuração vinha a conferência.
Em muitas instalações, outro profissional digitava novamente o conteúdo em uma máquina verificadora. Se a sequência digitada não correspondesse aos furos existentes, a máquina indicava divergência.
Era uma forma humana e mecânica de dupla validação.
Hoje chamamos isso de controle de qualidade.
Naquela época, chamava-se sobrevivência operacional.
7. Quando deixar cair um programa era literalmente possível
Um programa podia ser formado por centenas ou milhares de cartões.
Cada cartão representava uma linha.
Os cartões precisavam permanecer em ordem.
Se a pilha caísse no chão, o programa também caía.
Literalmente.
Por isso as colunas iniciais frequentemente continham números de sequência.
Caso o desastre acontecesse, os cartões poderiam ser classificados novamente por uma máquina sorter.
Essa é uma bela lição para o programador iniciante:
Numeração de sequência não era decoração. Era recuperação de desastre.
Hoje você usa Git.
Naquela época, usava-se disciplina, numeração e caixas de cartão.
A frase “meu código quebrou” tinha outra dimensão.
8. Os primeiros computadores desembarcam no Brasil
A chegada dos computadores eletrônicos ao Brasil ocorreu durante a década de 1950.
Um marco frequentemente citado é a instalação, em 1957, de um computador Univac para o governo do Estado de São Paulo. Pouco depois, em 1959, a Anderson Clayton adquiriu um IBM 305 RAMAC, apontado como o primeiro computador eletrônico instalado no setor privado brasileiro. (Din UEM)
O RAMAC era impressionante porque utilizava armazenamento em disco de acesso aleatório. Sua unidade IBM 350 empregava cinquenta discos magnéticos de grandes dimensões e armazenava poucos megabytes — capacidade minúscula hoje, mas revolucionária naquele contexto. (Wikipédia)
Não pense nesses computadores como PCs enormes.
Eles pertenciam a outro universo operacional.
A empresa não “comprava um computador” como quem compra uma estação de trabalho.
Ela implantava uma infraestrutura.
Era necessário preparar:
sala especial;
alimentação elétrica;
climatização;
piso;
cabeamento;
procedimentos;
operadores;
técnicos;
programadores;
métodos de segurança;
rotinas de backup.
A chegada do computador criava um novo departamento e uma nova cultura.
9. O CPD entra no palco
O Centro de Processamento de Dados, o famoso CPD, tornou-se o coração informacional das organizações.
Ali ficavam:
a unidade central;
leitoras de cartões;
perfuradoras;
impressoras de linha;
unidades de fita;
discos removíveis;
consoles;
painéis;
formulários contínuos;
armários de documentação.
O CPD era cercado por respeito e mistério.
Possuía acesso controlado.
Em muitos ambientes havia paredes de vidro separando os visitantes das máquinas.
O ar-condicionado era intenso.
Os operadores usavam roupas adequadas ao ambiente e, em algumas empresas, jalecos.
As máquinas produziam uma trilha sonora própria:
clac-clac-clac dos cartões,
vrummm das fitas,
trrrrrrrrr das impressoras,
bip do console.
Era rhythm and blues em código binário.
Uma banda inteira tocando para fechar a folha de pagamento.
10. IBM System/360: a grande banda entra em cena
Em 1964, a IBM anunciou a família System/360.
O nome representava a ambição de cobrir uma ampla variedade de aplicações: negócios, ciência, indústria e governo.
O conceito de família compatível foi revolucionário.
Antes disso, migrar para uma máquina maior frequentemente exigia reescrever programas. Com o System/360, a IBM buscava permitir que clientes evoluíssem dentro de uma arquitetura comum.
No Brasil, sistemas dessa família chegaram a bancos, indústrias, siderúrgicas, universidades e órgãos públicos.
Para empresas como a Mannesmann, o mainframe tornou-se parte da infraestrutura industrial.
Ele processava:
produção;
estoques;
custos;
materiais;
compras;
folha de pagamento;
contabilidade;
faturamento;
manutenção.
O computador deixava de ser uma curiosidade tecnológica.
Tornava-se sistema nervoso corporativo.
11. Uma carteira de trabalho assinada em 1975
Quando alguém olha para uma carteira de trabalho assinada em 1975 com uma função relacionada a processamento de dados, não está vendo apenas um registro profissional.
Está vendo um documento arqueológico da informática brasileira.
A pessoa que ingressava em um CPD naquela época encontrava um mundo sem interfaces amigáveis.
Aprender significava:
observar profissionais experientes;
estudar manuais;
decorar códigos;
entender formulários;
acompanhar operações;
interpretar mensagens;
registrar procedimentos;
errar com cuidado;
nunca repetir o mesmo erro;
respeitar a produção.
No CPD da Mannesmann, diante de um IBM System/360, as limitações de memória não eram uma abstração acadêmica.
Eram parte de cada decisão.
Uma tabela muito grande podia não caber.
Um programa mal estruturado podia consumir recursos preciosos.
Um excesso de operações de entrada e saída podia aumentar o tempo de execução.
Um erro na definição de arquivo podia interromper toda uma cadeia de processamento.
Essa escola criava um tipo específico de profissional:
alguém que pensava antes de executar.
12. O programador não começava programando
O caminho profissional podia começar em várias funções:
Auxiliar administrativo
↓
Perfurador
↓
Conferente
↓
Operador
↓
Programador trainee
↓
Programador júnior
↓
Programador pleno
↓
Programador sênior
↓
Analista de sistemas
Nem todas as carreiras seguiam exatamente essa ordem, mas era comum o conhecimento ser adquirido dentro da empresa.
O profissional conhecia primeiro a operação.
Depois aprendia a lógica.
Depois recebia pequenas alterações.
Mais tarde criava programas completos.
Isso tinha uma vantagem enorme: muitos programadores entendiam profundamente como o sistema era executado.
Eles sabiam o que acontecia antes e depois de seu código.
Sabiam quem montava a fita.
Sabiam onde o relatório era entregue.
Sabiam qual departamento dependia do processamento.
Hoje um desenvolvedor pode executar uma aplicação sem conhecer a infraestrutura.
Naquela época, software e operação viviam quase grudados.
Era DevOps antes do nome DevOps.
13. A folha de codificação: programar antes de digitar
O programa começava no papel.
O analista descrevia o problema.
Criava fluxogramas.
Definia arquivos.
Desenhava relatórios.
Especificava validações.
O programador recebia essas informações e escrevia o código em folhas de codificação.
Cada linha era planejada.
Depois a folha seguia para perfuração.
Esse processo podia levar horas ou dias até a primeira compilação.
Portanto, escrever código sem pensar era muito caro.
Considere um ciclo típico:
Especificação
↓
Fluxograma
↓
Teste de mesa
↓
Folha de codificação
↓
Perfuração
↓
Conferência
↓
Montagem do deck
↓
Submissão
↓
Compilação
↓
Listagem
↓
Correção
Hoje o compilador responde em segundos.
Naquela época, o programador podia entregar o job e aguardar uma janela de processamento.
O erro voltava impresso.
A depuração era feita examinando papel.
14. O teste de mesa: o debugger dentro da cabeça
Antes de submeter o programa, o profissional realizava o teste de mesa.
Ele simulava manualmente a execução.
Suponha o seguinte trecho:
MOVE 0 TO TOTAL-GERAL
PERFORM UNTIL FIM-ARQUIVO = 'S'
READ ARQUIVO-VENDAS
AT END
MOVE 'S' TO FIM-ARQUIVO
NOT AT END
ADD VALOR-VENDA TO TOTAL-GERAL
END-READ
END-PERFORM
No teste de mesa, o programador criava uma pequena tabela:
Registro Valor Fim? Total
1 100 N 100
2 250 N 350
3 50 N 400
EOF --- S 400
Ele verificava cada mudança de variável.
Isso revelava loops infinitos, totais incorretos, condições erradas e registros processados duas vezes.
Dica Bellacosa para o iniciante:
Quando um programa COBOL parecer misterioso, execute cinco registros no papel. O papel não mente e não esconde estado.
15. O operador: maestro da sala de máquinas
O operador não era alguém que apenas apertava ENTER.
Ele controlava a execução física e lógica do ambiente.
Suas tarefas podiam incluir:
iniciar equipamentos;
carregar o sistema;
montar fitas;
instalar disk packs;
alimentar leitoras;
retirar listagens;
controlar filas;
responder a mensagens;
registrar falhas;
reiniciar jobs;
comunicar incidentes;
executar rotinas de backup.
Imagine um job solicitando:
MOUNT TAPE PAYR01 ON UNIT 480
Alguém precisava localizar a fita correta, conferir sua etiqueta, montá-la na unidade e responder ao sistema.
A automação dependia de mãos humanas.
O operador era parte do fluxo de execução.
Se ele montasse a fita errada, o sistema poderia ler informações incorretas.
Por isso existiam procedimentos rigorosos.
O CPD ensinou cedo uma lição que a nuvem às vezes faz esquecer:
Infraestrutura abstrata continua sendo infraestrutura real em algum lugar.
16. Disk packs: o disco removível com peso de responsabilidade
Antes dos pequenos discos rígidos modernos, eram comuns conjuntos removíveis de discos magnéticos.
Os disk packs possuíam múltiplos pratos.
O operador os transportava em recipientes protetores e os instalava em unidades específicas.
Cada superfície podia armazenar dados.
Uma poeira, um impacto ou uma instalação inadequada podia causar danos.
A troca de um volume não era um clique.
Era uma operação física.
Hoje montamos um volume em cloud computing usando uma instrução ou console.
Naquela época, “montar o volume” significava literalmente pegar o volume com as mãos.
Outro easter egg tecnológico:
O verbo mount, usado até hoje em sistemas operacionais, preserva a memória de uma época em que mídias precisavam ser fisicamente montadas.
17. Fitas magnéticas e o pensamento sequencial
As fitas magnéticas foram fundamentais.
Elas ofereciam boa capacidade para a época e eram úteis para:
arquivos históricos;
backups;
processamento em lote;
transferência;
entrada e saída de grandes volumes.
Mas a fita era sequencial.
Para chegar ao registro desejado, era necessário percorrer os anteriores.
Esse comportamento influenciou profundamente os programas COBOL.
Muitos sistemas eram desenhados para ler dois arquivos ordenados e realizar casamento de registros.
Exemplo:
Arquivo de clientes
+
Arquivo de pagamentos
=
Relatório de clientes pagos e inadimplentes
O algoritmo caminhava pelos dois arquivos em ordem de chave.
Essa técnica continua valiosa.
Ela ensina que a melhor solução depende das características do armazenamento.
Não existe algoritmo isolado da infraestrutura.
18. O analista de sistemas: tradutor entre dois mundos
Com o crescimento dos sistemas, tornou-se necessário separar responsabilidades.
O analista conversava com as áreas de negócio.
Ele precisava compreender:
como a empresa funcionava;
quais documentos existiam;
quais regras eram aplicadas;
onde ocorriam erros;
quais relatórios eram necessários;
quais arquivos deveriam ser criados;
quais controles seriam obrigatórios.
Depois transformava isso em especificação técnica.
O analista era um tradutor.
De um lado, o usuário dizia:
“Preciso impedir o faturamento de clientes bloqueados.”
Do outro, o programador precisava receber algo como:
Se o código de situação do cliente for diferente de 01,
rejeitar a transação, registrar ocorrência e emitir mensagem 145.
Boa análise elimina ambiguidade.
Esse princípio continua absolutamente atual.
Um requisito ruim em 1975 gerava um programa errado.
Um requisito ruim em 2026 gera um microsserviço errado muito mais rapidamente.
19. Os primeiros cursos e a formação prática
Durante os primeiros anos, a indústria formava grande parte de seus profissionais.
Fabricantes ofereciam treinamento.
Empresas criavam programas internos.
Manuais técnicos circulavam entre equipes.
Os primeiros cursos superiores brasileiros voltados especificamente à computação surgiram no final da década de 1960. Estudos históricos apontam a criação, em 1969, de cursos de graduação plena na Unicamp e na Universidade Federal da Bahia. (HCTE UFRJ)
Até que essa formação se difundisse, os profissionais pioneiros precisavam vir de outras áreas:
engenharia;
matemática;
administração;
contabilidade;
estatística;
operação de máquinas;
funções administrativas.
A informática brasileira foi construída por uma tripulação heterogênea.
Não havia uma estrada pronta.
Eles desenharam a estrada enquanto dirigiam.
20. Uma correção histórica importante sobre 1985
Aqui precisamos ajustar uma informação frequentemente repetida.
O Decreto nº 91.250, de 17 de maio de 1985, não regulamentou de forma ampla e definitiva o exercício das profissões de informática no setor privado brasileiro.
Ele alterou dispositivos do Decreto nº 83.989, de 1979, relacionados a categorias funcionais e requisitos de ingresso no serviço público federal. Entre as alterações, incluiu o curso de Tecnólogo em Processamento de Dados entre as formações aceitas para a categoria funcional de Analista de Sistemas. (Presidência da República)
Portanto, a interpretação mais precisa é:
O decreto contribuiu para organizar e reconhecer cargos de informática dentro da estrutura funcional federal, mas não criou uma regulamentação geral da profissão de programador ou analista para todo o mercado brasileiro.
A regulamentação ampla das profissões de informática continuou sendo objeto de debates e projetos legislativos posteriores. (Legis Senador)
Isso não diminui a importância histórica de 1985.
Pelo contrário.
Mostra como o Estado precisou adaptar suas estruturas administrativas ao crescimento de uma atividade que já existia havia décadas.
A profissão surgiu primeiro.
A legislação tentou alcançá-la depois.
21. O veterano sem diploma específico não era improvisado
Quando se fala em reconhecer experiência profissional, é preciso evitar um erro comum.
O pioneiro que não possuía diploma de Ciência da Computação não era necessariamente alguém sem formação.
Muitos eram engenheiros, matemáticos, administradores, contadores ou técnicos altamente especializados.
Outros haviam aprendido integralmente dentro das empresas.
Eles acumulavam milhares de horas de prática.
Conheciam máquinas que exigiam domínio simultâneo de:
lógica;
hardware;
armazenamento;
operação;
linguagem;
negócio;
contingência;
documentação.
O mercado não podia simplesmente declarar:
“Agora existe um curso; tudo o que veio antes deixou de valer.”
Seria como construir uma ponte e depois informar aos engenheiros que fizeram a obra que sua experiência não conta.
O reconhecimento da experiência preservava a memória técnica das organizações.
22. A reserva de mercado e a informática nacional
Durante parte das décadas de 1970 e 1980, o Brasil adotou políticas de proteção à indústria nacional de informática.
A intenção era reduzir dependência externa e desenvolver capacidade tecnológica local.
Esse movimento ajudou a estimular empresas, pesquisas e projetos nacionais, mas também limitou o acesso a certos equipamentos estrangeiros, aumentou custos e criou diferenças tecnológicas em relação aos principais mercados mundiais.
Foi uma história cheia de contradições.
De um lado:
formação de engenheiros;
criação de empresas nacionais;
desenvolvimento de hardware;
pesquisa universitária;
domínio local de tecnologias.
Do outro:
equipamentos caros;
atraso em determinados segmentos;
restrições de importação;
compatibilidades problemáticas;
mercado paralelo.
Em 1972, o Patinho Feio, desenvolvido na Universidade de São Paulo, tornou-se um símbolo do esforço brasileiro de projetar computadores. O projeto nasceu no ambiente acadêmico da Escola Politécnica da USP e deixou um legado importante para ensino e indústria. (Revista Pesquisa Fapesp)
A informática nacional não foi apenas uma tentativa de copiar máquinas.
Foi também um laboratório de formação humana.
23. A grande migração: do cartão para o terminal
Com a popularização dos terminais, especialmente famílias como o IBM 3270, a relação entre o programador e o computador mudou.
Antes:
Papel → perfuração → cartão → leitora → compilação → listagem
Depois:
Terminal → editor → submissão → spool → correção
O ciclo encurtou.
Ferramentas como TSO e ISPF transformaram o desenvolvimento em mainframe.
O código passou a ser editado diretamente em datasets.
O programador podia consultar a saída no spool.
Alterar uma linha tornou-se muito mais rápido.
Mas os hábitos do cartão continuaram presentes:
colunas;
largura fixa;
sequência;
datasets;
jobs;
relatórios;
processamento batch.
A nova tecnologia não apagou a anterior.
Construiu sobre ela.
24. Cinquenta anos de armazenamento
Uma pessoa que iniciou a carreira em 1975 pôde testemunhar uma das maiores transformações materiais da história.
Ela atravessou:
Cartão perfurado
↓
Fita magnética
↓
Disk pack
↓
Disquete
↓
Disco rígido
↓
RAID
↓
Storage corporativo
↓
SAN
↓
SSD
↓
NVMe
↓
Object storage
↓
Cloud computing
No cartão, o dado era visível como um furo.
Na fita, era uma sequência magnética.
No disco, ocupava trilhas e setores.
Na nuvem, parece não possuir localização física.
Mas ainda está armazenado em algum dispositivo.
A nuvem não eliminou o hardware.
Apenas colocou o hardware atrás de uma API.
25. O que o programador COBOL iniciante deve aprender com os pioneiros
Passo 1 — Entenda o negócio
Não comece apenas pela sintaxe.
Descubra:
quem usa o programa;
qual processo ele atende;
quais dados recebe;
qual resultado produz;
o que acontece quando falha.
Passo 2 — Leia o layout do arquivo
Em COBOL, dados são arquitetura.
Analise:
PIC;tamanho;
sinal;
casas decimais;
campos redefinidos;
níveis;
campos de controle.
Passo 3 — Faça um teste de mesa
Pegue poucos registros.
Simule:
entrada;
condições;
cálculos;
saída;
fim de arquivo.
Passo 4 — Conheça o JCL
O programa não vive sozinho.
O JCL informa:
qual programa executar;
quais arquivos utilizar;
onde estão os dados;
o que fazer com a saída;
quais recursos serão necessários.
Passo 5 — Leia o spool
Não procure apenas a última mensagem.
Examine:
etapas executadas;
códigos de retorno;
mensagens;
alocações;
estatísticas;
dumps.
Passo 6 — Respeite a produção
Nunca trate uma alteração como “apenas uma linha”.
Uma linha pode afetar:
milhões de registros;
milhares de clientes;
fechamento contábil;
pagamento;
faturamento;
obrigação legal.
Passo 7 — Documente
O profissional seguinte talvez seja você mesmo seis meses depois.
Escreva para que ele entenda.
26. Curiosidades da estrada mainframe
O formulário contínuo tinha personalidade
Impressoras de linha utilizavam papel contínuo com furos laterais. Relatórios gigantes podiam ocupar caixas inteiras.
O erro podia chegar de carrinho
Listagens volumosas eram transportadas em carrinhos dentro de grandes CPDs.
O som ajudava no diagnóstico
Operadores experientes reconheciam anormalidades pelo ruído das unidades e impressoras.
A mídia tinha biblioteca
Fitas e discos eram armazenados, catalogados, emprestados e devolvidos como livros.
Backup era uma operação física
Copiar dados significava usar dispositivos, mídias, tempo de máquina e procedimentos formais.
O café era um componente crítico
Não aparece no diagrama da arquitetura, mas sustentou muitas janelas batch.
27. Easter egg: estamos em uma missão de Deus?
Os protagonistas de uma famosa comédia musical de 1980 cruzam estradas, reúnem antigos companheiros e enfrentam obstáculos absurdos para salvar aquilo em que acreditam.
A geração pioneira da informática brasileira também recebeu uma missão.
Não usava um automóvel preto atravessando Chicago.
Usava ônibus, trem, fusca, crachá e relógio de ponto.
Não precisava reunir uma banda.
Precisava reunir:
o analista;
o programador;
o perfurador;
o conferente;
o operador;
o técnico;
o usuário;
o chefe do CPD.
Quando todos trabalhavam em harmonia, o processamento entrava no ritmo.
Quando um deles saía do compasso, aparecia o ABEND.
A diferença entre uma banda e um CPD talvez seja menor do que parece.
Ambos exigem sincronização.
Ambos dependem de disciplina.
Ambos possuem bastidores invisíveis.
E ambos podem ser destruídos por alguém que entra no momento errado.
28. O verdadeiro mainframe sempre foi humano
É tentador contar a história da informática como uma sequência de máquinas.
Hollerith.
UNIVAC.
RAMAC.
System/360.
System/370.
308X.
ES/9000.
S/390.
IBM Z.
Mas máquinas não escrevem sua própria história.
Foram pessoas que decidiram como utilizá-las.
Pessoas perfuraram cartões.
Pessoas carregaram discos.
Pessoas interpretaram dumps.
Pessoas enfrentaram madrugadas.
Pessoas explicaram sistemas.
Pessoas ensinaram colegas.
Pessoas preservaram programas.
Pessoas migraram dados.
Pessoas impediram que décadas de conhecimento fossem perdidas.
O profissional que começou em 1975 e chegou à computação em nuvem não atravessou apenas mudanças de equipamento.
Atravessou diferentes maneiras de imaginar o que é informação.
Primeiro, a informação era um documento.
Depois, um furo.
Depois, um campo magnético.
Depois, um registro.
Depois, uma tabela.
Depois, um objeto.
Depois, um evento distribuído.
Mas, em todas as épocas, alguém precisou responder às mesmas perguntas:
O dado está correto?
O processamento terminou?
O resultado pode ser confiado?
Existe recuperação?
Quem será afetado?
O que faremos se falhar?
Conclusão: todos fazem parte da mesma banda
A história da profissão de informático no Brasil não começa no Vale do Silício.
Começa também nas ferrovias, nos escritórios, nos bancos, nas siderúrgicas, nas repartições públicas, nas universidades e nos departamentos Hollerith.
Começa com pessoas que mecanizaram cálculos.
Continua com perfuradores que transformaram papel em dados.
Avança com operadores que comandaram salas cheias de máquinas.
Ganha lógica com programadores que escreveram sistemas em Assembler, COBOL, FORTRAN e RPG.
Ganha visão com analistas que converteram processos empresariais em especificações.
Ganha escala com os grandes mainframes.
Ganha alcance com redes e terminais.
Ganha velocidade com discos e servidores.
Ganha abstração com virtualização e nuvem.
E chega ao presente com ambientes distribuídos, inteligência artificial e armazenamento aparentemente infinito.
Entretanto, a essência permanece.
Informática continua sendo a arte de transformar uma necessidade humana em uma sequência confiável de operações.
Por isso, olhar para uma carteira de trabalho assinada em 1975 não é praticar nostalgia vazia.
É reconhecer um documento de fundação.
Aquela assinatura pertence a uma geração que entrou em CPDs quando o conhecimento ainda precisava ser descoberto, traduzido e transmitido de pessoa para pessoa.
Uma geração que programava na raça.
Que respeitava cada byte.
Que sabia o peso de um disco.
Que conhecia o valor de uma fita.
Que entendia o silêncio de uma máquina parada.
Que não precisava chamar tudo de “missão crítica”, porque sabia que, se o processamento não terminasse, alguém não receberia, uma fábrica não faturaria ou um banco não fecharia.
A nova geração precisa conhecer essa história não para repetir suas limitações, mas para herdar suas virtudes:
disciplina,
curiosidade,
responsabilidade,
capacidade de análise,
respeito aos dados,
e coragem para enfrentar sistemas que parecem impossíveis.
Portanto, coloque os óculos escuros.
Ajuste o chapéu.
Confira o JCL.
Monte a fita.
Não derrube os cartões.
Temos memória limitada, uma janela batch fechando, centenas de quilômetros de história pela frente e um sistema inteiro esperando para ser processado.
Estamos em uma missão.
Fazer o conhecimento dos pioneiros continuar rodando.
Conheça um pouco sobre o Cobol
https://eljefemidnightlunch.blogspot.com/2009/04/cobol-uma-odisseia-de-1959-ao-ibm-z.html
