 |
| Bellacosa Mainframe e a Crise no Mundo Mainframe nos anos 1980 |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
IBM NOS ANOS 1980: O DIA EM QUE O MAINFRAME VIROU PEDRA — E DR. STONE PRECISOU RECONSTRUIR A INFORMÁTICA!
A incrível história do System/370, do misterioso S/380 que nunca existiu, do antitruste americano, da revolução dos microcomputadores, do MS-DOS, dos clones e do mundo que mudou enquanto a IBM tentava sobreviver.
Bellacosa Mainframe — Arqueologia da Computação, COBOL, Tecnologia e os Fantasmas dos Sistemas Legados
Prólogo — Dez bilhões por cento de ciência, COBOL e café!
Imagine a seguinte situação.
Estamos em um centro de processamento de dados no início dos anos 1980.
Uma imensa sala climatizada abriga computadores IBM, unidades de discos, fitas magnéticas e terminais 3270. Operadores acompanham consoles, técnicos inspecionam equipamentos e programadores COBOL corrigem programas que movimentam milhões de registros.
O ambiente parece saído de uma instalação científica ultrassecreta.
De repente, uma misteriosa luz atravessa o planeta e transforma todos os profissionais da informática em estátuas de pedra.
Milhares de anos depois, Senku Ishigami, o extraordinário protagonista de Dr. Stone, desperta diante das ruínas daquele antigo CPD.
Ao lado de uma máquina IBM System/370, encontra uma caixa de cartões perfurados, uma fita magnética e um manual de COBOL.
Seu primeiro desafio é descobrir por que uma civilização capaz de construir computadores gigantescos decidiu colocar máquinas cada vez menores sobre as mesas dos funcionários.
Seu segundo desafio é ainda mais difícil: compreender como a empresa que dominava a informática mundial acabou enfrentando uma das maiores crises de sua história.
E o terceiro?
Descobrir por que nunca existiu um IBM System/380!
Bem-vindos ao Reino da Ciência Mainframe!
Nesta aventura, cada capítulo será uma experiência histórica. Vamos reconstruir os acontecimentos utilizando documentos, lógica, tecnologia e algumas boas doses de curiosidade.
Observação: Senku e os demais personagens de Dr. Stone aparecem aqui como recursos narrativos de uma aventura imaginária. Os acontecimentos históricos são reais; suas intervenções no CPD são ficcionais.
Capítulo I — 1964: A primeira grande fórmula da civilização IBM
Antes de investigar a crise dos anos 1980, precisamos voltar a 7 de abril de 1964.
Naquela data, a IBM anunciou o System/360, uma família de computadores que ajudaria a redefinir o conceito de arquitetura de sistemas.
Antes dele, organizações frequentemente enfrentavam dificuldades significativas ao migrar aplicações entre computadores de diferentes classes.
A IBM propôs uma solução ambiciosa: uma família de máquinas que compartilhassem uma arquitetura compatível.
Isso permitiria que uma organização começasse com um equipamento menor e, conforme suas necessidades aumentassem, migrasse para outro mais poderoso preservando grande parte de seu investimento em software.
Para um programador COBOL, a ideia era extraordinária.
Imagine desenvolver um sistema de folha de pagamento contendo milhares de linhas de código.
Se a empresa precisasse adquirir um computador maior, seria desejável aproveitar o programa existente, em vez de reconstruí-lo do zero.
A compatibilidade arquitetural passou a ser uma das grandes vantagens dos computadores IBM.
A fórmula científica da compatibilidade
Podemos representar essa estratégia de maneira simplificada:
Arquitetura estável + evolução tecnológica + preservação dos programas = proteção do investimento empresarial.
É importante destacar que compatibilidade não significa que todo programa executaria em qualquer modelo sem adaptações.
Sistemas operacionais, periféricos, requisitos de memória e características específicas das instalações também precisavam ser considerados.
Mas a direção estava estabelecida.
O System/360 não era simplesmente um computador. Era uma proposta de continuidade tecnológica.
Em 1970, essa evolução prosseguiu com o System/370.
E começava nossa primeira investigação.
Capítulo II — O enigma do System/380: onde está o computador desaparecido?
Imagine Senku examinando uma sequência de documentação técnica.
System/360.
System/370.
System/390.
Ele interrompe a investigação.
Onde foi parar o 380?
A primeira hipótese seria imaginar que a IBM planejou um System/380, mas cancelou o projeto por causa da crise econômica.
A segunda hipótese seria atribuir o desaparecimento ao processo antitruste americano.
A terceira seria imaginar que o sucesso do IBM PC obrigou a empresa a abandonar a nomenclatura.
Mas ciência não funciona com suposições transformadas em certezas.
Precisamos examinar os fatos.
A evolução real
Depois do System/370, a IBM continuou desenvolvendo diversas famílias de máquinas.
Entre elas encontramos:
IBM 3031, 3032 e 3033.
IBM 3081 e outros modelos da família 308x.
IBM 3090, anunciado em 1985.
IBM System/390, apresentado em 1990.
Ao mesmo tempo, a arquitetura evoluiu.
A introdução e expansão do endereçamento virtual, os aperfeiçoamentos de processamento e as novas arquiteturas ESA contribuíram para manter a plataforma competitiva.
Os computadores ficaram mais rápidos e sofisticados.
A IBM não interrompeu a evolução técnica entre o System/370 e o System/390.
O que aconteceu foi uma evolução utilizando diferentes nomes comerciais, modelos de processadores e extensões arquiteturais.
Atenção, jovem aprendiz de COBOL: não existe evidência histórica suficiente para afirmar que a ausência do nome System/380 foi causada por uma decisão política ou por um projeto secreto cancelado.
O System/380 é um excelente enigma para um artigo de arqueologia tecnológica, mas não devemos inventar uma explicação documental.
Curiosidade científica
O IBM 3081 introduziu o Thermal Conduction Module, uma tecnologia sofisticada de encapsulamento e dissipação térmica.
Isso nos lembra de uma questão fundamental: computadores não evoluem apenas através de linguagens de programação.
Materiais, eletrônica, refrigeração, memória e armazenamento também determinam o desempenho dos sistemas.
Uma excelente aula de engenharia para o Reino da Ciência!
Capítulo III — 1969: O governo americano coloca a IBM no banco dos réus
Agora precisamos investigar um conflito muito anterior à explosão dos PCs.
Em 17 de janeiro de 1969, o Departamento de Justiça dos Estados Unidos iniciou uma ação antitruste contra a IBM.
A acusação central envolvia alegações de monopolização ilegal de um mercado de computadores de uso geral.
Na época, a IBM exercia enorme influência sobre a informática empresarial.
Fornecia processadores, sistemas operacionais, programas, periféricos, manutenção e serviços.
Mas uma pergunta precisava ser respondida:
Dominar um mercado é automaticamente ilegal?
Não.
A legislação antitruste americana diferencia a existência de poder de mercado das práticas ilegais utilizadas para adquiri-lo ou preservá-lo.
Uma empresa pode conquistar grande participação porque oferece produtos excelentes.
Outra questão é utilizar determinadas condutas para excluir ilegalmente seus concorrentes.
O governo examinou práticas comerciais da IBM e sua influência sobre fabricantes de equipamentos compatíveis.
Imagine uma empresa que desejasse utilizar uma CPU IBM com discos de outro fabricante.
A compatibilidade de interfaces podia determinar se essa escolha seria economicamente viável.
Fabricantes independentes dependiam de informações técnicas para desenvolver produtos capazes de trabalhar com equipamentos IBM.
Uma descoberta importante: o caso de 1956
A história é mais complexa do que parece.
Já existia um acordo judicial antitruste de 1956, relacionado a uma disputa anterior.
Portanto, não devemos confundir três acontecimentos:
O acordo antitruste de 1956.
O processo iniciado em 1969.
A posterior revisão de restrições aplicáveis à empresa.
Em 1969, a IBM também anunciou a separação comercial de determinados softwares e serviços dos preços de equipamentos, prática conhecida como unbundling.
Essa mudança teve enorme significado para o surgimento de uma indústria independente de software.
É comum associá-la ao ambiente antitruste, mas seria simplista afirmar que o processo iniciado naquele ano foi sua única causa.
O mercado e as decisões empresariais já estavam passando por transformações.
O surpreendente final do julgamento
Em 8 de janeiro de 1982, o governo americano decidiu abandonar a ação iniciada em 1969.
Não houve uma condenação judicial final da IBM naquele processo.
O Departamento de Justiça avaliou que não conseguiria demonstrar adequadamente as acusações de monopolização ilegal apresentadas.
A empresa não saiu desse episódio com uma sentença condenatória, embora o longo processo tenha produzido consequências organizacionais, jurídicas e estratégicas.
Nosso primeiro experimento científico está concluído.
Hipótese: a IBM foi condenada por monopolizar a informática em 1982.
Resultado: hipótese falsa.
Capítulo IV — 1973 e 1979: o petróleo invade o CPD
Agora Senku encontra uma informação aparentemente desconectada da informática.
Crise do petróleo.
O que barris de petróleo têm a ver com computadores IBM?
Muito mais do que parece.
Em 1973, o embargo petrolífero árabe, associado ao contexto da Guerra do Yom Kippur, provocou uma grande perturbação no mercado internacional de energia.
O preço do petróleo disparou.
Em 1979, a Revolução Iraniana contribuiu para um segundo grande choque energético.
As consequências atingiram transportes, fábricas, comércio e investimentos.
Os governos enfrentavam aumento de preços, dificuldades econômicas e crescimento reduzido.
Uma combinação particularmente desagradável recebeu o nome de estagflação.
Era possível ter inflação elevada e, simultaneamente, uma economia enfraquecida.
Para empresas que dependiam de grandes investimentos tecnológicos, a situação criava dificuldades.
Quanto custava manter um mainframe?
Não bastava comprar o processador.
Uma instalação típica também precisava considerar:
Equipamentos de armazenamento e comunicação.
Energia elétrica e refrigeração.
Manutenção especializada.
Sistemas operacionais e software.
Salários de operadores e programadores.
Espaço físico.
Expansão de capacidade.
Contratos de aquisição ou locação.
Naturalmente, os custos variavam conforme o porte e o contrato.
Mas, quando os juros aumentavam e os investimentos se tornavam mais difíceis, diretores financeiros começavam a analisar alternativas.
Um sistema central continuava sendo indispensável para determinadas atividades.
Porém, seria realmente necessário utilizar recursos centrais para produzir uma simples planilha departamental?
Essa pergunta abriu espaço para os microcomputadores.
A inflação não foi igual no planeta inteiro
Aqui precisamos corrigir outro mito.
Os Estados Unidos enfrentaram inflação elevada, chegando perto de 15% na medição anual durante 1980.
Mas isso não representa hiperinflação mundial.
Hiperinflação possui significado econômico específico e costuma ser associada a aumentos de preços superiores a 50% ao mês.
Na América Latina, alguns países enfrentaram episódios muito mais extremos.
Brasil, Argentina, Bolívia e Peru viveram graves crises inflacionárias em períodos distintos.
A crise da dívida externa latino-americana, especialmente a partir de 1982, agravou os problemas regionais.
Portanto, o impacto econômico sobre uma instalação IBM no Brasil podia ser muito diferente daquele enfrentado por uma empresa americana.
Uma aquisição financiada em moeda estrangeira representava desafios adicionais para uma organização brasileira.
Dica para o programador COBOL
Quando estudar sistemas legados, não examine apenas a tecnologia.
Investigue também o ambiente econômico em que foram construídos.
Muitos programas foram desenvolvidos para atender restrições muito específicas de custo, armazenamento, processamento e legislação.
A história econômica frequentemente explica decisões de arquitetura que parecem estranhas quando observadas quarenta anos depois.
Capítulo V — 1977: os computadores pequenos começam a conquistar o planeta
Estamos em 1977.
Enquanto os grandes sistemas empresariais continuam operando, uma revolução acontece fora dos centros de processamento de dados.
O Apple II, o Commodore PET e o TRS-80 aparecem como representantes de uma nova geração comercial de microcomputadores.
Eram equipamentos muito mais modestos que os mainframes.
Utilizavam processadores de 8 bits, pequenas quantidades de memória e armazenamento limitado.
Mas tinham uma característica revolucionária.
Uma pessoa podia possuir seu próprio computador.
Antes, acessar poder computacional muitas vezes significava depender de uma universidade, empresa ou instituição.
Agora, estudantes, pequenos empresários e entusiastas podiam programar seus próprios equipamentos.
O BASIC tornou-se uma das portas de entrada para a computação.
Um simples programa podia despertar o interesse de futuros engenheiros.
10 PRINT "BELLACOSA MAINFRAME"
20 PRINT "BEM-VINDO AO REINO DA CIENCIA"
30 GOTO 10Naturalmente, o pequeno computador não conseguiria substituir diretamente um grande sistema bancário.
Mas isso não era necessário para transformar o mercado.
O microcomputador precisava apenas resolver problemas suficientemente importantes para seus usuários.
O segredo das planilhas eletrônicas
Em 1979, surgiu o VisiCalc para o Apple II.
A possibilidade de criar e recalcular planilhas eletrônicas transformou a utilização comercial dos computadores pessoais.
Antes, muitos cálculos departamentais dependiam de processos manuais ou solicitações ao departamento de informática.
Agora, um profissional podia alterar valores e observar resultados imediatamente.
No começo dos anos 1980, o Lotus 1-2-3 ajudaria a consolidar esse mercado nos IBM PCs e compatíveis.
Esse foi um grande desafio cultural para os CPDs.
Os departamentos não queriam necessariamente abandonar o mainframe.
Queriam autonomia.
E autonomia era algo que as novas máquinas começavam a proporcionar.
Capítulo VI — 1981: a IBM cria o PC e abre a caixa de Pandora
Em 12 de agosto de 1981, a IBM apresentou o Personal Computer 5150.
O equipamento utilizava o processador Intel 8088.
Embora fosse associado à família x86 de 16 bits, o 8088 possuía barramento externo de dados de 8 bits.
Esse detalhe contribuiu para viabilizar um projeto baseado em componentes disponíveis comercialmente.
O IBM PC não foi o primeiro computador pessoal da história.
Mas o nome IBM ajudou a legitimar o uso do PC dentro das empresas.
A equipe liderada por Don Estridge, em Boca Raton, desenvolveu o produto utilizando uma abordagem incomum para os padrões tradicionais da companhia.
Em vez de criar internamente cada componente, o projeto incorporou tecnologias de diferentes fornecedores.
A arquitetura aberta
A IBM publicou documentação técnica que facilitava o desenvolvimento de placas, periféricos e programas para o PC.
Essa decisão ajudou a criar um ecossistema extraordinário.
Entretanto, também abriu oportunidades para concorrentes.
Empresas começaram a desenvolver computadores capazes de executar programas destinados ao IBM PC.
Nascia a grande expansão dos compatíveis.
É importante lembrar que arquitetura aberta não significava autorização para copiar indiscriminadamente o código do BIOS.
Fabricantes precisavam respeitar os direitos autorais e desenvolver implementações próprias.
A engenharia reversa independente teve papel importante nesse processo.
A ironia histórica
A IBM criou uma plataforma comercialmente bem-sucedida.
Mas não conseguiu manter controle exclusivo sobre todos os componentes que definiriam seu futuro.
Processadores Intel, sistemas operacionais Microsoft e equipamentos fabricados por outras empresas passaram a compartilhar um padrão técnico.
O mercado começou a falar cada vez mais em computadores compatíveis com IBM PC, e não necessariamente em computadores fabricados pela IBM.
Capítulo VII — MS-DOS: o pequeno sistema operacional que mudou o equilíbrio de poder
O universo dos microcomputadores também estava passando por uma revolução em software.
Gary Kildall e a Digital Research haviam desenvolvido o CP/M, que se tornou importante na primeira geração de microcomputadores.
Quando a IBM procurou um sistema operacional para seu novo PC, as negociações não resultaram no fornecimento do CP/M como sistema principal da máquina.
A Microsoft acabou fornecendo a solução que seria conhecida como PC DOS na versão comercializada pela IBM.
Sua origem estava ligada ao 86-DOS, desenvolvido por Tim Paterson na Seattle Computer Products.
O MS-DOS tornou-se uma das bases da indústria de PCs compatíveis.
Imagine a seguinte tela:
C:\>DIR
C:\>COPY CLIENTES.DAT B:\
C:\>TYPE RELATORIO.TXTUm usuário podia navegar pelo disco, copiar arquivos e executar aplicações sem conhecer JCL, TSO ou a estrutura de um sistema operacional mainframe.
É claro que isso não significava possuir os mesmos recursos de segurança, compartilhamento e processamento corporativo.
Mas a simplicidade relativa de acesso ajudou a conquistar milhões de usuários.
O verdadeiro segredo da Microsoft
O mercado de sistemas operacionais não ficou restrito aos computadores fabricados pela IBM.
A Microsoft podia fornecer seu software a outros fabricantes de PCs compatíveis.
Quanto mais máquinas compatíveis eram vendidas, maior se tornava o mercado potencial de aplicações para MS-DOS.
Esse processo criou um efeito de rede.
Mais computadores atraíam mais desenvolvedores.
Mais programas tornavam a plataforma mais interessante para novos compradores.
O resultado foi uma extraordinária expansão do ecossistema PC.
Capítulo VIII — 1986: os clones desafiam o criador
A Compaq tornou-se um dos grandes símbolos dessa revolução.
Em 1983, comercializou um computador portátil compatível com o IBM PC.
Mas o acontecimento mais emblemático veio em 1986.
A empresa apresentou o Deskpro 386, utilizando o processador Intel 80386 antes de a IBM lançar um PC equivalente.
O 80386 introduzia recursos avançados de uma arquitetura x86 de 32 bits.
Para o mercado, a mensagem era poderosa.
Uma empresa que não havia criado originalmente o padrão podia liderar sua evolução tecnológica.
A IBM continuava sendo uma grande fabricante.
Mas já não controlava sozinha o ritmo dos lançamentos.
O PS/2 e a tentativa de reorganização
Em 1987, a IBM apresentou a família Personal System/2.
Alguns modelos utilizavam a nova Micro Channel Architecture, conhecida como MCA.
A tecnologia oferecia características avançadas, mas também exigia novas placas de expansão e envolvia condições de licenciamento.
Fabricantes de compatíveis resistiram à dependência dessa arquitetura.
O setor continuou desenvolvendo alternativas baseadas em padrões mais amplamente adotados.
A batalha dos PCs já não era apenas uma disputa por velocidade de processadores.
Era uma guerra por padrões industriais.
Curiosidade
É perfeitamente possível que um fabricante crie uma tecnologia excelente e ainda assim não consiga transformá-la no padrão dominante.
Compatibilidade, preço, licenciamento e quantidade de usuários podem ser tão importantes quanto desempenho.
Essa é uma lição que continua válida para hardware, sistemas operacionais, APIs e plataformas de software.
Capítulo IX — Laboratório Senku: construindo nosso primeiro programa COBOL
Finalmente chegamos ao laboratório.
Imagine que estamos em 1985.
Um departamento utiliza microcomputadores para preparar informações locais, mas o processamento corporativo permanece no mainframe.
Nosso desafio será construir um pequeno programa COBOL responsável por calcular o saldo final de uma conta fictícia.
O programa deverá:
Definir um saldo inicial.
Aplicar um depósito.
Subtrair um pagamento.
Apresentar o resultado.
Identificar se o saldo ficou negativo.
Não precisamos de CICS ou Db2 para compreender o conceito inicial.
Vamos começar com COBOL tradicional.
Experimento 1 — O programa
IDENTIFICATION DIVISION.
PROGRAM-ID. LAB1985.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-SALDO-INICIAL PIC 9(5)V99.
01 WS-DEPOSITO PIC 9(5)V99.
01 WS-PAGAMENTO PIC 9(5)V99.
01 WS-SALDO-FINAL PIC S9(6)V99.
01 WS-EDITADO PIC -ZZZZZ9.99.
PROCEDURE DIVISION.
MOVE 1500.00 TO WS-SALDO-INICIAL
MOVE 350.00 TO WS-DEPOSITO
MOVE 275.00 TO WS-PAGAMENTO
COMPUTE WS-SALDO-FINAL =
WS-SALDO-INICIAL
+ WS-DEPOSITO
- WS-PAGAMENTO
END-COMPUTE
MOVE WS-SALDO-FINAL TO WS-EDITADO
DISPLAY "BELLACOSA MAINFRAME"
DISPLAY "LABORATORIO COBOL 1985"
DISPLAY "SALDO FINAL: " WS-EDITADO
IF WS-SALDO-FINAL < ZERO
DISPLAY "ATENCAO: SALDO NEGATIVO"
ELSE
DISPLAY "SALDO NAO NEGATIVO"
END-IF
GOBACK.Este exemplo utiliza convenções de código em formato fixo, típicas de programas COBOL tradicionais. As linhas de código começam na área apropriada para esse formato.
Experimento 2 — Entendendo a estrutura
IDENTIFICATION DIVISION
Identifica o programa.
Nesse caso, seu nome é LAB1985.
DATA DIVISION
Define os dados utilizados pelo programa.
WORKING-STORAGE SECTION
Declara variáveis disponíveis durante a execução.
PROCEDURE DIVISION
Contém as instruções que realizam o processamento.
Experimento 3 — O significado do PIC
Observe:
01 WS-DEPOSITO PIC 9(5)V99.O 9(5) representa cinco posições numéricas inteiras.
O V99 representa duas posições decimais implícitas.
Isso permite armazenar valores com duas casas decimais sem manter um ponto decimal físico na representação numérica.
Para cálculos financeiros simples, esse conceito é fundamental.
Observe também:
01 WS-SALDO-FINAL PIC S9(6)V99.O S indica que o campo admite sinal.
Escolhemos um campo assinado porque o resultado pode ser negativo.
Em um sistema financeiro real, os tipos de dados devem ser escolhidos com atenção à amplitude dos valores, precisão, arredondamento, sinal e possíveis condições de erro.
Experimento 4 — Calculando o resultado
Nosso processamento é:
Saldo inicial: 1.500,00.
Depósito: 350,00.
Pagamento: 275,00.
Resultado:
1.500,00 + 350,00 − 275,00 = 1.575,00.
O COBOL executa o cálculo com COMPUTE.
O campo WS-EDITADO prepara a representação para exibição, incluindo o ponto decimal e o sinal quando necessário.
Experimento 5 — Testando situações especiais
Agora altere o valor do pagamento para 2.000,00.
O resultado será negativo.
O programa deverá informar essa condição.
Esse exercício demonstra um princípio essencial da programação empresarial:
Um programa não precisa apenas calcular resultados corretos. Precisa tratar situações excepcionais de maneira previsível.
Experimento 6 — Como executar num ambiente mainframe
Em um ambiente de estudos com z/OS, o processo geral seria:
Acessar o ambiente autorizado de desenvolvimento.
Criar um membro contendo o código-fonte COBOL.
Verificar se o código está no formato esperado pelo compilador.
Utilizar um procedimento de compilação e linkedição disponível na instalação.
Executar o programa.
Consultar o resultado pelo SDSF ou ferramenta equivalente.
Comparar a saída obtida com o resultado esperado.
Corrigir eventuais erros e repetir o teste.
Os nomes de bibliotecas, compiladores e procedimentos variam entre ambientes.
Por isso, o exemplo não presume um JCL universal que funcionaria automaticamente em qualquer instalação.
Experimento 7 — O que mudou desde 1985?
Atualmente, o mesmo exercício pode ser desenvolvido utilizando ferramentas modernas de edição e integração com ambientes mainframe.
Mas a lógica fundamental permanece reconhecível.
Variáveis, regras de negócio, cálculos, validações e testes continuam sendo conceitos indispensáveis.
O equipamento evoluiu.
A disciplina de programação permaneceu.
Capítulo X — MVS, CICS, VSAM e Db2: os guardiões do Reino Mainframe
Mas por que um programa COBOL empresarial continuaria sendo executado em um mainframe se os PCs estavam ficando cada vez melhores?
A resposta aparece quando examinamos o problema da escala.
Imagine que nosso programa de laboratório precise processar uma única conta.
Praticamente qualquer computador pessoal moderno consegue realizar essa operação.
Agora imagine milhões de contas, usuários simultâneos, transações concorrentes, auditorias, registros persistentes e regras rigorosas de integridade.
A situação é completamente diferente.
MVS
O MVS oferecia os recursos fundamentais de gerenciamento necessários à operação de grandes sistemas IBM.
Processamento em lote, gerenciamento de recursos e execução de aplicações faziam parte desse ambiente.
CICS
O CICS permitia construir e executar aplicações transacionais.
Pense em operações bancárias, consultas, atualizações e interação de múltiplos usuários.
O CICS se tornou uma peça extremamente importante no mundo corporativo.
VSAM
O VSAM fornecia métodos organizados de armazenamento e acesso a dados.
Arquivos sequenciais, indexados e outras estruturas podiam atender diferentes necessidades das aplicações.
Db2
O Db2, introduzido comercialmente na década de 1980, representou um passo importante na adoção de bancos de dados relacionais no ambiente IBM.
Seu modelo permitia utilizar SQL para consultar e manipular dados.
Para programadores COBOL, isso significava novas possibilidades de integração entre aplicações e gerenciamento de dados.
A descoberta fundamental
Mainframes e microcomputadores não eram apenas versões grandes e pequenas da mesma ideia.
Cada plataforma apresentava características, objetivos e limitações diferentes.
A evolução da informática empresarial acabaria combinando múltiplas tecnologias.
O mundo cliente-servidor estava se aproximando.
Capítulo XI — Guerra Fria: a ciência dividida pelo Muro de Berlim
Enquanto a IBM enfrentava transformações comerciais, a Europa estava dividida.
De um lado, os países associados ao bloco ocidental.
Do outro, a União Soviética e seus aliados.
A computação tinha enorme importância militar, científica e econômica.
O desenvolvimento de semicondutores, sistemas operacionais, equipamentos de comunicação e computadores avançados estava associado também a políticas estratégicas.
Os países socialistas possuíam suas próprias indústrias de computadores.
A Alemanha Oriental, por exemplo, desenvolveu equipamentos comercializados pela Robotron.
Na União Soviética e em países aliados, a linha ES EVM procurava fornecer uma família de computadores compatíveis, em diferentes graus, com tecnologias ocidentais.
Portanto, não seria correto afirmar que a computação simplesmente não existia no bloco socialista.
O desafio era outro.
As restrições de acesso a determinadas tecnologias, as estruturas econômicas, a coordenação industrial e as dificuldades de produção afetavam sua capacidade de competir em vários segmentos.
1985: Gorbachev chega ao poder
Mikhail Gorbachev assumiu a liderança soviética em 1985.
Suas políticas de perestroika e glasnost buscavam promover reformas econômicas e maior abertura.
Mas os problemas estruturais eram profundos.
A insatisfação social crescia em diversos países da Europa Oriental.
Movimentos políticos exigiam transformações.
Em 9 de novembro de 1989, o Muro de Berlim foi aberto.
Imagens de cidadãos atravessando a fronteira e celebrando sobre o muro tornaram-se símbolos de uma mudança histórica.
Em 1990, a Alemanha foi reunificada.
Em 1991, a União Soviética deixou de existir.
O impacto sobre a informática
A abertura de novos mercados criava oportunidades para empresas ocidentais.
Instituições financeiras, organizações públicas e empresas precisavam modernizar seus sistemas.
Computadores pessoais, redes, servidores e plataformas corporativas participariam dessa transformação.
Mas existe um detalhe indispensável para nossa investigação.
A queda do Muro não causou a crise da IBM.
Os problemas competitivos da empresa já estavam em desenvolvimento.
Os acontecimentos políticos alteraram o cenário internacional, mas não explicam isoladamente as dificuldades comerciais da companhia.
Um cientista cuidadoso separa acontecimentos simultâneos de relações causais comprovadas.
Capítulo XII — 1990: o System/390 chega para impedir a petrificação
O ano de 1990 marcou a apresentação da família IBM System/390.
A arquitetura mainframe continuava evoluindo.
O lançamento representava a continuidade de décadas de compatibilidade e aperfeiçoamentos.
Entretanto, a IBM enfrentava um problema que não podia ser resolvido apenas com processadores mais rápidos.
O mercado empresarial estava mudando.
Clientes adotavam redes locais, sistemas Unix, PCs compatíveis, bancos de dados e servidores departamentais.
Novos fornecedores competiam em segmentos anteriormente associados aos grandes fabricantes.
A IBM possuía tecnologias extraordinárias, mas precisava adaptar sua organização, estratégia comercial e estrutura de custos.
As dificuldades financeiras mais graves apareceriam no início dos anos 1990.
Em 1993, a companhia registraria um prejuízo anual de aproximadamente 8 bilhões de dólares.
O impacto foi extraordinário para uma empresa que durante décadas simbolizara o poder da indústria informática.
A recuperação exigiria uma transformação profunda.
E essa história merece outro capítulo inteiro.
Capítulo XIII — Dez curiosidades para o arqueólogo mainframe
1. O mainframe nunca dependeu apenas de força bruta
A importância de um grande sistema envolve também disponibilidade, integridade, segurança, administração de recursos e processamento simultâneo.
2. Compatibilidade é um patrimônio invisível
Milhares de programas antigos continuam relevantes porque representam regras empresariais construídas ao longo de décadas.
3. O IBM PC não nasceu dentro do modelo tradicional de desenvolvimento da IBM
A equipe de Boca Raton trabalhou com maior autonomia e aproveitou componentes externos para acelerar o projeto.
4. O 8088 era um processador com características de 16 bits e barramento externo de 8 bits
Esse detalhe ajuda a explicar escolhas de engenharia do PC original.
5. A revolução dos microcomputadores começou antes do IBM PC
Os equipamentos de 1977 e seus antecessores já demonstravam o potencial da computação pessoal.
6. A Compaq antecipou a IBM no lançamento de um PC baseado no 80386
Isso simbolizou a perda do controle exclusivo sobre a evolução do padrão PC.
7. A IBM foi processada, mas não condenada no caso antitruste encerrado em 1982
É um dos detalhes jurídicos mais frequentemente apresentados incorretamente.
8. A inflação americana não foi hiperinflação
A expressão deve ser utilizada com precisão histórica e econômica.
9. O Muro de Berlim caiu antes do colapso da União Soviética
Os acontecimentos ocorreram em 1989 e 1991, respectivamente.
10. O COBOL atravessou todas essas transformações
O valor das aplicações empresariais preservadas ajuda a explicar a extraordinária longevidade da linguagem.
Capítulo XIV — Dez dicas para quem está começando no COBOL
Primeira dica: compreenda a evolução histórica. Conhecer System/360, System/370 e System/390 ajuda a entender por que a compatibilidade é tão valorizada.
Segunda dica: aprenda as quatro divisões tradicionais do COBOL. Identification, Environment, Data e Procedure formam a estrutura clássica da linguagem, embora programas simples nem sempre precisem declarar todas explicitamente.
Terceira dica: domine o PICTURE. Entender PIC 9, PIC X, V e S é fundamental para trabalhar com dados.
Quarta dica: estude formatos numéricos. DISPLAY, COMP e COMP-3 possuem características diferentes que influenciam armazenamento e operações.
Quinta dica: pratique validações. Programas empresariais precisam tratar dados incorretos, valores inesperados e condições excepcionais.
Sexta dica: conheça JCL. No ambiente batch tradicional do z/OS, a linguagem de controle de jobs é essencial para compreender a execução operacional.
Sétima dica: aprenda a consultar resultados. Saber analisar mensagens, códigos de retorno e saídas no SDSF é tão importante quanto escrever o código.
Oitava dica: estude VSAM e Db2. Os dados são parte central da maioria das aplicações empresariais.
Nona dica: conheça CICS e terminais 3270. Eles ajudam a compreender como aplicações online tradicionais foram construídas e utilizadas.
Décima dica: não trate código legado como código inútil. Antes de substituir um programa, descubra quais regras de negócio ele implementa, quem depende dele e quais riscos uma mudança representa.
Capítulo XV — O desafio final de Dr. Stone: reconstruir um CPD com conhecimento científico
Imagine que Senku tivesse de reconstruir uma instalação IBM depois da petrificação da humanidade.
Certamente seria necessário compreender eletrônica, física, materiais, energia elétrica e processos industriais.
Mas mesmo com todo esse conhecimento, reconstruir um mainframe funcional seria um empreendimento imenso.
Um sistema dessa complexidade representa o resultado acumulado de gerações de engenharia.
Precisaríamos recuperar documentação, tecnologias de semicondutores, processos de fabricação, armazenamento, interfaces e sistemas operacionais.
E ainda existiria um desafio aparentemente menos espetacular, mas igualmente importante.
Reconstruir os programas que fazem o computador ser útil.
Uma CPU capaz de executar milhões de instruções não resolve automaticamente um problema bancário.
Precisamos definir arquivos, estruturas de dados, regras, validações, operações e controles.
É nesse momento que o COBOL reaparece.
A linguagem foi concebida para expressar operações empresariais de maneira relativamente próxima dos conceitos utilizados nas organizações.
Não depende de efeitos gráficos extraordinários.
Seu propósito é representar e executar regras de processamento.
Talvez seja justamente essa simplicidade conceitual que explique parte de sua resistência ao tempo.
O mundo mudou.
Os computadores ficaram menores.
As redes se expandiram.
A internet surgiu.
A inteligência artificial passou a participar do desenvolvimento de software.
Mas as organizações continuam precisando calcular salários, processar pagamentos, movimentar contas, administrar contratos e preservar informações.
A necessidade de confiabilidade não desapareceu.
Epílogo — O mainframe que se recusou a virar pedra
Nossa investigação começou com um enigma: por que a IBM, aparentemente invencível, entrou em crise?
Descobrimos que a resposta não está em um único acontecimento.
O System/370 continuou evoluindo, embora a IBM não tenha lançado uma família comercial chamada System/380.
O processo antitruste iniciado em 1969 terminou sem condenação final naquela ação.
Os choques do petróleo e a inflação alteraram o ambiente econômico.
Os microcomputadores de 8 bits levaram a informática para fora dos grandes centros de processamento.
O IBM PC legitimou a computação pessoal no mercado empresarial.
O MS-DOS e os computadores compatíveis ajudaram a consolidar um enorme ecossistema independente da fabricação exclusiva da IBM.
A Compaq demonstrou que os concorrentes podiam desenvolver novas gerações de computadores sem esperar pela criadora do padrão.
A Guerra Fria se aproximou do fim.
O Muro de Berlim caiu.
E a IBM chegou aos anos 1990 precisando reinventar profundamente seu modelo de negócios.
Mas o mainframe não desapareceu.
Ele evoluiu.
E o COBOL continuou sendo uma linguagem importante para aplicações empresariais.
O verdadeiro legado dessa história é que nenhuma tecnologia permanece relevante apenas por causa de seu passado.
Ela precisa continuar resolvendo problemas reais.
Para quem está começando no COBOL, essa talvez seja a maior lição de toda a aventura.
Não basta decorar comandos.
Precisamos compreender por que os sistemas foram construídos, quais necessidades atendem e como podem continuar evoluindo.
A ciência de Dr. Stone nos lembra da importância de reconstruir o conhecimento a partir dos princípios fundamentais.
No Bellacosa Mainframe, fazemos a mesma coisa com a arqueologia da computação.
Abrimos os manuais esquecidos, examinamos antigas arquiteturas, investigamos decisões empresariais e descobrimos que o passado continua vivo dentro de muitos dos sistemas atuais.
E, enquanto houver uma aplicação COBOL executando uma regra de negócio importante, haverá uma boa razão para continuar estudando a história dos gigantes de silício.
Porque, no Reino da Ciência Mainframe, o conhecimento nunca vira pedra.
Bellacosa Mainframe — Porque antes da nuvem existia o CPD. Antes dos micros existiam os grandes sistemas. E antes de declarar a morte do COBOL, alguém deveria verificar se o processamento batch terminou com RC=0000.
FIM — OU MELHOR, CONTINUE NO PRÓXIMO JOB.
Referências históricas recomendadas
IBM — The IBM PC: https://www.ibm.com/history/personal-computer
IBM — System/360: Revolution and Evolution: https://www.ibm.com/support/pages/zvm/history/360rev.pdf
Departamento de Justiça americano — United States' Memorandum on the 1969 Case: https://www.justice.gov/atr/case-document/united-states-memorandum-1969-case
Computer History Museum — The IBM PC: https://www.computerhistory.org/revolution/personal-computers/17/301
Computer History Museum — Timeline 1986: https://www.computerhistory.org/timeline/1986/
Federal Reserve History — The Great Inflation: https://www.federalreservehistory.org/essays/great-inflation
Shonen Jump — Dr. STONE: https://www.shonenjump.com/j/rensai/drstone/
