☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta ibm. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta ibm. Mostrar todas as mensagens

quinta-feira, 5 de novembro de 2026

🎭 GREAT PRETENDER: O GOLPE DE US$ 1,2 BILHÃO — EDAMAME, A ENTER E A GUERRA DAS OABs PELO CONTROLE DA JUSTIÇA!

 

Bellacosa Mainframe e o roubo do século

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🎭 GREAT PRETENDER: O GOLPE DE US$ 1,2 BILHÃO — EDAMAME, A ENTER E A GUERRA DAS OABs PELO CONTROLE DA JUSTIÇA!

Quando uma inteligência artificial começou a preparar milhares de defesas judiciais, uma startup brasileira virou unicórnio, os advogados entraram em guerra e Makoto Edamura descobriu que o maior truque não era enganar alguém — era descobrir quem realmente estava tomando as decisões.

Bellacosa Mainframe — Arqueologia da Computação, COBOL, Inteligência Artificial, Segurança Digital e os Fantasmas da Justiça Automatizada

5 de novembro de 2026 | Tecnologia, Direito, Mainframe e Sociedade

Nota editorial: Os personagens de Great Pretender participam desta história como recurso narrativo fictício. Os acontecimentos envolvendo a Enter e a OAB são reais, mas as acusações permanecem em discussão judicial. Nenhuma fraude da Enter foi comprovada por esta investigação. Os diálogos e as situações protagonizadas pelos personagens do anime são imaginários.



🎬 Prólogo — O dia em que Edamame descobriu que o maior golpe talvez estivesse escondido num algoritmo

São Paulo, novembro de 2026.

O relógio marcava sete horas da manhã quando Makoto Edamura, conhecido internacionalmente como Edamame, entrou numa cafeteria da Avenida Paulista.

O jovem japonês carregava uma mochila, um notebook e uma expressão preocupada.

Na televisão, uma reportagem anunciava:

Uma startup brasileira de inteligência artificial, avaliada em US$ 1,2 bilhão, estava no centro de uma disputa judicial com a Ordem dos Advogados do Brasil.

Edamame quase derrubou o café.

— Um bilhão e duzentos milhões de dólares? Por um software que escreve documentos?

Sentado diante dele, Laurent Thierry, o elegante vigarista francês de Great Pretender, sorriu.

— Meu caro Edamame, você ainda pensa como um ladrão de carteiras. O verdadeiro dinheiro está na transformação de mercados inteiros.

— Você está dizendo que essa empresa é uma fraude?

— Absolutamente não. Uma empresa valiosa não é necessariamente fraudulenta. Mas toda operação sofisticada merece uma pergunta: quem controla o jogo?

Na tela apareceu o nome da companhia.

ENTER.

Fundada em 2023 por Mateus Costa-Ribeiro, Henrique Vaz e Michael Mac-Vicar, a empresa brasileira havia anunciado, em maio de 2026, uma rodada de investimentos superior a US$ 100 milhões, liderada pelo Founders Fund.

A avaliação alcançara US$ 1,2 bilhão.

Para o mercado financeiro, um novo unicórnio.

Para os departamentos jurídicos, uma revolução.

Para a OAB paulista, uma série de perguntas sobre os limites da automação da advocacia.

E para Edamame?

Uma oportunidade de compreender uma das maiores transformações profissionais provocadas pela inteligência artificial.

— Laurent, acho que precisamos investigar.

— Finalmente, meu jovem. Mas desta vez nada de golpes. Vamos seguir os documentos.



🎭 Capítulo I — Quem é Makoto Edamura e por que ele está investigando uma inteligência artificial?

Antes de entrarmos na tecnologia, precisamos conhecer nosso investigador.

Makoto Edamura é o protagonista de Great Pretender, anime original produzido pelo WIT Studio, lançado em 2020, com direção de Hiro Kaburagi, roteiro de Ryota Kosawa e personagens desenhados por Yoshiyuki Sadamoto.

A história acompanha um jovem japonês que se considera um extraordinário vigarista, até encontrar Laurent Thierry, um trapaceiro internacional muito mais experiente.

O apelido Edamame nasce de uma brincadeira com seu sobrenome.

Ao longo da série, Makoto participa de operações elaboradas envolvendo identidades falsas, manipulação psicológica, organizações criminosas e situações em que a aparência raramente corresponde à realidade.

Mas existe uma característica especialmente interessante no personagem.

Edamame frequentemente acredita ter compreendido o golpe antes de descobrir que existe outro plano escondido dentro do primeiro.

É exatamente essa característica que torna Great Pretender uma metáfora interessante para investigar os sistemas de inteligência artificial.

Uma plataforma pode parecer simplesmente um programa que redige documentos.

Entretanto, quando examinamos sua estrutura operacional, encontramos agentes, decisões automatizadas, integrações, regras, contratos, modelos de remuneração e responsabilidade profissional.

O software é apenas a parte visível.

O verdadeiro sistema inclui tudo aquilo que acontece antes e depois da execução do algoritmo.

No universo da informática empresarial, chamamos isso de compreender o processo de negócio.

E nenhum programador COBOL deveria alterar um programa crítico antes de compreender o negócio que ele representa.

☕ Curiosidade Bellacosa

Em Great Pretender, muitas operações são divididas em casos, cada um com uma estrutura própria.

Nos ambientes de mainframe, também costumamos organizar o trabalho em etapas controladas: entrada de dados, processamento, validação, armazenamento e auditoria.

A diferença é que uma operação de confiança precisa ser verificável.

Não basta acreditar que alguém executou a tarefa corretamente.

Precisamos de evidências.



💰 Capítulo II — A Enter: o unicórnio brasileiro que encontrou ouro nas ações judiciais

Edamame abriu o notebook e começou a pesquisar.

A primeira descoberta foi surpreendente.

A Enter não nasceu para responder dúvidas jurídicas de pequenos usuários.

Seu principal mercado são os departamentos jurídicos de grandes empresas.

Bancos, companhias aéreas, plataformas de comércio eletrônico e outras organizações enfrentam milhares de processos judiciais.

Muitos envolvem situações semelhantes.

Imagine um banco com dezenas de milhares de reclamações relacionadas a tarifas, contratos, transações e serviços financeiros.

Cada processo exige uma série de tarefas:

  1. Receber e identificar a ação.

  2. Examinar os documentos.

  3. Localizar contratos e registros.

  4. Entender os fatos alegados.

  5. Identificar evidências relevantes.

  6. Consultar normas e precedentes.

  7. Preparar uma possível defesa.

  8. Submeter o trabalho ao advogado.

  9. Acompanhar o andamento judicial.

  10. Registrar os resultados.

É uma operação intensiva em informações.

E justamente por isso oferece oportunidades de automação.

Segundo os dados divulgados pela própria Enter em maio de 2026, mais de 300 mil processos por ano já contavam com o auxílio de sua tecnologia.

A companhia anunciou clientes como Bradesco, Nubank, Mercado Livre, Airbnb, LATAM Airlines e Azul, além de outras grandes empresas.

Laurent observou a tela.

— Veja, Edamame. A empresa não está vendendo apenas palavras geradas por inteligência artificial.

— Então o que está vendendo?

— Capacidade operacional.

A diferença é fundamental.

Um chatbot pode escrever uma contestação quando recebe informações.

Uma plataforma especializada procura integrar a obtenção dessas informações, a organização dos documentos, a elaboração de minutas e o acompanhamento do processo.

O objetivo comercial é reduzir o custo por processo e aumentar a produtividade.

O segredo do contencioso de massa

Contencioso é o conjunto de disputas jurídicas.

Quando uma empresa enfrenta milhares de ações semelhantes, falamos em contencioso de massa.

Considere uma simulação:

Uma empresa possui 100 mil processos anuais.

Se cada processo consumir dez horas de trabalho, teremos um milhão de horas.

Se a tecnologia reduzir parte dessas atividades para quatro horas por processo, o trabalho operacional cairia para 400 mil horas.

Seriam 600 mil horas potencialmente liberadas.

Atenção: esse é um exemplo matemático inventado para fins didáticos. Não representa um resultado auditado da Enter.

Naturalmente, nem todas as horas são intercambiáveis. Casos difíceis, erros da automação, revisões humanas e integrações tecnológicas podem reduzir a economia real.

Mas a escala ajuda a compreender o interesse dos investidores.

O mercado não está apenas comprando um algoritmo.

Está financiando a possibilidade de reorganizar uma indústria inteira.



🤖 Capítulo III — EnterOS: quando os agentes de IA entram no escritório de advocacia

Edamame imaginava que a Enter utilizasse um único modelo de linguagem.

Laurent apresentou outra possibilidade.

— Um sistema sofisticado pode distribuir tarefas entre diferentes componentes.

— Como uma equipe?

— Exatamente. Uma equipe digital.

A Enter chama sua plataforma de EnterOS.

A companhia afirma utilizar agentes de inteligência artificial para apoiar diferentes etapas do trabalho jurídico.

Nos modelos modernos de automação, um agente pode receber um objetivo, consultar ferramentas, analisar resultados e executar passos adicionais.

Não significa que possua consciência ou compreensão humana.

Significa que foi projetado para realizar tarefas coordenadas.

Uma arquitetura ilustrativa

Imagine cinco componentes:

Agente 1 — Recepção

Identifica o processo, separa documentos e reconhece as informações principais.

Agente 2 — Evidências

Consulta contratos, extratos e registros pertinentes.

Agente 3 — Análise

Organiza possíveis argumentos, identifica inconsistências e aponta informações ausentes.

Agente 4 — Redação

Prepara uma minuta baseada nos dados disponibilizados.

Agente 5 — Controle

Verifica integridade, registra o histórico e encaminha o material para revisão humana.

Essa divisão é um exemplo conceitual. Não significa que a Enter utilize exatamente cinco agentes ou essa arquitetura interna.

O problema das alucinações

Um modelo de linguagem pode produzir informações incorretas com aparência convincente.

Imagine uma minuta que cite uma decisão judicial inexistente.

Ou utilize um contrato pertencente a outro cliente.

Ou interprete uma data de pagamento incorretamente.

Esses erros podem produzir consequências sérias.

Na Justiça, uma afirmação falsa pode prejudicar direitos.

Por isso, um sistema jurídico confiável precisa apresentar a origem das informações utilizadas, permitir revisão crítica e manter rastreabilidade.

Edamame franziu a testa.

— Laurent, estamos falando de uma máquina que pode produzir milhares de documentos incorretos em questão de horas?

— Sim. Mas também pode ajudar a encontrar milhares de erros humanos. A tecnologia amplia a capacidade de operação, tanto para o bem quanto para o mal.

Esse é o paradoxo da automação.


⚖️ Capítulo IV — Outubro de 2026: a OAB de São Paulo entra em cena

Em 7 de outubro de 2026, a OAB-SP ajuizou uma ação civil pública contra a Enter, que atua juridicamente sob o nome Talisman AI Ltda.

A entidade não pediu simplesmente o fim da inteligência artificial jurídica.

Seu argumento principal foi a necessidade de delimitar a automação e preservar atividades privativas da advocacia.

Segundo a seccional paulista, seria necessário investigar em que medida a plataforma participa da definição de estratégias, produz documentos e organiza a atuação dos profissionais.

A OAB-SP também relatou ter recebido informações de advogados que se sentiriam pressionados a assinar grandes quantidades de documentos produzidos por inteligência artificial.

Esses relatos constituem alegações que precisam ser examinadas, não fatos judicialmente comprovados contra a Enter.

A entidade defende mecanismos de revisão humana efetiva e auditável.

Isso envolve algo muito mais importante do que colocar um botão de aprovação na tela.

Um advogado precisa ter condições reais de examinar o conteúdo, identificar erros, discordar do sistema e rejeitar uma minuta.

O advogado pode virar um simples carimbador?

Imagine uma situação hipotética.

Uma plataforma produz 500 contestações durante a madrugada.

Pela manhã, um advogado recebe uma fila de documentos aguardando aprovação.

Se ele possuir apenas alguns segundos para cada peça, será possível analisar individualmente os contratos, os fatos, as evidências e os argumentos?

Provavelmente não de maneira adequada.

O problema não é o software ter preparado os documentos.

O problema é a diferença entre uma revisão verdadeira e uma aprovação meramente formal.

Em um sistema empresarial, isso seria semelhante a permitir que um operador autorize centenas de transações críticas sem verificar os relatórios de exceção.

É um problema de governança.

E governança não se resolve apenas comprando computadores mais rápidos.


🏛️ Capítulo V — A guerra fria entre a OAB paulista e a direção nacional

Edamame encontrou uma segunda surpresa.

A disputa não envolvia somente a empresa tecnológica e a advocacia.

Existiam divergências entre a OAB-SP e a direção nacional da Ordem.

Pouco depois da ação paulista, uma resolução da direção do Conselho Federal estabeleceu parâmetros para negociar termos de ajustamento de conduta com empresas de inteligência artificial jurídica.

A Resolução nº 16/2026 foi assinada em 9 de outubro e disponibilizada no Diário Eletrônico da OAB em 13 de outubro.

O documento permite buscar soluções negociadas antes de decidir pelo ajuizamento de determinadas medidas.

Isso não impede providências judiciais urgentes e não representa aprovação automática de produtos de IA.

Temos, portanto, duas estratégias institucionais.

A posição paulista: levar a controvérsia ao Judiciário e exigir esclarecimentos, preservação de evidências e salvaguardas verificáveis.

A posição nacional: criar também uma via de negociação para corrigir eventuais irregularidades e estabelecer compromissos de adequação.

As posições não são necessariamente incompatíveis.

A divergência envolve o momento, a forma e a condução institucional da resposta.

A política entra no tabuleiro

A reportagem de Artur Rodrigues, publicada no UOL em 5 de novembro de 2026, apresenta essa disputa em um contexto mais amplo.

A OAB-SP também defende eleições diretas para a presidência nacional da Ordem.

Atualmente, a escolha da direção nacional ocorre por meio dos conselheiros federais.

A eleição paulista está prevista para novembro de 2027, enquanto a nacional está prevista para janeiro de 2028.

Não é possível concluir que a discussão eleitoral tenha causado a ação contra a Enter.

Entretanto, as divergências políticas ajudam a compreender por que um conflito tecnológico ganhou dimensão institucional.

Laurent sorriu.

— Agora temos dois tabuleiros, Edamame.

— A tecnologia e a política?

— E talvez um terceiro: o dinheiro.


📂 Capítulo VI — Os contratos misteriosos e a questão dos honorários

Em 20 de outubro, a OAB-SP informou ter juntado novos documentos à ação.

Entre eles, havia material apresentado como contrato de gestão e licenciamento de software.

Segundo a entidade, esse material previa mecanismos de distribuição de processos a escritórios e repasses associados à gestão dos casos, incluindo referência a 50% de determinado valor líquido.

A autenticidade e o alcance desses documentos dependem de apuração judicial.

Não se pode afirmar que tais condições tenham sido efetivamente adotadas pela Enter apenas com base nas alegações.

Mas a questão levantada é importante.

Existe diferença entre uma empresa vender software jurídico e uma empresa organizar a prestação de serviços de advocacia, influenciar a distribuição dos casos e participar de receitas relacionadas à atuação profissional.

No Brasil, a advocacia possui regras próprias de habilitação, independência, sigilo e remuneração.

A análise jurídica dependerá da realidade contratual e operacional, não apenas do nome comercial atribuído ao serviço.

O memorando de 2023

A reportagem do UOL também teve acesso a um memorando de investimento atribuído ao fundo ONEVC, de agosto de 2023.

O documento mencionava a possibilidade de trazer um presidente da OAB como investidor-anjo, sem identificar a pessoa nem esclarecer se seria da direção nacional ou de uma seccional.

Não existe, nessa reportagem, comprovação de que um dirigente da OAB tenha investido na Enter.

A empresa afirmou desconhecer o documento e negou qualquer convite, negociação ou participação financeira ou consultiva de dirigentes da Ordem.

Essa distinção é indispensável.

Um documento com uma referência a um possível investidor não comprova que o investimento aconteceu.

Edamame anotou cuidadosamente:

Hipótese não é evidência. Evidência não é sentença. E uma suspeita não pode ser apresentada como condenação.

Uma lição que vale tanto para investigadores quanto para programadores.


🔐 Capítulo VII — A Justiça manda preservar os registros

Em 21 de outubro de 2026, a Justiça Federal determinou que a Enter preservasse documentos e registros relacionados ao funcionamento de seu modelo de negócio desde 1º de janeiro de 2024.

A ordem abrangia contratos, versões de modelos, parametrizações, registros de geração e revisão de minutas, designação de processos e informações financeiras relacionadas às operações.

Foi estabelecida multa de R$ 50 mil por ato de descumprimento.

A decisão também rejeitou o pedido da empresa para suspender a ação em razão das conversas mantidas com o Conselho Federal.

A OAB-RJ foi admitida no polo ativo do processo.

Entretanto, a decisão não equivale a uma condenação definitiva da Enter nem a uma proibição geral de suas atividades.

O mérito da controvérsia permanece sujeito à análise judicial.

O que isso significa para um programador?

Significa que os registros de auditoria podem se transformar em provas decisivas.

Imagine que um advogado declare ter revisado determinado documento.

Um registro confiável poderia indicar:

  • Qual versão do documento foi apresentada.

  • Quando o profissional recebeu acesso.

  • Quais alterações realizou.

  • Quais fontes estavam disponíveis.

  • Quando ocorreu a aprovação.

  • Qual versão foi efetivamente utilizada.

Porém, um log registrando um clique não prova, sozinho, que houve revisão intelectual adequada.

Seria necessário examinar o contexto e a efetividade do controle.

É aqui que a informática se encontra diretamente com o Direito.


💻 Capítulo VIII — Edamame encontra um mainframe IBM e descobre o papel do COBOL

Nosso investigador decide visitar um centro de processamento de dados fictício.

No ambiente, uma aplicação bancária utiliza COBOL para processar contratos e transações financeiras.

Edamame observa os terminais.

— Laurent, achei que tudo estivesse na nuvem.

— A nuvem não eliminou os sistemas centrais. E muitos negócios continuam dependendo de plataformas transacionais construídas e modernizadas ao longo de décadas.

Um banco pode utilizar COBOL, CICS, Db2, Java, APIs e serviços de IA simultaneamente.

A modernização não exige abandonar todas as tecnologias anteriores.

O desafio consiste em integrar os sistemas com segurança.

Imagine esta arquitetura

Camada 1 — Sistemas transacionais

Programas COBOL processam contratos, saldos, tarifas e operações financeiras.

Camada 2 — Serviços de integração

APIs controladas disponibilizam dados autorizados.

Camada 3 — Plataforma jurídica

Uma ferramenta de IA recebe informações pertinentes a determinado processo.

Camada 4 — Revisão humana

Advogados verificam a interpretação dos documentos e a estratégia jurídica.

Camada 5 — Auditoria

Registros permitem reconstruir o processamento e identificar responsabilidades.

Essa arquitetura é uma hipótese didática. Não significa que a Enter utilize diretamente sistemas IBM Z em seus clientes.

Entretanto, o modelo demonstra como plataformas modernas de IA podem se relacionar com sistemas legados.

A grande lição

Uma IA não deveria obter acesso indiscriminado a um banco de dados apenas porque precisa consultar determinada informação.

A integração deve utilizar autenticação, autorização, minimização de dados e registros de acesso.

O sistema transacional permanece como fonte oficial dos valores financeiros.

A IA funciona como ferramenta de análise.

E o profissional autorizado permanece responsável pelas decisões que exigem julgamento humano.


🧪 Capítulo IX — Laboratório COBOL: construindo um controle de revisão para documentos gerados por IA

Agora começa a parte prática.

Imagine que fomos contratados para desenvolver um pequeno programa COBOL capaz de verificar se uma minuta produzida por inteligência artificial passou por uma revisão humana registrada.

Não vamos construir uma IA nem um sistema judicial real.

Nosso objetivo será demonstrar os conceitos básicos de entrada de dados, condições, regras de negócio e validação.

Passo 1 — Definindo os requisitos

O programa receberá três informações:

  1. Identificador numérico do processo.

  2. Indicador de existência de advogado responsável.

  3. Indicador de revisão registrada.

Se ambos os indicadores forem iguais a S, o programa apresentará uma mensagem informando que os requisitos cadastrais mínimos foram atendidos.

Caso contrário, apontará a pendência.

Isso não comprova a qualidade da revisão jurídica. Apenas demonstra uma regra administrativa simples.

Passo 2 — O código COBOL

Exemplo em formato livre, compatível com compiladores que suportam essa modalidade:

       >>SOURCE FORMAT FREE
identification division.
program-id. AUDITIA.

environment division.
configuration section.
repository.
    function all intrinsic.

data division.
working-storage section.

01 ws-processo       pic 9(8).
01 ws-advogado       pic x.
01 ws-revisao        pic x.
01 ws-situacao       pic x(30).

procedure division.

    display "BELLACOSA MAINFRAME"
    display "CONTROLE DIDATICO DE IA JURIDICA"

    display "Numero do processo (8 digitos): "
    accept ws-processo

    display "Advogado responsavel? (S/N): "
    accept ws-advogado

    display "Revisao registrada? (S/N): "
    accept ws-revisao

    evaluate true
        when ws-advogado = "S"
         and ws-revisao = "S"
            move "CADASTRO MINIMO ATENDIDO"
              to ws-situacao

        when other
            move "PENDENCIA DE VALIDACAO"
              to ws-situacao
    end-evaluate

    display "PROCESSO: " ws-processo
    display "SITUACAO: " ws-situacao

    goback.

Passo 3 — Entendendo as divisões

O COBOL organiza os programas em divisões.

A IDENTIFICATION DIVISION identifica o programa.

A ENVIRONMENT DIVISION permite definir características do ambiente.

A DATA DIVISION declara as variáveis.

A PROCEDURE DIVISION contém as instruções executáveis.

No nosso exemplo, o número do processo é armazenado em:

PIC 9(8)

Isso significa um campo numérico de oito dígitos.

Já os indicadores utilizam:

PIC X

Cada campo armazena um caractere.

Passo 4 — Entendendo o EVALUATE

O comando EVALUATE permite selecionar diferentes comportamentos a partir de condições.

No exemplo, usamos:

evaluate true
    when ws-advogado = "S"
     and ws-revisao = "S"
        ...
    when other
        ...
end-evaluate

Se o cadastro apresentar advogado responsável e revisão registrada, o programa informa que os requisitos mínimos foram atendidos.

Caso contrário, existe uma pendência.

É importante compreender que os indicadores são simplesmente informações declaradas ao programa.

Uma pessoa poderia informar S sem ter realmente revisado documento algum.

Portanto, esse pequeno programa é apenas o início de uma solução de controle.

Passo 5 — Executando o programa

Em um ambiente de laboratório com GnuCOBOL, poderíamos compilar o arquivo auditia.cbl utilizando:

cobc -x -free -o auditia auditia.cbl

Depois, em Linux ou outro ambiente compatível:

./auditia

Exemplo de entrada:

Numero do processo (8 digitos):
12345678

Advogado responsavel? (S/N):
S

Revisao registrada? (S/N):
N

Saída esperada:

PROCESSO: 12345678
SITUACAO: PENDENCIA DE VALIDACAO

Passo 6 — Melhorando a solução

Um sistema real precisaria de controles adicionais.

Por exemplo:

  • Identificação autenticada do advogado.

  • Data e hora da revisão.

  • Identificação da versão do documento.

  • Registro de alterações.

  • Histórico de aprovação.

  • Associação às evidências utilizadas.

  • Proteção contra alterações indevidas.

  • Política de retenção e descarte dos registros.

Também seria necessário validar entradas e tratar erros antes da gravação dos dados.

Nossa aplicação de laboratório ainda permite valores inválidos, não consulta um cadastro profissional e não grava registros persistentes.

Em produção, essas limitações seriam inaceitáveis.

☕ Dica Bellacosa

Não confunda um campo preenchido com uma atividade comprovadamente executada.

Esse é um dos erros mais perigosos dos sistemas corporativos.

Uma transação pode estar marcada como aprovada sem que a autorização tenha sido válida.

Uma documentação pode estar marcada como revisada sem que alguém tenha conferido seu conteúdo.

A qualidade da auditoria depende da confiabilidade do processo completo.


🕵️ Capítulo X — O golpe dentro do golpe: quando a inteligência artificial inventa uma evidência

Edamame resolveu testar uma situação fictícia.

Um consumidor processa uma instituição financeira alegando cobrança indevida de R$ 8 mil.

O sistema de inteligência artificial recebe documentos e procura informações pertinentes.

Porém, encontra um contrato parecido, pertencente a outra operação.

A IA identifica cláusulas semelhantes e conclui, incorretamente, que o documento comprova a autorização da cobrança.

Uma minuta é produzida com essa interpretação equivocada.

Se ninguém conferir a associação entre o contrato e o processo, o erro poderá chegar à defesa.

O problema não começou na redação do texto.

Começou na identificação da evidência.

Data lineage: a origem dos dados

Em engenharia de dados, data lineage representa a capacidade de compreender a origem e as transformações pelas quais uma informação passou.

No nosso exemplo, seria necessário saber:

Qual sistema forneceu o contrato?

Quando ele foi consultado?

A qual cliente pertence?

Qual é o identificador da operação financeira?

Qual versão foi utilizada?

Houve alguma transformação dos dados?

Uma aplicação COBOL poderia contribuir fornecendo registros transacionais confiáveis, desde que corretamente integrados.

A IA precisaria respeitar esses registros e indicar as fontes que fundamentaram sua análise.

Uma resposta aparentemente convincente não substitui uma evidência verificável.

Essa é uma lição especialmente importante para bancos e instituições financeiras.


🧠 Capítulo XI — O perigo da industrialização das defesas judiciais

Vamos imaginar uma situação social mais ampla.

Uma grande empresa possui milhares de consumidores insatisfeitos.

Alguns apresentam reclamações procedentes.

Outros cometem equívocos.

Existem também processos sem fundamento suficiente.

Uma plataforma de IA pode ajudar a organizar esses casos.

Mas existe uma questão de equilíbrio.

O consumidor normalmente possui recursos limitados para investigar sistemas internos de uma empresa.

A companhia, por outro lado, pode possuir equipes jurídicas, bancos de dados, sistemas transacionais e ferramentas avançadas de automação.

Se conseguir produzir defesas em grande escala e a baixo custo, poderá obter vantagens operacionais importantes.

Isso não significa que suas defesas sejam incorretas.

Também não significa que os consumidores tenham sempre razão.

Significa que a tecnologia pode alterar a distribuição de recursos e capacidades entre as partes.

Um exemplo hipotético

Imagine dois participantes de uma disputa judicial.

O consumidor possui acesso ao contrato, alguns comprovantes e mensagens de atendimento.

A empresa possui registros financeiros, logs, informações sobre operações internas e uma plataforma capaz de localizar documentos relevantes em segundos.

Se a empresa disponibilizar evidências corretas, a automação poderá ajudar a esclarecer o conflito.

Mas, caso utilize documentos incompletos ou classificações equivocadas, o mesmo mecanismo poderá multiplicar problemas.

O princípio do contraditório exige que as partes tenham oportunidade de conhecer e contestar os elementos relevantes apresentados no processo.

Ferramentas de IA deveriam contribuir para melhorar a qualidade das informações, não dificultar sua contestação.

Uma possibilidade positiva

A automação também pode beneficiar consumidores.

Imagine uma ferramenta capaz de identificar inconsistências em milhares de contratos, localizar cobranças potencialmente indevidas e ajudar profissionais habilitados a analisar reclamações.

O mesmo avanço tecnológico pode servir a diferentes lados de uma disputa.

A questão decisiva não é simplesmente quem utiliza inteligência artificial.

É como utiliza, quais controles existem e quem responde pelos resultados.


💸 Capítulo XII — A economia da IA jurídica: produtividade, empregos e concentração de mercado

Edamame retornou à cafeteria.

— Laurent, se uma empresa automatiza milhares de processos, ela não vai precisar de menos advogados?

— Algumas tarefas podem exigir menos horas de trabalho. Mas a consequência sobre o emprego depende de muitos fatores.

Essa resposta merece atenção.

A automatização pode reduzir a demanda por determinadas atividades repetitivas.

Ao mesmo tempo, pode criar novas funções ligadas à integração de sistemas, revisão especializada, auditoria, segurança, governança e supervisão tecnológica.

Não existe garantia de que os novos postos compensarão integralmente os anteriores.

Também não é correto afirmar que toda tecnologia de produtividade provoca necessariamente desemprego generalizado.

Os efeitos dependerão de custos, regulação, concorrência, demanda e reorganização dos serviços.

O que acontece com o jovem advogado?

Profissionais iniciantes frequentemente aprendem preparando documentos, pesquisando precedentes e examinando processos.

Se grande parte desse trabalho for automatizada, escritórios e departamentos jurídicos precisarão encontrar novas formas de treinamento.

Existe um risco semelhante na programação COBOL.

Uma IA pode preparar um programa relativamente simples.

Mas como o iniciante aprenderá a identificar erros, interpretar regras de negócio e compreender o comportamento do compilador se apenas copiar o resultado?

A produtividade de curto prazo não pode destruir a formação técnica de longo prazo.

A concentração tecnológica

Outra preocupação envolve o poder das plataformas.

Empresas capazes de reunir grandes volumes de dados, integrar sistemas e financiar infraestrutura de IA podem conquistar vantagens competitivas significativas.

Isso não representa necessariamente uma ilegalidade.

Entretanto, pode aumentar a dependência tecnológica de clientes e profissionais.

Quanto mais uma organização depender de uma única plataforma, mais importante será avaliar portabilidade de dados, interoperabilidade, auditoria e continuidade operacional.

No mainframe conhecemos bem essa discussão.

O custo de substituir um sistema crítico não está apenas no software.

Está nas integrações, nos processos, nos conhecimentos acumulados e nas dependências construídas ao longo dos anos.


🧭 Capítulo XIII — A Lei Geral de Proteção de Dados entra na investigação

O trabalho jurídico frequentemente envolve informações pessoais.

Contratos, documentos de identificação, dados financeiros, registros trabalhistas e informações de saúde podem aparecer em processos.

Portanto, uma plataforma de IA jurídica precisa observar os requisitos legais aplicáveis ao tratamento dessas informações.

No Brasil, a LGPD estabelece princípios como finalidade, adequação, necessidade, segurança e prevenção.

Isso exige muito mais do que colocar uma senha na aplicação.

Um projeto sério deve avaliar quais dados precisam ser utilizados, quem poderá acessá-los e durante quanto tempo deverão ser preservados.

Cinco perguntas para uma auditoria

Primeira: a plataforma recebe somente as informações necessárias para determinada finalidade?

Segunda: existem mecanismos para impedir acesso indevido a documentos de outros clientes?

Terceira: as consultas e alterações deixam registros auditáveis?

Quarta: os contratos estabelecem responsabilidades sobre o tratamento e a retenção dos dados?

Quinta: existem procedimentos para lidar com incidentes e responder aos direitos dos titulares?

A Enter declara adotar controles de segurança e proteção de informações.

A avaliação de sua conformidade concreta exigiria documentação técnica, contratos e verificações adequadas.

O perigo do treinamento inadvertido

Uma preocupação recorrente envolve a possibilidade de documentos confidenciais serem utilizados para treinar modelos de inteligência artificial.

Não se deve presumir que isso esteja acontecendo na Enter.

A empresa afirma manter proteções para impedir utilização inadequada dos dados de clientes.

Entretanto, qualquer organização que contrate soluções de IA deve verificar tecnicamente e contratualmente as condições de processamento e retenção.

O sigilo profissional não desaparece porque um documento passou por uma API.


🛠️ Capítulo XIV — Dez recomendações para programadores COBOL que trabalharão com inteligência artificial

A discussão jurídica oferece ensinamentos valiosos para o desenvolvimento de aplicações empresariais.

1. Compreenda a regra de negócio antes de automatizá-la.

Um requisito mal interpretado continuará errado mesmo quando processado por uma IA sofisticada.

2. Nunca confie cegamente em código gerado por modelos de linguagem.

Leia, compile, teste e documente.

3. Preserve a origem dos dados.

Registre de onde veio cada informação importante.

4. Utilize controles de acesso.

Nenhum agente deve receber privilégios superiores aos necessários.

5. Separe análise de execução.

Uma IA pode sugerir uma ação sem receber autorização para executá-la automaticamente.

6. Implemente registros de auditoria.

Identifique transações, usuários, horários e versões relevantes.

7. Proteja informações sensíveis.

Evite inserir dados reais em ferramentas sem autorização institucional.

8. Prepare testes negativos.

Verifique o comportamento diante de documentos ausentes, dados inconsistentes e entradas inválidas.

9. Mantenha possibilidade de intervenção humana.

Em processos críticos, uma pessoa autorizada precisa conseguir interromper ou rejeitar operações inadequadas.

10. Documente as limitações.

Um sistema bem projetado deve permitir que seus usuários conheçam os riscos e as condições de utilização.

Exercício para o laboratório

Amplie o programa AUDITIA para aceitar um terceiro indicador:

WS-EVIDENCIA

Ele deverá informar se a documentação de suporte foi registrada.

Depois, modifique o EVALUATE para exigir os três indicadores iguais a S.

Em uma segunda versão, grave um arquivo sequencial contendo os dados recebidos.

Na terceira versão, crie uma estrutura com data, identificador do revisor e situação.

Por fim, desenvolva casos de teste para entradas incorretas e registre os resultados.

Esse exercício simples permite praticar declarações de dados, condições, processamento e desenho de controles.


🎲 Capítulo XV — O que Edamame realmente descobriu?

Ao final da investigação, Laurent perguntou:

— Então, Edamame, encontrou o grande golpe?

O jovem permaneceu em silêncio por alguns instantes.

— Não encontrei provas de que a Enter seja uma fraude. Encontrei uma empresa tecnológica que cresceu rapidamente, um mercado jurídico sujeito à automação e uma disputa institucional sobre os limites dessa transformação.

Laurent sorriu.

— Excelente. Você finalmente aprendeu a diferença entre investigar e acusar.

Edamame continuou:

— Mas encontrei uma questão ainda maior. Se a inteligência artificial puder preparar milhares de defesas, quem será responsável por garantir que cada uma delas seja correta?

Essa é a pergunta mais importante do caso.

Não basta saber se uma máquina consegue realizar determinada tarefa.

Precisamos compreender quem estabelece as regras, quem controla os dados, quem valida os resultados e quem assume as consequências.

O problema aparece no Direito, mas também na Medicina, na Engenharia, na Contabilidade, na Segurança Cibernética e no desenvolvimento de software.

A inteligência artificial está alterando a fronteira entre executar uma tarefa e assumir responsabilidade profissional por ela.

A diferença entre capacidade e autoridade

Um sistema pode possuir capacidade técnica para produzir um documento.

Isso não significa que possua autoridade jurídica para exercer uma profissão regulamentada.

Da mesma forma, um programa COBOL pode possuir capacidade para movimentar valores financeiros, mas sua execução deve obedecer a regras de autorização e controle.

A existência da funcionalidade não substitui a legitimidade de sua utilização.


🥚 Capítulo XVI — Easter eggs: as pistas escondidas entre COBOL, Great Pretender e a Justiça

Easter egg 1 — O nome Edamame

Makoto prefere ser reconhecido pelo próprio sobrenome, mas Laurent insiste em chamá-lo de Edamame.

A brincadeira funciona como uma lembrança de que um rótulo pode mudar a percepção das pessoas.

Na disputa jurídica, chamar determinada solução de software, plataforma ou serviço não resolve automaticamente a natureza das atividades efetivamente realizadas.

É necessário observar a operação real.

Easter egg 2 — O mágico de Oz

Em Great Pretender, os personagens encontram situações em que os acontecimentos aparentes escondem estruturas muito mais elaboradas.

Na tecnologia, algo parecido acontece quando uma interface simples esconde centenas de componentes.

O usuário vê uma resposta.

O engenheiro precisa compreender o processamento.

Easter egg 3 — O velho arquivo sequencial

Durante décadas, aplicações COBOL utilizaram arquivos sequenciais e registros organizados para processar informações empresariais.

Esses mecanismos ensinam uma lição que continua valiosa.

Dados precisam de estrutura.

Informações precisam de contexto.

Resultados precisam de validação.

Não existe inteligência artificial capaz de transformar automaticamente dados inconsistentes em verdades confiáveis.

Easter egg 4 — O terminal 3270

Imagine Edamame sentado diante de um terminal IBM 3270.

Na tela, um sistema solicita confirmação de uma transação.

A operação exige autorização.

O personagem tenta executar a tarefa sem possuir os privilégios necessários.

O sistema apresenta uma mensagem de acesso negado.

O que parece uma inconveniência é, na realidade, uma proteção.

Em sistemas críticos, impedir operações indevidas é tão importante quanto executar rapidamente as operações permitidas.

Easter egg 5 — O verdadeiro Great Pretender

O título do anime faz referência ao universo das aparências, das identidades e da confiança.

No mundo da IA generativa, existe um fenômeno curioso.

Uma resposta pode parecer extremamente segura e bem fundamentada mesmo quando contém erros.

A fluência não garante veracidade.

Um texto bonito não é necessariamente um texto correto.

E um documento produzido com velocidade não é necessariamente um documento juridicamente adequado.

Talvez seja essa a maior armadilha contemporânea: confundir aparência de competência com competência comprovada.


🏁 Epílogo — Quem vencerá a guerra da inteligência artificial jurídica?

A cafeteria começava a fechar.

Edamame guardou o notebook.

A investigação havia revelado três forças disputando o futuro.

De um lado, empresas de tecnologia financiadas para automatizar operações jurídicas.

De outro, entidades profissionais preocupadas com responsabilidade, independência e atividades reservadas aos advogados.

No centro, trabalhadores, empresas, consumidores e cidadãos cujos direitos dependem do funcionamento correto da Justiça.

Seria possível construir uma solução que respeitasse todos esses interesses?

A resposta depende de escolhas tecnológicas, regulatórias, econômicas e institucionais.

A inovação pode ampliar o acesso aos serviços jurídicos, reduzir tarefas repetitivas e melhorar a análise de documentos.

Mas também pode reproduzir erros em escala, concentrar capacidade tecnológica e enfraquecer mecanismos de responsabilidade quando implementada inadequadamente.

A questão não é escolher entre inteligência artificial e advogados.

É construir sistemas em que automação e responsabilidade profissional possam coexistir de maneira verificável.

No universo do mainframe, aprendemos que disponibilidade, integridade e segurança não aparecem espontaneamente.

São resultados de arquitetura, processos, controles, testes e profissionais preparados.

A Justiça automatizada precisa da mesma disciplina.

Edamame levantou-se.

— Laurent, sabe qual foi a coisa mais importante que aprendi?

— Qual?

— Que o verdadeiro perigo não está em uma máquina escrever milhares de documentos.

Laurent inclinou a cabeça.

— Então onde está?

— Em alguém acreditar que milhares de documentos estão corretos apenas porque uma máquina conseguiu produzi-los.

O francês terminou seu café.

— Muito bem, Edamame. Você está começando a pensar como um verdadeiro investigador.

E, em algum lugar de um centro de processamento de dados, um programa COBOL continuava registrando transações, verificando condições e preservando as informações que talvez um dia precisassem ser apresentadas diante de um tribunal.

Porque, no final das contas, a confiança não nasce da velocidade de processamento. Ela nasce da possibilidade de verificar a verdade.


☕ Considerações finais — Bellacosa Mainframe

A história da Enter representa uma nova etapa da transformação digital brasileira.

Não estamos falando de uma experiência acadêmica isolada.

Estamos diante de uma empresa que anunciou investimentos expressivos, conquistou grandes clientes e passou a atuar em uma atividade com profundas consequências sociais.

A reação da OAB-SP, a estratégia de negociação do Conselho Federal e as decisões da Justiça Federal revelam que as instituições brasileiras ainda estão procurando maneiras de lidar com sistemas capazes de automatizar tarefas intelectuais especializadas.

A discussão merece ser acompanhada sem alarmismo e sem ingenuidade.

É necessário evitar tanto a ideia de que qualquer utilização de IA constitui uma ameaça à advocacia quanto a suposição de que toda automação produzida por uma empresa inovadora será automaticamente benéfica.

O desenvolvimento tecnológico precisa caminhar com transparência, responsabilização e proteção dos direitos fundamentais.

Para nós, programadores COBOL, fica uma lição adicional.

O futuro da computação empresarial não será necessariamente uma guerra entre mainframes e inteligência artificial.

Poderá ser uma combinação de sistemas transacionais altamente confiáveis, interfaces modernas, modelos inteligentes e processos de governança rigorosos.

A inteligência artificial poderá analisar registros produzidos por aplicações COBOL.

Mas os desenvolvedores continuarão precisando compreender dados, regras de negócio, integridade transacional e segurança.

Talvez a maior contribuição das tecnologias tradicionais para esse novo mundo seja justamente lembrar que sistemas críticos exigem disciplina.

A IA pode escrever a minuta. O COBOL pode fornecer a evidência. Mas a responsabilidade pela decisão não pode desaparecer no meio do processamento.

E essa, meus caros leitores, é uma história que vale mais do que US$ 1,2 bilhão.

Até o próximo café no Bellacosa Mainframe!


Referências e fontes consultadas

  1. UOL — Artur Rodrigues, 5 de novembro de 2026: Disputa sobre IA jurídica expõe guerra fria entre OAB-SP e cúpula nacional.
    https://noticias.uol.com.br/colunas/artur-rodrigues/2026/11/05/disputa-sobre-ia-juridica-expoe-guerra-fria-entre-oab-sp-e-cupula-nacional.htm

  2. OAB-SP — 7 de outubro de 2026: comunicado sobre a ação civil pública ajuizada contra a Enter.
    https://www.oabsp.org.br/

  3. OAB-SP — 20 de outubro de 2026: comunicado sobre documentos apresentados no processo judicial.
    https://www.oabsp.org.br/

  4. OAB-SP — 21 de outubro de 2026: comunicado sobre a decisão judicial de preservação de registros.
    https://www.oabsp.org.br/

  5. Conselho Federal da OAB: Resolução nº 16/2026, sobre parâmetros para termos de ajustamento com empresas de IA jurídica.
    https://deoab.oab.org.br/

  6. Enter — 5 de maio de 2026: anúncio da rodada Série B e avaliação de US$ 1,2 bilhão.
    https://www.getenter.ai/

  7. Bloomberg Línea — 5 de maio de 2026: cobertura da rodada de investimento da Enter.
    https://www.bloomberglinea.com.br/

  8. Great Pretender — Site oficial: informações sobre Makoto Edamura, personagens, história e produção.
    https://www.greatpretender.jp/

  9. IBM: documentação de Enterprise COBOL e desenvolvimento no IBM Z.
    https://www.ibm.com/docs/en/cobol-zos


Bellacosa Mainframe — Onde os sistemas legados encontram a inteligência artificial, a história da computação ganha vida e até um vigarista internacional precisa aprender COBOL.

domingo, 4 de outubro de 2026

IBM NOS ANOS 1980: O DIA EM QUE O MAINFRAME VIROU PEDRA — E DR. STONE PRECISOU RECONSTRUIR A INFORMÁTICA!

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:

  1. O acordo antitruste de 1956.

  2. O processo iniciado em 1969.

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

Naturalmente, 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.TXT

Um 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á:

  1. Definir um saldo inicial.

  2. Aplicar um depósito.

  3. Subtrair um pagamento.

  4. Apresentar o resultado.

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

  1. Acessar o ambiente autorizado de desenvolvimento.

  2. Criar um membro contendo o código-fonte COBOL.

  3. Verificar se o código está no formato esperado pelo compilador.

  4. Utilizar um procedimento de compilação e linkedição disponível na instalação.

  5. Executar o programa.

  6. Consultar o resultado pelo SDSF ou ferramenta equivalente.

  7. Comparar a saída obtida com o resultado esperado.

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

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...